VTU 5TH SEM CSE SOFTWARE ENGINEERING SOLVED PAPERS - JUN13 DEC13 JUN14 DEC14 JUN15

SOFTWARE ENGINEERING SOLVED PAPER JUNE - 2013
1-1
1a. What are the attributes of good software? (04 Marks)
Ans:
FOUR ATTRIBUTES OF GOOD SOFTWARE
1) Maintainability
• Software must be able to evolve to meet the changing-needs of customers.
2) Dependability
• Dependability has a range of features such as
→ reliability
→ security &
→ safety.
• In the event of software-failure, the software should not cause physical or economic damage.
3) Efficiency
• Software should not waste system-resources such as
→ memory-cycles &
→ processor-cycles.
• Efficiency includes
→ response-time
→ processing-time &
→ memory-utilization.
4) Usability
• Software must be usable, without undue effort, by the end-user.
• Software should have an appropriate
→ user interface &
→ proper documentation.
1b. Define software engineering. Explain diff. types of software products (06 Marks)
Ans:
SOFTWARE ENGINEERING
• This is an engineering-discipline which is concerned with all aspects of software-development.
• Software-engineers should
→ adopt a systematic approach to their work and
→ use appropriate tools/techniques depending on
1) Problem to be solved
2) Development constraints &
3) Available Resources (Figure 1.1).
Figure 1.1: Stages in software engineering
TWO TYPES OF SOFTWARE PRODUCTS
1) Generic Products
 These are stand-alone systems that are developed by a software-company.
 These are sold to any customer who is able to buy them.
 The company which develops the software controls the software-specification.
 For example:
→ databases
→ word processors &
→ drawing packages.

1-2
2) Customized Products
 These are systems which are developed for a particular customer.
 A software-contractor develops the software especially for that customer.
 The company which is buying the software controls the software-specification.
 The software-developers must work to that specification.
 For example:
→ electronic-device control systems &
→ air-traffic control systems.
1c. Explain emergent system properties with example (10 Marks)
Ans:
EMERGENT SYSTEM PROPERTIES
1) Functional Emergent Properties
• These properties appear when all parts of a system work together to achieve some objective.
• For ex,
After a bicycle is assembled from different components,
the bicycle has the functional property of a transportation-device.
2) Non-functional Emergent
• These properties relate to the behavior of the system in its operational environment.
• For ex,
→ reliability
→ performance
→ safety &
→ security.
• Failure to achieve these properties may make the system unusable.
• Most often, a system which is unreliable or too slow is rejected by all the end-users.
EXAMPLES OF EMERGENT PROPERTIES
1) Volume
• The volume means the total space occupied in the system.
• The volume varies depending on how the components are arranged and connected.
2) Reliability
• System-reliability depends on component-reliability.
• Unexpected-interactions between components can cause new types of failure.
Therefore, this affects the reliability of the system.
• Three types:
1) Hardware Reliability
 What is the probability of a hardware-component failing?
 How long does it take to repair the component?
2) Software Reliability
 How likely the software-component will produce an incorrect output?
3) Operator Reliability
 How likely the system-operator will make an error?
3) Security
• The security of the system cannot be easily measured.
• Attacks may be devised which are not anticipated by the system-designers.
• Attacks may defeat built-in safeguard.
4) Repairability
• How easy it is to fix a problem in the system, once it has been discovered?
• This depends on being able to
i) Diagnose the problem
ii) Access the faulty-components and
iii) Modify or replace the components.
5) Usability
• How easy it is to use the system?
• This depends on
i) Technical-components
ii) Component’s operators and
iii) Component’s operating environment.

1-3
2a. Explain the different types of critical systems. (06 Marks)
Ans:
CRITICAL SYSTEMS
• These are socio-technical systems that people or businesses depend-on.
• Failure of the systems results in
i) Serious problems and
ii) Significant losses.
• Three main types:
1) Safety-Critical Systems
 A system whose failure may result in
→ injury
→ loss of life or
→ serious environmental damage.
 Example: Control-system in a chemical manufacturing plant.
2) Mission-Critical Systems
 A system whose failure may result in the failure of some goal-directed activity.
 Example: Navigational-system in a spacecraft.
3) Business-Critical Systems
 A system whose failure may result in very high costs for the business.
 Example: Customer accounting-system in a bank.
A SIMPLE SAFETY-CRITICAL SYSTEM
• Automated insulin delivery-systems
→ monitor blood sugar-levels &
→ deliver an appropriate dose of insulin when required (Figure 3.1).
• A software-controlled insulin- system works by using a micro-sensor embedded in the patient.
• The micro-sensor is used to measure some blood parameter that is proportional to sugar-level.
• The controller computes the sugar-level and the amount of insulin that is needed.
• Then, the controller sends signals to a miniaturised pump to deliver the insulin via a needle.
• There are 2 high-level dependability requirements:
1) The system should be available to deliver insulin when required (Figure 3.2).
2) The system should deliver the correct amount of insulin.
Figure 3.1 Insulin pump structure
Figure 3.2 Data-flow model of the insulin pump

1-4
2b. Describe rational unified process (RUP) with block diagram. (09 Marks)
Ans:
RATIONAL UNIFIED PROCESS
• This is described from 3 perspectives:
1) Dynamic Perspective shows the phases of the model over time.
2) Static Perspective shows the process-activities that are enacted.
3) Practice Perspective suggests good practices to be used during the process.
• Four phases (Figure 4.12):
1) Inception
 The goal is to establish a business-case for the system.
 Software-engineers should
→ identify all external entities that will interact with the system &
→ define the interactions with the system.
2) Elaboration
 The goal is to
→ develop an understanding of the problem-domain
→ establish an architectural-framework for the system
→ develop the project-plan &
→ identify key project-risks.
3) Construction
 This is concerned with i) design, ii) programming & iii) testing.
 Parts of the system are developed in parallel & integrated.
4) Transition
 This is concerned with
→ moving the system from development-community to user-community and
→ making the system work in a real environment.
Figure 4.12 Phases in the Rational Unified Process
• The static view of the RUP focuses on the activities that take place during the development
process. These are called workflows.
• Core engineering and support workflows:
1) Business Modeling
 The business-processes are modeled using business use-cases.
2) Requirements
 Actors who interact with the system are identified.
 Use-cases are developed to model the system-requirements.
3) Analysis and Design
 A design-model is created and documented using
i) architectural-models ii) component-models and iii) sequence-models.
4) Implementation
 The system-components are implemented.
5) Testing
 Testing is carried out in conjunction with implementation.
6) Deployment
 A product-release is
→ created & distributed to users and
→ installed in user’s workplace.
7) Configuration & Change Management
 This manages changes to the system.
8) Project Management
 This manages the system-development.
9) Environment
 This is concerned with making right software-tools available to development-team.

1-5
• Six best practices are recommended:
1) Develop Software Iteratively
 Plan increments of the system based on customer-priorities.
 Develop & deliver highest priority system-features early in the development-process.
2) Manage Requirements
 Explicitly document the customer’s requirements.
 Keep track of changes to customer’s requirements.
 Analyze the impact of changes on the system before accepting them.
3) Use Component-based Architectures
 Structure the system-architecture into components.
4) Visually Model Software
 Use graphical-models to present static- and dynamic-views of the software.
5) Verify Software Quality
 Ensure that the software meets the organizational quality-standard.
6) Control Changes to Software
 Manage changes to the software using
i) change management-system &
ii) configuration-management tools.
2c. Explain security terminologies. (05 Marks)
Ans:
SECURITY TERMINOLOGIES
1) Exposure
 Possible loss or harm in a computing-system.
 This may be loss or damage to data.
 This may be a loss of time & effort if recovery is necessary after a security breach.
2) Vulnerability
 A weakness in a computer-system that may be exploited to cause loss or harm.
3) Attack
 An exploitation of a system’s vulnerability.
 Often, attack is from outside the system.
 Often, attack is a deliberate attempt to cause some damage.
4) Threats
 Circumstances that have potential to cause loss or harm.
 Threats are a system-vulnerability that is subjected to an attack.
5) Control
 A protective measure that reduces a system’s vulnerability.
 For ex: Encryption can be used to reduce a vulnerability of a weak access control
system.

1-6
3a. Explain the metrics for specifying non-functional requirements. (06 Marks)
Ans:
3b. Explain requirement engineering process. (06 Marks)
Ans:
Requirement Engineering Process
• The goal is to create and maintain a system requirement document.
• The overall process includes 4 sub-processes:
1) Feasibility Study: Concern with accessing whether system is useful to the business.
2) Elicitation & Analysis: Discovering requirement and analyzing them.
3) Specialization: Converting this requirement into some standard form.
4) Validation: Checking that the requirement actually defines the system that the
customer wants.
• These activities are concerned with
→ discovery documentation &
→ checking of requirements.
• The people involved in development gain better understanding of
→ what they want to do the software
→ modification made to the software and organizational environment.
• The process of managing these changing requirements is called requirement management.
Figure 7.1 The requirements engineering process

1-7
3c. Explain the structure of the requirement document. (08 Marks)
Ans:
STRUCTURE OF A REQUIREMENTS DOCUMENT
1) Preface
• This should
→ define the expected readership of the document &
→ describe document’s version history & a summary of changes made in each version.
2) Introduction
• This should
→ describe the need for the system.
→ describe system’s functions and explain how it will work with other systems.
→ describe how the system fits into the overall business objectives of the organisation.
3) Glossary
• This should define the technical terms used in the document.
4) User Requirements
• This should
→ describe services provided for the user
→ describe the non-functional definition system requirements &
→ specify product standards which must be followed.
• This description may use
→ natural language
→ diagrams or
→ other notations.
5) System Architecture
• This should
→ describe a high-level overview of the anticipated system-architecture
→ show the distribution of functions across system modules &
→ highlight architectural components that are reused.
6) System Requirements
• This should describe the functional and non-functional specification requirements in more detail.
7) System models
• This should select one or more system models showing the relationships between
→ system-components and
→ system.
• These might be
→ object models
→ data-flow models and
→ semantic data models.
8) System Evolution
• This should describe anticipated changes due to hardware evolution, changing user needs, etc.
9) Appendices
• These should provide detailed, specific information which is related to the application.
• Examples: i) Hardware description and ii) Database description.
i) Hardware Requirements define the minimal & optimal configurations for the system.
ii) Database Requirements define the logical organisation of the data used by the
system and the relationships between data.
10) Index
• Several indexes to the document may be included.
• Along with a normal alphabetic index, there may be an index of diagrams, an index of
functions, etc.

1-8
4a. List and explain different types of system models. (10 Marks)
Ans:
CONTEXT MODEL
• This shows how the system is positioned in an environment with other systems and processes.
• They also define the boundaries of the system (Figure 8.1).
• However, they do not show the relationships between
→ specified system and
→ other systems in the environment.
Figure 8.1 The context of an ATM system
BEHAVIORAL MODEL
• This is used to describe the overall behavior of the system.
• Two types of model: 1) Data-flow models and 2) State machine models.
Data Flow Models
 This shows how data is processed at different stages in the system.
 This also shows how data flows through a sequence of processing stages.
 Notations used to represent the model (Figure 8.4):
1) Oval represents functional processing.
2) Rectangle represents data stores.
3) Labeled arrow represents data movements between functions.
Figure 8.4 Data-flow diagram of library loans system
State Machine Model
 This shows how the system reacts to internal & external events.
 This does not show the flow of data within the system.
 Assumption: At any time, the system is in one of the possible states.
 When a stimulus is received, the system changes from one state to another state.
 An event is something that affects the system.
 Application: Used for modeling real-time systems.
Figure 8.5: State machine model of ON/OFF button

1-9
DATA MODEL
• This is used to describe the logical structure of data processed by the system (Figure 8.7).
• Most commonly used technique is ERA model (Entity Relation Attribute).
• ERA model shows
1) Data entities
2) Associated attributes and
3) Relations b/w the entities.
• ER models are commonly used in database design.
• This can be implemented using relational databases.
Figure 8.8 Semantic data model for the library system
OBJECT MODEL
• This describes the system in terms of object-classes and their associations.
• They may be used to represent both system-data and its processing.
• An object is executable entity with the attributes and services of the class.
• A class is a set of objects with common attributes and the operations provided by each object.
• A class is represented as a rectangle.
• The rectangle contains 3 sections (Figure 8.10):
1) Name of the class is in the top section.
2) Attributes are in the middle section.
3) Operations associated with the class are in the bottom section.
Figure 8.10: Object Model of contact management system

1-10
4b. What are project management activities? Explain. (10 Marks)
Ans:
PROJECT MANAGEMENT ACTIVITIES
1) Proposal Writing
• The first stage is writing a proposal to win a contract.
• The proposal describes
i) Objectives of the project.
ii) How the objectives will be carried out.
• The proposal includes
i) Cost-estimate and
ii) Schedule-estimate.
• The proposal justifies why the project contract should be awarded to a particular organisation.
• The existence of many software organizations depends on
→ number of proposals accepted and
→ number of contracts awarded.
2) Project Planning and Scheduling
• Project planning is concerned with identifying the
i) Activities
ii) Milestones and
iii) Deliverables.
• The project plan must include the following 7 sections:
i) Introduction
 This
→ describes the objectives of the project and
→ sets out the constraints e.g. budget, time.
ii) Project Organisation
 This describes
→ how the project-team is organized and
→ what are the roles of project-member.
iii) Risk Analysis
 This describes
→ possible project risks
→ likelihood of the risks arising and
→ risk reduction strategies.
iv) Hardware & Software Resource Requirements
 This specifies the hardware and the support-software required to carry out the
development.
v) Work Breakdown
 This
→ sets out the breakdown of the project into activities and
→ identifies the milestones/deliverables associated with each activity.
vi) Project Schedule
 This shows the dependencies between
i) Activities
ii) Estimated time required to reach each milestone and
iii) Allocation of people to activities.
vii) Monitoring & Reporting Mechanisms
 This defines
→ management-reports that should be produced and
→ project-monitoring mechanisms used.
3) Project Cost
• Cost estimation is concerned with estimating resources required to accomplish the project-plan.
4) Project Monitoring & Reviews
• Project monitoring is a continuing project-activity.
• The manager must
→ keep track of the progress of the project and
→ compare actual & planned progress.
• Project reviews are concerned with
→ reviewing overall progress of the project and
→ checking whether the project and the goals of the organization are aligned.

1-11
5) Personnel Selection & Evaluation
• Project-managers must select people to work on their project.
• Project-managers have to settle for a less-than-ideal project-team. The reasons for this are:
i) The project-budget may not cover the use of highly paid staff.
ii) Staff with the appropriate experience may not be available.
iii) The organisation may wish to develop the skills of its employees.
6) Report Writing & Presentations
• Project managers are usually responsible for reporting on the project to both
i) Client and
ii) Contractor organisations.
• They have to write brief documents that abstract critical information from detailed project
reports.

1-12
5a. With an example describe the repository-model and give its advantages and
disadvantages. (10 Marks)
Ans:
REPOSITORY-MODEL
• In a system, the subsystems exchange information so that they can work together effectively.
• Information can be exchanged in 2 ways.
1) Centralized
 All shared data is held in a central-database (Figure 11.2).
 These data can be accessed by all subsystems.
2) Distributed
 Each subsystem maintains its own database.
 Data is interchanged with other subsystems by passing messages to them.
• The systems that use large amounts of data are organized around a shared-database (or
repository).
• This model is suitable to applications where
→ data is generated by one sub-system and
→ data is used by another sub-system.
• Examples include
→ control/CAD systems
→ management information system (MIS) and
→ CASE toolsets.
Figure 11.2 The architecture of an integrated CASE toolset
ADVANTAGES OF REPOSITORY-MODEL
1) Efficient Data Sharing
 Large amount of data can be shared efficiently.
 There is no need to transmit data explicitly from one sub-system to another.
2) Data Independence
 Subsystems need not be concerned with how data is produced.
3) Centralized Management
 Following activities are centralized: i) Backup ii) Security and iii) Access control
 These activities are the responsibility of the repository-manager.
 Tools can focus on their principal function rather than be concerned with these issues.
4) Easy Integration
 It is easy to integrate new tools if they are compatible with the agreed data model.
DISADVANTAGES OF REPOSITORY-MODEL
1) Subsystems must agree on a repository data-model
 Obviously, this is a compromise between the specific needs of each tool.
 Performance may be badly affected by this compromise.
 It may be difficult to integrate new sub-systems if they are not compatible with the
agreed data model.
2) Data-Evolution is difficult & expensive
 A large amount of information is generated.
 Translating agreed data model to a new model is expensive.
3) No scope for specific management policies
 Different subsystems may have different requirements for security/backup policies.
 The repository-model forces the same policy on all sub-systems.
4) Difficult to distribute efficiently
 In distribute repository, there may be problems with data redundancy & inconsistency.

1-13
5b. Draw and explain state diagram for a typical weather station. (10 Marks)
Ans:
STATE MACHINE MODEL
• This is a dynamic model (Figure 14.14).
• This shows how the system reacts to internal & external events.
• This does not show the flow of data within the system.
• Assumption: At any time, the system is in one of the possible states.
• When a stimulus is received, the system changes from one state to another state.
• An event is something that affects the system.
• Application: Used for modeling real-time systems.
• Notations used to represent the model:
1) The rounded rectangles represent system states. They include a brief description of the
actions taken in that state.
2) The labelled arrows represent stimuli that force a transition from one state to another.
Figure 14.14 State diagram for WeatherStation
EXPLANATION OF WEATHERSTATION SYSTEM
1) If a startup() message is received, the system moves from Shutdown state to Waiting
state.
2) In the Waiting state, the system expects further messages.
 If a shutdown() message is received, the system moves from Waiting state to
Shutdown state.
3) If a reportWeather() message is received, the system moves to the Summarising
state.
 When the summary is complete, the system moves to a Transmitting state.
 In Transmitting state, the information is transmitted.
 The system then returns to the Waiting state.
4) If a calibrate() message is received, the system moves to the Calibrating state, then
the Testing state, and then the Transmitting state, and finally the to the Waiting state.
 If a test() message is received, the system moves directly to the Testing state.
5) If a signal from the clock is received, the system moves to the Collecting state.
 In Collecting state, the system is collecting data from the instruments.
 Each instrument is instructed in turn to collect its data.

1-14
6a. Explain the principles of agile methods. (06 Marks)
Ans:
PRINCIPLES OF AGILE METHODS
1) Customer Involvement
• Customers should be closely involved throughout the development process.
• Customer’s role:
→ provide and priorities new system requirements.
→ evaluate the iterations of the system.
2) Incremental Delivery
• The software is developed in increments.
• The customer specifies the requirements to be included in each increment.
3) People not Process
• The skills of the development-team should be recognized and exploited.
• Team members should be left to develop their own ways of working w/o prescriptive processes.
4) Embrace Change
• Expect the system-requirements to change, so design system to accommodate these changes.
5) Maintain Simplicity
• Focus on simplicity in both
→ developed software and
→ development process.
• Wherever possible, actively work to eliminate complexity from the system.
6b. What is pair programming? Explain its advantages. (06 Marks)
Ans:
• The programmers work in pairs to develop the software.
• They actually sit together at the same workstation to develop the software.
• Development does not always involve the same pair of people working together.
• Basic idea: Pairs are created dynamically so that all group-members may work with other
members in a pair.
• Advantages:
1) Supports the idea of common ownership & responsibility for the system.
 The software is owned by the team as a whole.
 The individuals are not held responsible for problems with the code.
 The team has collective responsibility for resolving the problems.
2) Acts as an informal review process.
 Each line of code is looked at by at least 2 people.
 Code inspections/reviews are very successful in discovering a high percentage of errors.
 Drawbacks of code inspections/reviews:
i) They are time consuming to organize.
ii) They introduce delays into the development-process.
 Advantage: Pair programming is a much cheaper inspection process than formal
program inspections.
3) Helps to support refactoring.
 Refactoring is a process of software-improvement.
 Principle of extreme programming:
The software should be constantly re-factored i.e. the code should be rewritten to
improve their clarity or structure.
 Drawbacks of refactoring:
i) This is effort that is used for long-term benefit.
ii) Individual who practices refactoring is judged less efficient than s/w developer.
 If pair programming and collective ownership are used, then others benefit immediately
from the refactoring so they are likely to support the process.

1-15
6c. Explain Lehman’s laws of program evolution dynamics. (08 Marks)
Ans:
LEHMAN’S LAWS
1) Continuing Change
• A program that is used in a real-world environment necessarily must change.
• The program necessarily becomes progressively less useful in that environment.
2) Increasing Complexity
• As an evolving program changes, its structure tends to become more complex.
• Extra resources must be dedicated to preserving and simplifying the structure.
3) Large Program Evolution
• Program evolution is a self-regulating process.
• System attributes such as size & time is approximately invariant for each system release.
4) Organisational Stability Approximately
• Over a program’s lifetime,
→ Program’s rate of development is constant.
→ Program’s rate of development is independent of resources used for system development
5) Conservation of Familiarity
• Over the lifetime of a system, the incremental change in each release is approximately
constant.
6) Continuing Growth Increase
• The functionality offered by systems has to continually to maintain user satisfaction.
7) Declining Quality
• The quality of systems will decrease if they are not adapted to changes in their operational
environment.
8) Feedback System
• Evolution processes incorporate multi-agent, multi-loop feedback systems.
• You have to treat them as feedback systems to achieve significant product improvement.
7a. Briefly explain the roles in inspection process. (06 Marks)
Ans:
INSPECTION ROLES
1) Author or Owner
 He is responsible for
→ producing the program
→ fixing defects.
2) Inspector
→ finding errors/inconsistencies in programs
→ identifying broader issues that are outside the scope of the inspection-team.
3) Reader
 He is responsible for presenting the code at an inspection-meeting.
4) Scribe
 He is responsible for recording the results of the inspection-meeting.
5) Chairman or Moderator
→ managing the process
→ facilitating the inspection and
→ reporting process-results to the chief-moderator.
6) Chief Moderator
→ inspection process improvements
→ checklist updating and
→ standards development.

1-16
7b. Explain clean room software development. (06 Marks)
Ans:
CLEANROOM SOFTWARE DEVELOPMENT
• Objective: to develop a zero-defect software.
Figure 22.10 The Cleanroom development process
• The software-development is based on 5 key strategies (Figure 22.10):
1) Formal Specification
 The software to be developed is formally specified.
 A state-transition-model is used to express the specification.
 The state-model shows system-responses to stimuli.
2) Incremental Development
 The software is divided into increments that are developed and validated separately.
 These increments are specified, with customer-input, at an early stage in the process.
3) Structured Programming
 A limited number of constructs are used.
 The aim is to systematically transform the specification to create the program-code.
4) Static Verification
 The developed-software is statically verified using software-inspections.
 There is no unit-testing process for code-components.
5) Statistical Testing of the System
The integrated-software is tested statistically to determine its reliability.
• Three teams in the system-development:
1) Specification Team
 This team is responsible for developing and maintaining the system-specification.
 This team produces
→ customer-oriented specifications (the user requirements definition) and
→ mathematical specifications for verification.
2) Development-team
 This team has the responsibility of developing/verifying the software.
 The software is not executed.
3) Certification Team
 This team is responsible for developing set of statistical tests to check developed s/w.
 These tests are based on the formal-specification.

1-17
7c. Explain general model of testing with the help of block diagram (08 Marks)
Ans:
GENERAL MODEL OF TESTING
• Test-cases are specifications of
→ inputs to the system
→ expected-output from the system
→ statement of what is being tested (Figure 23.2).
• Test-data are the inputs devised to test the system.
• Test-data can sometimes be generated automatically.
But automatic test case generation is impossible.
• The output of the tests can only be predicted by people who understand the system.
• Testing has to be based on a subset of possible test cases.
• Ideally, software companies should have policies for choosing the subset of possible test cases.
• The policies might be based on
→ general testing-policies.
→ experience of system-usage.
• For example:
1) All program statements should be executed at least once.
2) All system functions that are accessed through menus should be tested.
3) Combinations of functions that are accessed through the same menu must be tested.
4) Where user-input is provided, all functions must be tested with both correct & incorrect
input.
Figure 23.1 Testing phases
Figure 23.2 A model of the software testing process
• The managers have to make decisions on who should be responsible for the different stages of
testing.
• Different types of testing:
1) Component Testing
 This is the process of testing individual components in the system (Figure 23.1).
 Main goal:
→ To expose faults in the components.
 The developers of components are responsible for component-testing.
2) Integration Testing
 The integration team
→ integrates the modules from different developers
→ builds the software and
→ tests the system as a whole.
3) System Testing
 System Testing has to be based on a written system specification.
 This can be
→ detailed system-requirements specification or
→ higher-level user-oriented specification.
 A separate team is normally responsible for system testing.
 The testing-team works from the user/system-requirements documents to develop
testing-plans.

1-18
8a. Explain any five factors governing staff selection. (05 Marks)
Ans:
FACTORS GOVERNING STAFF SELECTION
1) Application-domain Experience
• Main requirements of developer are:
i) The developers must understand the application-domain.
ii) The developers must have some domain experience.
2) Platform Experience
• If low-level programming is involved;
Then platform experience may be important attribute;
Otherwise, platform experience is not a critical attribute.
3) Programming Language Experience
• This is an important attribute for
→ short-duration projects or
→ where there is not enough time to learn a new language.
• Learning a language itself is easy task.
• But, it takes several months to become expert in using the associated libraries/components.
4) Problem Solving Ability
• This is important for software engineers who constantly have to solve technical problems.
• However, it is not possible to judge without knowing the work of the group-member.
5) Educational Background
• This provides an indication of
→ what the candidate knows and
→ what is his ability to learn new concepts.
• This factor becomes irrelevant as engineers gain experience across a range of projects.
6) Communication Ability
• There must be proper oral/writing communication among
i) Project-staff
ii) Other engineers
iii) Project-managers and
iv) Customers.
7) Adaptability
• Adaptability may be judged by looking at the experience that candidates have had.
• This is an important attribute, as it indicates an ability to learn.
8) Attitude
• Project-staff should have a positive attitude toward their work.
• Project-staff should be willing to learn new skills.
9) Personality
• Candidates must be reasonably compatible with other group-members.
• No particular type of personality is more or less suited to software engineering

1-19
8b. What are the factors that influence group working? (05 Marks)
Ans:
FACTORS INFLUENCING GROUP WORKING
1) Group Composition
• Is there the right balance of skills, experience & personalities in the team?
• Group composed of members who share the same motivation can be problematic.
• Different types of problems are:
i) Task-oriented: Everyone wants to do their own thing.
ii) Self-oriented: Everyone wants to be the boss.
iii) Interaction-oriented: Too much chatting, not enough work.
• An effective group has a balance of above 3 types.
2) Group Cohesiveness
• Does the group think of itself as
→ team or
→ collection of individuals who are working together?
• In a cohesive group, members consider the group to be more important than any individual in
the group.
• Advantages of a cohesive group:
i) Group quality standards can be developed.
ii) Group-members work closely together so problems caused by ignorance are reduced.
iii) Group-members learn from each other and get to know each other’s work.
• Egoless programming where members try to improve each other’s programs can be practiced.
3) Group Communications
• Do the members of the group communicate effectively with each other?
• Good communications are essential for effective group-working.
• Information must be exchanged on
→ status of work and
→ design-decisions
• Good communications also strengthens group-cohesion as it promotes understanding.
Key Factors influencing the Effectiveness of Communication:
i) Group Size
 The larger the group, the harder it is for people to communicate with other group-
members.
 The number of one-way communication links is n*(n – 1), where n is the group-size.
For ex: With a group of 8 members, some people may rarely communicate.
 Status differences b/w group-members means that communications are often one-way.
 Higher-status members tend to dominate communications with lower-status members.
ii) Group Structure
 Communication is better in informally structured-groups than in hierarchically
structured-groups.
 Drawbacks of hierarchical groups:
i) Communications tend to flow up & down the hierarchy.
ii) People at the same level may not talk to each other.
iii) This is a serious problem in a large project with several development-groups.
iv) The project may suffer delays and misunderstandings.
iii) Group Composition
 Communication is better
→ when there are different personality types in a group and
→ when groups are mixed rather than single sex.
 Women tend to be more interaction-oriented than men.
 Women may act as interaction controllers and facilitators for the group.
iv) Physical Work Environment
 Good workplace organization can help encourage communications.
4) Group Organization
• Is the team organized in such a way that
→ everyone feels valued and
→ everyone is satisfied with his role in the group?
• Small groups are usually organized informally without a rigid structure.
• For large projects, there may be a hierarchical structure.
• In a hierarchical structure, different groups are responsible for different sub-projects.

1-20
8c. Explain cost estimation techniques. (10 Marks)
Ans:
COST ESTIMATION TECHNIQUES
1) Algorithmic Cost Modeling
• A model is developed using historical cost information.
• Historical cost information relates some software metric (usually its size) to the project-cost.
• An estimate is made of that metric.
• And, the model predicts the effort required.
2) Expert Judgment
• Several experts are consulted to discuss about
→ proposed s/w development techniques and
→ application-domains.
• Each expert estimates the project-cost.
• These estimates are compared and discussed.
• The estimation process iterates until an agreed estimate is reached.
3) Estimation by Analogy
• This technique is used when other projects in the same application-domain have been
completed.
• The cost of a new project is estimated by analogy with these completed projects.
4) Parkinson’s Law
• Parkinson’s Law states that work expands to fill the time available.
• The cost is determined by available resources rather than by objective assessment.
For example:
If the software has to be delivered in 12 months and 5 people are available, then
estimated-effort required = 60 person-months.
5) Pricing to Win
• The software-cost is estimated based on how much money is available with the customer.
• The estimated-effort depends on the customer’s budget and not on the software-functionality.

SOFTWARE ENGINEERING SOLVED PAPER DEC - 2013
2-1
1a. Define software, software engineering, software-process. (06 Marks)
Ans:
SOFTWARE
• Software is a set of
1) Computer-programs &
2) Associated documentation.
• A software-system consists of following programs:
1) Configuration-files used to set-up programs
2) System-documentation used to describe the structure of the system &
3) User-documentation used to explain how to use the system.
• Two types of software-products:
1) Generic Products
 These are stand-alone systems that are developed by a software-company.
 These are sold to any customer who is able to buy them.
 For example: databases & word processors.
2) Customized Products
 These are systems which are developed for a particular customer.
 A software-contractor develops the software especially for that customer.
 For example: Air-traffic control systems.
1. Problem to be solved
2. Development constraints &
3. Available Resources (Figure 1.1).
Figure 1.1: Stages in software engineering
SOFTWARE-PROCESS
• A set of activities whose goal is the development of software.
• Four main activities:
1) Software Specification
 This answers questions like:
i) What does the customer need?
ii) What are the constraints?
2) Software Development
 Software is designed & programmed.
3) Software Validation
 Software is checked to ensure that it meets the needs of the customer
4) Software Evolution
 Software is modified to adapt to changing i) Customer-requirements &
ii) Market-requirements.
1b. What are attributes of good software? (08 Marks)
Ans: For answer, refer Solved Paper June-2013 Q.No.1a.
1c. Explain two types of emergent properties. (06 Marks)
Ans: For answer, refer Solved Paper June-2013 Q.No.1c.

2-2
2a. Explain system dependability. (10 Marks)
Ans:
SYSTEM DEPENDABILITY
• The dependability means the degree of user-confidence that
→ system will operate as the user expects and
→ system will not 'fail' in normal use.
• Four main dimensions to dependability (Figure 3.3):
1) Availability
 The probability that the system will be able to deliver useful services at any given time.
2) Reliability
 The probability that the system will correctly deliver services as expected by the user.
3) Safety
 A judgment of how likely that the system will cause damage to
i) People or
ii) System-environment.
4) Security
 A judgment of how likely that the system can resist accidental or deliberate intrusions.
Figure 3.3 Dimensions of dependability
• Further, the above 4 dimensions can be divided into a number of simpler properties.
• For example:
1) Security includes
i) Integrity: Ensuring system’s program & data are not damaged
ii) Confidentiality: Ensuring info. can only be accessed by authorized-people.
2) Reliability includes
i) Correctness: Ensuring the system-services are as specified.
ii) Precision: Ensuring information is delivered at an appropriate level of detail.
iii) Timeliness: Ensuring the information is delivered when it is required.
• Four system-properties of dependability:
1) Repairability
 The disturbance caused by failure can be minimized if system can be repaired quickly.
 To repair quickly, it must be possible to
→ diagnose the problem
→ access the faulty-component &
→ make changes to fix the component.
 Repairability is improved when the organisation using the system
→ has access to the source-code &
→ has the skills to make changes to the source-code.
2) Maintainability
 As systems are used, new requirements emerge.
 Maintainable-software can be adapted economically to cope with new requirements.
 There is a low probability that making changes will introduce new errors into system.
3) Survivability
 The ability of a system to continue to deliver service while it is under attack.
 Work on survivability focuses on
→ identifying key components &
→ ensuring the components can deliver a minimal service.

2-3
 Three strategies to improve survivability:
i) Resistance to attack
ii) Attack recognition &
iii) Recovery from the damage caused by an attack.
 Survivability is a very important attribute for Internet-based systems.
4) Error Tolerance
 The extent to which the system is designed so that user input-errors are tolerated.
 When user-errors occur, the system should detect the errors.
 The system should either
→ fix the errors automatically or
→ request the user to re-input the data.
 Error tolerance can be considered as part of usability.

2-4
2b. Explain the process iteration. (10 Marks)
Ans:
PROCESS ITERATION
• Most often, change is inevitable in large software-projects.
• System-requirements change as business procuring the system responds to external pressures.
• Management priorities change.
• As new technologies become available, designs & implementation change.
• The software-process is not a one-off process.
Rather, the process-activities are regularly repeated as system is re-worked.
• Two process models:
1) Incremental Delivery
 The software is divided into increments that are developed and validated separately.
 These increments are specified, with customer-input, at an early stage in the process.
2) Spiral Development
 This is a software development approach which is a combination of
→ an iterative nature of prototyping and
→ systematic aspects of waterfall model.
 Each loop represents a stage of the software-process.
 Each loop is split into 4 sectors (Figure 4.5):
1) Objective Setting
 Objectives for each stage of the project are defined.
 Constraints on the process are identified.
 Project-risks are identified.
 Alternative strategies are planned.
2) Risk Assessment & Reduction
 This involves
→ identifying the risks associated with activities and
→ taking steps to reduce those risks.
3) Development & Validation
 A development-model for system is chosen which can be any generic models.
 Generic models may be waterfall model or spiral model.
4) Planning
 The project is reviewed.
 The next phase of the spiral is planned.
Figure 4.5 Spiral model of the software-process

2-5
3a. Explain requirement validation. (10 Marks)
Ans:
REQUIREMENT VALIDATION
• This is concerned with demonstrating that the requirements define the system that the
customer really wants.
• Requirements validation overlaps analysis in that it is concerned with finding problems with the
requirements.
• Requirement validation is important because
errors in requirement document can lead to extensive rework/cost, when they are
discovered during development or after the system is in service.
REQUIREMENT CHECKLIST
1) Validity Check
 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.
2) Consistency Check
 Requirements in the document should not conflict i.e. there should be no contradictory
constraints or descriptions of the same system function.
3) Completeness Check
 The requirement document should include requirements, which define all functions
intended by the system-user
4) Realism Checks
 Using knowledge of existing technology, the requirements should be checked to ensure
that they could 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.
 You should be able to write a set of tests that can demonstrate that the delivered
system meets each specified requirement.
REQUIREMENTS VALIDATION TECHNIQUES
1) Requirements reviews
 The requirements are analysed systematically by a team of reviewers.
2) Prototyping
 In this approach to validation, an executable model of the system 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
 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.
 Developing tests from the user requirements before any code is written is an integral
part of extreme programming.
3b. Give software requirement document (IEEE standard). (10 Marks)

2-6
4a. Explain structured methods. (10 Marks)
Ans:
STRUCTURED METHOD
• This is a systematic way of producing models of a system.
• They have their own preferred set of models.
• They define
→ processes used to derive the models and
→ set of rules that apply to the models.
• Standard documentation is produced for the system.
• CASE tools are available for method-support.
• CASE tools support
→ model editing and
→ code/report generation.
• Advantages:
1) They are used successfully in many large projects.
2) They help in cost reductions.
3) They ensure that standard design documentation is produced.
• Disadvantages:
1) They are not suitable for modeling non-functional system-requirements.
2) They produce too much documentation.
3) The models are very detailed, and users often find them difficult to understand.
4) They do not include guidelines to help users.
Figure 8.15: The components of a CASE tool for structured method support
• Full method-support tools include (Figure 8.15):
1) Diagram Editors
 The editors are used to create
→ object-models
→ data-models &
→ behavioral-models.
 These editors are aware of the types of entities in the diagram.
 They
→ capture information about the entities and
→ save the information in the central repository.
2) Design Analysis & Checking Tools
 These tools
→ process the design and
→ report on error.
 These tools may be integrated with the editing-system.
Thus, user-errors can be trapped at an early stage in the process.
3) Repository Query Languages
 These languages allow the designer to find designs and associated design-information in
the repository.
4) Data Dictionary
 This maintains information about the entities used in a system-design.

2-7
5) Report Definition and Generation Tools
 These tools
→ take information from the central-store and
→ generate system-documentation automatically.
6) Forms Definition Tools
 These tools are used to specify screen and document formats.
7) Import/Export Facilities
 These allow the interchange of information between
→ central-store &
→ other development tools.
8) Code Generators
 These generate code (or code-skeletons) automatically from the design captured in the
central-store.

2-8
4b. Explain risk management. (10 Marks)
Ans:
RISK MANAGEMENT
• The basic idea is
1) Identify possible risks.
2) Then, draw up plans to minimize their effect on a project.
• Risk management has 4 stages: 1) Risk Identification 2) Risk Analysis
3) Risk planning 4) Risk Monitoring
1) Risk Identification
 Possible i) Project-risk, ii) Product-risk and iii) Business-risk are identified.
 Six types of risk (Figure 5.11):
1) Technology Risks
 Risks derived from the s/w & h/w technologies used to develop the system.
2) People Risks
 Risks that is associated with the people in the development-team.
3) Organizational Risks
 Risks derived from organisational environment where s/w is being developed.
4) Tools Risks
 Risks derived from the CASE tools & other support s/w used to develop system.
5) Requirements Risks
 Risks derived from changes to the customer-requirements.
6) Estimation Risks
 Risks derived from management estimates of tine/resources required to build the
system.
2) Risk Analysis
 Each identified risk is considered.
 A judgment is made about the probability and the seriousness of each risk (Fig 5.14).
 The risk estimates is based on a number of bands. For example,
i) The probability of the risk may be assessed as
→ low (<25%)
→ moderate (25-50%)
→ high (>75%) or
ii) The effects of the risk may be assessed as
→ serious
→ tolerable or
→ insignificant.

2-9
3) Risk Planning
 The basic idea is
1. Consider each identified risks.
2. Then, identify strategies to manage the risk.
 Three categories of strategies (Figure 5.13):
1) Avoidance Strategies
 The probability that the risk will arise will be reduced.
2) Minimization Strategies
 The impact of the risk will be reduced.
3) Contingency Plans
 You are prepared for the worst and have a strategy in place to deal with it.
4) Risk Monitoring
 The risk is constantly assessed.
 Plans for risk-reduction are revised as more info. about the risk becomes available.
 Risk monitoring should be a continuous process.
 At every progress-review, you should consider & discuss each of key risks separately.

2-10
5a. Explain system organization. (10 Marks)
Ans:
SYSTEM ORGANIZATION
• This shows the basic strategy used to organize a system.
• Three organisational-styles can be used:
1) Repository model
2) Client-server model and
3) Layered model or abstract machine
1) REPOSITORY MODEL
• In a system, the subsystems exchange information so that they can work together effectively.
• Information can be exchanged in 2 ways.
1) All shared-data is held in a central-database (Figure 11.2).
 These data can be accessed by all subsystems.
2) Each subsystem maintains its own database.
 Data is interchanged with other subsystems by passing messages to them.
Figure 11.2 The architecture of an integrated CASE toolset
• Advantages:
1) Efficient Data Sharing
2) Data Independence
3) Centralized Management
4) Easy Integration
• Disadvantages:
1) Subsystems must agree on a repository data-model.
2) Data-evolution is difficult and expensive.
3) No scope for specific management policies.
4) Difficult to distribute efficiently.
2) CLIENT-SERVER MODEL
• This is a distributed system-model.
• Three major components:
i) Servers
 A set of servers provide specific services such as printing, data management, etc.
ii) Clients
 A set of clients call on the services offered by servers.
iii) Network
 A network allows the clients to access the servers (Figure 11.3).
Figure 11.3 The architecture of a film and picture library system

2-11
• Clients have to know names of the available-servers.
However, servers need not know names of the available-clients.
• Clients access the services provided by a server through RPC (remote procedure call).
• Advantages:
1) Distribution of data is easy.
2) Easy maintenance.
3) Flexibility: Easy to add new servers or upgrade existing servers.
4) Scalability: Any element can be upgraded when needed.
5) Centralization: Access, resources and data security are controlled through the server.
• Disadvantages:
1) No shared data-model across servers.
2) Subsystems may organize their data in different ways.
3) Data interchange may be inefficient.
4) No central register of names and services. It may be hard to find out what servers and
services are available.
5) Single point of failure: When servers go down, all operations stop.
3) LAYERED MODEL (ABSTRACT MACHINE MODEL)
• This model organizes a system into a set of layers (Figure 11.4).
• Each layer provides a set of service to the layer above it.
• Each layer can be thought of as an abstract-machine whose machine-language is defined by the
services provided by the layer.
• This machine language is used to implement the next level of abstract-machine.
• Example: OSI reference model of network protocols.
Figure 11.4 Layered model of a version management system
• Advantages:
1) Can be used to model the interfacing of subsystems.
2) Supports incremental development.
3) Changeable: When new facilities are added to a layer, only the adjacent layer is
affected.
4) Easier to provide multi-platform implementations of an application-system.
• Disadvantages:
1) Structuring systems into layers is difficult.
2) Performance is degraded ‘.’ of the multiple levels of command interpretation.
5b. Give state diagram for weather station and explain design evaluation. (10 Marks)
Ans: For answer, refer Solved Paper June-2013 Q.No.5b.

2-12
6a. Explain extreme programming. (10 Marks)
Ans:
EXTREME PROGRAMMING (XP)
• Extreme programming is perhaps the best known and most widely used of the agile methods.
Figure 17.4 The extreme programming release cycle
• Extreme programming practices are(Figure 17.4):
1) Incremental Planning
 Requirements are recorded on Story Cards.
 The Stories to be included in a release are determined by the time available and their
relative priority.
 The developers break these Stories into development ‘Tasks’.
2) Small Releases
 The minimal useful set of functionality that provides business value is developed first.
 Releases of the system are frequent and incrementally add functionality to the first
release.
3) Simple Design
 Enough design is carried out to meet the current requirements and no more.
4) Test-first development
 An automated unit test framework is used to write tests for a new piece of functionality.
 Then, that functionality itself is implemented.
5) Refactoring
 All developers are expected to refactor the code continuously as soon as possible code
improvements are found.
 This keeps the code simple and maintainable.
6) Pair Programming
 Developers work in pairs.
 They check each other’s work.
 They provide the support to always do a good job.
7) Collective Ownership
 The pairs of developers work on all areas of the system.
 Thus, all the developers own all the code.
 Anyone can change anything.
8) Continuous Integration
 As soon as work on a task is complete it is integrated into the whole system.
 After any such integration, all the unit tests in the system must pass.
9) Sustainable Pace
 Large amounts of overtime are not acceptable.
 This is because the net effect is often to reduce code quality and medium-term
productivity.
10) On-site Customer
 A representative of the end-user of the system (the Customer) should be available full
time for the use of the XP team.
 The customer is a member of the development-team.
 The customer is responsible for bringing system requirements to the team for
implementation.
6b. Give Lehman’s laws. (10 Marks)

2-13
7a. Explain clean room software development. (10 Marks)
Ans:
CLEANROOM SOFTWARE DEVELOPMENT
• Objective: to develop a zero-defect software.
Figure 22.10 The Cleanroom development process
• The software-development is based on 5 key strategies (Figure 22.10):
1) Formal Specification
 The software to be developed is formally specified.
 A state-transition-model is used to express the specification.
 The state-model shows system-responses to stimuli.
2) Incremental Development
 The software is divided into increments.
 The increments are developed and validated separately.
 Critical customer functionality is delivered in early increments.
 Less important system functions are included in later increments.
3) Structured Programming
 A limited number of constructs are used.
 The program development process is a process of stepwise refinement of the
specification.
 The aim is to systematically transform the specification to create the program-code.
4) Static Verification
 The developed-software is statically verified using software-inspections.
 A state model of the system is produced as a system specification.
 This is refined through series of more detailed system models to executable program.
 The approach attempts to preserve the correctness at each transformation to a more
detailed representation.
 The vast majority of defects
→ are discovered before execution and
→ are not introduced into the developed software.
 There is no unit-testing process for code-components.
5) Statistical Testing of the System
 The integrated-software is tested statistically to determine its reliability.
 These statistical tests are based on an operational profile.
 Operational profile is developed in parallel with the system specification
• Three teams in the system-development:
1) Specification Team
 This team is responsible for developing and maintaining the system-specification.
 This team produces
→ customer-oriented specifications (the user requirements definition) and
→ mathematical specifications for verification.
 In some cases, when the specification is complete, the specification team also takes
responsibility for development.
2) Development Team
 This team has the responsibility of developing and verifying the software.
 The software is not executed during the development process.
 A structured, formal approach to verification based on inspection of code supplemented
with correctness arguments is used.

2-14
3) Certification Team
 This team is responsible for developing a set of statistical tests to exercise the software
after it has been developed.
 These tests are based on the formal-specification.
 Test case development is carried out in parallel with software development.
The test cases are used to certify the software reliability.
 Reliability growth models may be used to decide when to stop testing.

2-15
7b. Explain component testing. (10 Marks)
Ans:
COMPONENT TESTING
• This is also called as unit testing.
• This is the process of testing individual components in the system.
• Main goal: To expose faults in the components.
• The developers of components are responsible for component-testing.
• Component may be:
1) Individual functions or methods (Figure 23.6).
2) Object-classes that have attributes and methods.
3) Composite components made up of different objects or functions.
• Individual functions are the simple components.
Your tests are a set of calls to these functions with different input parameters.
• Object class testing should include:
1) Testing of all operations associated with the object.
2) Setting and interrogation of all attributes associated with the object.
3) Exercising the object in all possible states i.e. all events that change states in the
object should be simulated.
Figure 23.6 The weather station object interface
Figure 14.14 State diagram for WeatherStation
• The weather station interface has a single attribute named identifier (Figure 14.14).
 identifier is a constant that is set when the weather station is installed.
 You therefore only need a test that checks whether it has been set up.
• You need to define test cases for reportWeather(), calibrate(), test(), startup() and shutdown().
• You should test methods in some sequences.
For examples:
Shutdown → Waiting → Shutdown
Waiting → Calibrating → Testing → Transmitting → Waiting
Waiting → Collecting → Waiting → Summarising → Transmitting → Waiting
Problem with Inheritance
• Inheritance makes it more difficult to design object tests, as the information to be tested is not
localized.
• In case of superclass, all of the subclasses should be tested with all inherited operations.
• This is because the inherited operation may make assumptions about other
operations/attributes, which might have been changed when inherited.
• When a superclass operation is overridden, then the overwriting operation must be tested.

2-16
8a. Explain factors affecting software engineering productivity. (5 Marks)
Ans:
FACTORS AFFECTING SOFTWARE ENGINEERING PRODUCTIVITY
1) Application-Domain Experience
• Knowledge of the application-domain is an important attribute for effective software-
development.
• Engineers who already understand a domain are likely to be the most productive.
2) Process Quality
• The development-process used can have a significant effect on productivity.
3) Project Size
• For a larger project.
More time is required for team-communications.
Hence, less time is available for development.
So, individual productivity is reduced.
4) Technology Support
• Good support technology such as CASE tools and configuration management systems can
improve productivity.
5) Working Environment
• A quiet working-environment with private work areas contributes to improved productivity.
8b. Give factors governing staff selection. (10 Marks)
8c. Explain cost estimation techniques. (5 Marks)

3-1
1a. Answer the following frequently asked questions about software engineering:
i) Difference between software engineering and system engineering.
ii) What are key challenges facing software engineering?
iii) What is a software-process model? (06 Marks)
Ans (i):
Figure 1.1: Stages in software engineering Figure 2.2 The systems engineering process
1. Problem to be solved
2. Development constraints &
3. Available Resources (Figure 1.1).
SYSTEM ENGINEERING
• This is the activity of
→ specifying, designing, implementing, validating & maintaining socio-technical systems.
• System-engineers are concerned with
→ software & hardware and
→ system's interactions with users & its environment (Figure 2.2).
• Software-engineering is part of system-engineering.
Ans (ii):
KEY CHALLENGES FACING SOFTWARE ENGINEERING
1) Heterogeneity Challenge
• Increasingly, systems are required to operate across networks that include
→ different types of computers
→ different kinds of support-systems &
→ different platforms.
• Most often, it is necessary to integrate new software with older legacy-systems.
• The challenge is
“The challenge of developing techniques for building software. The software must be
flexible enough to deal with this heterogeneity”.
2) The Delivery Challenge
• Many traditional software-engineering techniques are time-consuming.
• Nowadays, businesses change rapidly. So, their supporting-software must change rapidly.
“shortening delivery-times for large-systems without compromising on quality”.
3) The Trust Challenge
• As software is a part of our lives (work, study), it is essential that we can trust that software.
• This is true for remote-systems accessed through a web-page interface.
“Develop techniques which demonstrate that the software can be trusted by the end-users”.
Ans (iii): For answer, refer Solved Paper Dec-2014 Q.No.1a.
1b. What are emergent system properties? Give examples. Explain the types of
emergent properties. (08 Marks)

3-2
1c. Define legacy systems. Explain the layered model of a legacy system. (06 Marks)
Ans:
LEGACY SYSTEMS
• These systems are socio-technical systems.
• These systems have been developed in the past using older technology.
• These systems consists of
→ hardware & software
→ legacy-processes &
→ legacy-procedures.
• These systems are business-critical systems.
• These systems are maintained because it is too risky to replace them.
Figure 2.11 Legacy system components
• Logical parts of legacy-system (Figure 2.11):
1) System Hardware
 In many cases, legacy-systems have been written for mainframe-hardware.
 The mainframe-hardware is
→ No longer available &
→ Expensive to maintain.
 The mainframe-hardware may not be compatible with current organizational-policies.
2) Support Software
 Legacy-system depends on OS & compilers provided by the old hardware-manufacturer.
 These softwares may be no longer supported by their original providers.
3) Application Software
 The application-system is composed of a number of separate programs.
 The programs have been developed at different times.
4) Application Data
 These are the data that are processed by the application-system.
 A huge amount of data has accumulated over the lifetime of the system.
5) Business Processes
 These processes are used in the business to achieve some business-objective.
 Business-processes may be
→ designed around a legacy-system &
→ constrained by the system‟s functionality.
6) Business policies and Rules
 These are definitions of
→ how the business should be carried-out &
→ constraints on the business.

3-3
2a. What are the types of critical systems? Define. Write a simple safety critical system
and explain. (09 Marks)
2b. Explain the evolutionary development and its problems. (06 Marks)
Ans:
EVOLUTIONARY DEVELOPMENT
• This is also called as iterative model (Figure 4.2).
• Basic idea is:
1) Developers produce an initial version of the system rapidly.
2) Customers use the system & give feedback.
3) Developers modify the system based on the feedback.
4) Repeat steps 2 and 3 until customers are satisfied.
Figure 4.2 Evolutionary development
• Two types:
1) Exploratory Development
 The objective is to work with the customer to
→ explore the customer‟s requirements and
→ deliver a final-system.
 The development starts with the understood-parts of the system.
 The system evolves by adding new features proposed by the customer.
2) Throwaway Prototyping
 Main objectives:
i) Understand the customer-requirements &
ii) Develop a better requirements-definition for the system.
 The prototype concentrates on experimenting with the customer-requirements.
• Advantages:
1) Specification can be developed incrementally.
2) Suitable for development of small and medium-sized systems.
3) Some working functionality can be developed quickly and early in the life cycle.
4) Parallel development can be planned.
5) It supports changing customer-requirements.
6) Users get a feel for the actual system in early stage.
• Disadvantages:
1) The process is not visible
 Managers need regular-deliverables to measure progress.
2) Systems are often poorly structured
 Continual change tends to corrupt the software-structure.
 Incorporating software changes, becomes increasingly difficult & costly.
 Not suitable for development of large, complex, long-lifetime systems.

3-4
2c. Write Boehm's spiral model of the software-process and explain. (05 Marks)
Ans:
SPIRAL MODEL
• This is a software development approach which is a combination of
i) Iterative nature of prototyping &
ii) Systematic aspects of waterfall model.
• Each loop represents a stage of the software-process (Figure 4.5).
• Each loop is split into 4 sectors:
1) Objective Setting
 Objectives for each stage of the project are defined.
 Constraints on the process are identified.
 A detailed management plan is drawn up.
 Project-risks are identified.
 Alternative strategies are planned.
2) Risk Assessment & Reduction
 This involves
→ identifying the risks associated with activities &
→ taking steps to reduce identified-risks.
3) Development and Validation
 A development-model for system is chosen which can be any generic models.
 Generic models may be waterfall model or spiral model.
4) Planning
 The project is reviewed.
 The next phase of the spiral is planned.
Figure 4.5 Spiral model of the software-process
• What is risk?
Ans: Situations or possible events that may cause a project to fail to meet its goal.
For example:
i) Experienced staff leaves the project.
ii) Essential hardware will not be delivered on schedule.
• Advantage:
1) Risks are explicitly assessed & resolved throughout the process.
• Disadvantages:
1) Requires highly skilled people in risk-analysis & planning.
2) Requires more time, and is more expensive.

3-5
3a. List out the notations for requirement specification with description. (06 Marks)
Ans:
NOTATIONS FOR REQUIREMENTS SPECIFICATION
1) Structured Natural Language
• This approach depends on defining standard forms (or templates) to express the requirements.
2) Design Description Language
• This approach
→ uses a language like a programming language that uses more abstract features to
specify the requirements.
→ can be useful for interface specifications.
3) Graphical Notations
• A graphical language, supplemented by text annotations is used to define the requirements.
For example: Use-case descriptions & Sequence diagrams.
4) Mathematical Specifications
• These are notations based on mathematical concepts such as finite-state machines or sets.
• These unambiguous specifications reduce the arguments between customer and contractor
about system functionality.
• However, most customers
→ don‟t understand formal specifications and
→ are reluctant to accept it as a system-contract.
3b. Write the roles of the users of a requirement document. (06 Marks)
Ans:
ROLES OF USERS OF REQUIREMENT DOCUMENT
1) System Customers
• Specify the requirements and read them to check that they meet their needs.
• Customers specify changes to the requirements.
2) Managers
• Use the requirements document to
→ plan a bid for the system and
→ plan the system development process
3) System Engineers
• Use the requirements to understand what system is to be developed.
4) System Test Engineers
• Use the requirements to develop validation tests for the system.
5) System Maintenance Engineers
• Use the requirements to understand the system and the relationships between its parts.

3-6
3c. What is Ethnography? How ethonography is effective in discovering the types of
requirement? (08 Marks)
Ans:
ETHNOGRAPHY
• Ethnography is an observational technique that can be used to understand social and
organisational requirements (Figure 7.9).
• An analyst immerses himself in the working environment where the system will be used.
• The analyst
→ observes the day-to-day work and
→ notes down actual tasks in which participants are involved.
• Ethnography helps analysts discover implicit system requirements that reflect the actual
processes in which people are involved.
How Ethnography Benefits
1) People often find it very difficult to articulate details of their work because it is second
nature to them.
2) People understand their own work but may not understand its relationship with other
work in the organisation.
3) Social and organisational factors that affect the work but that are not obvious to
individuals may only become clear when noticed by an unbiased observer.
• Two types of requirements:
1) Requirements that are derived from the way in which people actually work
For example:
 Air traffic controllers may switch off an aircraft conflict alert system that detects
aircraft with intersecting flight paths.
 Their control strategy is designed to ensure that these aircraft are moved apart
before problems occur.
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 aircraft 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.
Figure 7.9 Ethnography and prototyping for requirements analysis

3-7
4a. Draw the state machine model of a microwave oven. (06 Marks)
Ans:
STATE MACHINE MODEL OF A MICROWAVE OVEN
Figure 8.5 State machine model of a simple microwave oven
4b. What is object aggregation? Write an example showing aggregation. (04 Marks)
Ans:
OBJECT AGGREGATION
• An object is an aggregate of a set of other objects.
• A class is a set of objects with common attributes and the operations provided by each object.
• The classes may be modelled using an object aggregation model.
• A class is represented as a rectangle.
• The rectangle contains 3 sections (Figure 8.13):
1) Name of the class is in the top section.
2) Attributes are in the middle section.
3) Operations associated with the class are in the bottom section.
• The UML notation for aggregation is to represent the composition by including a diamond shape
on the source of the link.
• Figure 8.13 can be read as
„A study pack is composed of
→ one of more assignments
→ OHP slide packages
→ lecture notes and videotapes.
Figure 8.13 Aggregate object representing a course

3-8
4c. Following table shows no. of activities, durations and dependencies and milestones.
Draw a bar chart showing the critical path for the project schedule. (10 Marks)
Task
Start
Date
End date
# Days
Required
T1 1/9/16 5/9/16 5
T2 6/9/16 20/9/16 15
T3 6/9/16 15/9/16 10
T4 21/9/16 23/9/16 3
T5 21/9/16 30/9/16 10
T6 16/9/16 23/9/16 8
T7 1/10/16 10/10/16 10
T8 11/10/16 19/10/16 9
T9 11/10/16 20/10/16 10
T10 11/10/16 19/10/16 9
T11 21/10/16 9/11/16 20
T12 20/10/16 29/10/16 10
T13 10/11/16 14/11/16 5
T14 15/11/16 24/11/16 10
Figure 5.5 Task durations and dependencies

3-9
5a. According to Bas et al, what are the advantages of designing and documenting
software architecture? (05 Marks)
Ans:
1) Stakeholder Communication
• The architecture is a high-level presentation of the system.
• This presentation may be used as a focus of discussion by different stakeholders.
2) System Analysis
• Making the system architecture explicit at an early stage in the system development requires
some analysis.
• Architectural-design decisions have a strong effect on whether the system can meet critical
requirements such as
→ performance
→ reliability and
→ maintainability.
3) Large-scale Reuse
• A system architecture model is a compact, manageable description of
→ how a system is organised and
→ how the components interoperate.
• Usually, the system architecture is the same for systems with similar requirements. Thus, they
can be reused.
• It may be possible to develop product-line architectures.
• In product-line architectures, the same architecture is used across a range of related systems.

3-10
5b. Explain event driven systems. (07 Marks)
Ans:
EVENT DRIVEN SYSTEMS
• These models are driven by externally generated events.
• Each subsystem can respond to events from either
→ other subsystems or
→ environment of the system.
• The timing of the event is outside the control of the subsystems which process the event.
• The event may be
→ signal that can take a range of values or
→ command-input from a menu.
• For example: Text editors where user interface events signify editing commands.
• Two models are: 1) Broadcast models and
2) Interrupt-driven models.
1) Broadcast Models
• An event is broadcast to all the subsystems (Figure 11.9).
• Any subsystems which can handle that event respond to it.
• The event and message handler maintains
→ register of subsystems and
→ events of interest to those subsystems.
• The event handler detects the event to those subsystems that have registered an interest in the
event.
• A subsystem can send a message to another subsystem.
• Advantages:
1) Evolution is simple i.e. Useful in integrating subsystems distributed across different
computers on network.
2) Any subsystem can activate any other subsystem without knowing its name or location.
• Disadvantages:
1) Subsystems don't know if or when events will be handled.
2) Different subsystems might have registered for same events. This may cause conflicts.
Figure 11.9 A control model based on selective broadcasting
2) Interrupt-Driven Models
• These are used in real-time systems (Figure 11.10).
• The external events are detected by an interrupt handler.
• The interrupt types are identified with their respective handlers.
• Each interrupt is associated with the memory location where handlers address is stored.
• When an interrupt is received, a hardware switch causes control to be transferred immediately
to its handler.
• This interrupt handler may then start or stop other processes in response to the interrupt.
Figure 11.10 An interrupt-driven control model

3-11
• Advantage:
1) Allows very fast responses to events to be implemented.
• Disadvantages:
1) Complex to program.
2) Difficult to validate.
3) Difficult to change systems if the number of interrupts is limited.
5c. What is a sequence model? Write the sequence model of operations in collecting the
data from a weather station and explain. (08 Marks)
Ans:
SEQUENCE MODELS
• These are dynamic-models.
• These show the sequence of object-interactions.
• How to draw sequence-models (Figure 14.13):
1) The objects are arranged horizontally with a vertical line linked to each object.
2) Time is represented vertically.
3) Labeled arrows linking the vertical lines represent interactions between objects.
4) The thin rectangle on the object-lifeline represents the time when the object is the
controlling-object in the system.
Figure 14.13 Sequence of operations-data collection
EXPLAINATION OF WEATHER STATION
1) An object CommsController receives a request from its environment to send a weather report.
This object CommsController acknowledges receipt of this request.
2) The object CommsController sends a message to an object WeatherStation to create a
weather report.
The object CommsController then suspends itself.
3) The object WeatherStation sends a message to an object WeatherData to summarize the
weather data.
4) This summary is computed and control returns to the object WeatherStation.
5) The object WeatherStation sends a message to an object CommsController requesting it to
transfer the data to the remote system.
The object WeatherStation then suspends itself.
6) The object CommsController.
→ sends the summarized data to the remote system
→ receives an acknowledgement and
→ suspends itself waiting for the next request.

3-12
6a. Explain difficulties with iterative development & incremental delivery. (06 Marks)
Ans:
DRAWBACKS OF ITERATIVE DEVELOPMENT
1) Management Problems
• It may be very expensive to produce lots of system-documentation.
• Sometimes, unfamiliar technologies are used to ensure the most rapid delivery of the software.
• Managers find it difficult to use existing staff because they lack the required skills.
2) Contractual Problems
• The normal contractual model between a customer and a software developer is based around a
system-specification.
• When there is no system-specification, it is difficult to design contract for system- development.
• Customers are unhappy with a contract that simply pays developers for the time spent on the
project.
• Developers may not accept a fixed-price contract because they cannot control the changes
requested by the end-users.
3) Validation Problems
• Verification and validation are used for demonstrating that the system meets its specification.
• An independent V&V team
→ can start work as soon as the specification is available and
→ can prepare tests in parallel with the system implementation.
• Iterative development tries to
→ minimize documentation and
→ interleave specification and development.
• Hence, independent validation of incrementally developed-systems is difficult.
4) Maintenance Problems
• Continual change tends to corrupt the structure of any software.
• New developers may find the software difficult to understand.
• One way to reduce this problem is to use refactoring.
• In refactoring, software structures are continually improved during the development process.
• Furthermore, if specialized technology such as RAD is used, the RAD may become obsolete.
• Therefore, finding people who have the required knowledge to maintain the system may be
difficult.
6b. Briefly discuss the extreme programming release cycle with a diagram. (06 Marks)
Ans: For answer, refer Solved Paper Dec-2013 Q.No.6a.

3-13
6c. How software maintenance is carries out? Explain briefly. (08 Marks)
Ans:
SOFTWARE MAINTENANCE
• Software Maintenance is the general process of changing a system after it has been
delivered.
• The changes made to the software may be
→ simple changes to correct coding-errors
→ complex changes to correct design-errors or
→ accommodate new requirements.
• Three different types of software maintenance:
1) Maintenance to repair software faults
 Coding-errors are relatively cheap to correct.
 Design-errors are expensive, as they involve re-writing many program-components.
 Requirements-errors are most expensive to repair „.‟ of the extensive system re-design.
2) Maintenance to adapt the software to a different operating environment
 This type of maintenance is required when there are changes in
→ hardware or
→ platform operating system
3) Maintenance to add to or modify the system’s functionality
 This type of maintenance is required when there are changes in
→ organizational strategies or
→ business objectives
 Often, the scale of the changes required to the software is much greater than for the
other types of maintenance.
• The key factors that distinguish development & maintenance:
1) Team Stability
 After a system has been delivered,
→ normally the development-team will be broken-up and
→ people start working on new projects.
 The new team responsible for system-maintenance does not understand the system.
 During the maintenance process,
→ lot of effort is put to understand the existing system &
→ then the changes are implemented in the existing system.
2) Contractual Responsibility
 Usually, maintenance-contract is separate from the system development-contract.
 The maintenance-contract may be given to a different company rather than the original
system-developer.
3) Staff Skills
 Often, maintenance-staff is relatively inexperienced.
Maintenance-staff is unfamiliar with the application domain.
 Maintenance has a poor image among software-engineers.
 Maintenance is seen as a less skilled process than system-development.
 Maintenance is often allocated to the most junior staff.
 Furthermore, old systems may be written in obsolete programming languages.
4) Program Age & Structure
 As programs age, their structure tends to be degraded by change, so they become
harder to understand/modify.
 Some systems have been developed without modern software engineering techniques.
 Some systems may never have been well structured.
 Some systems were perhaps optimized for efficiency rather than understandability.
 System documentation may be lost or inconsistent.
 Time is often wasted finding the right versions of system components to change.

3-14
7a. Explain V-model with a neat diagram for planning verification and validation
process. (07 Marks)
Ans:
V-MODEL
• It is an instantiation of the generic waterfall model and shows that test plans should be derived
from the system specification and design.
• This model also breaks down system V & V into a number of stages.
• Each stage is driven by tests that have been defined to check the conformance of the program
with its design and specification.
• Test planning is concerned with
→ establishing standards for the testing-process
→ describing product-tests and
→ helping managers allocate resources & estimate testing-schedules.
• Test plans are intended for software engineers involved in designing and carrying out system
tests.
• They help technical staff get an overall picture of the system tests and place their own work in
this context.
Figure 22.3 Test plans as a link between development and testing
• Major components of a test-plan (Figure 22.3):
1) Testing Process
 A description of the major phases of the testing-process.
2) Requirements Traceability
 Users are most interested in the system meeting its requirements and testing should be
planned so that all requirements are individually tested.
3) Tested Items
 The products of the software-process that are to be tested should be specified.
4) Testing Schedule
 An overall testing-schedule and resource-allocation is, obviously, linked to the more
general project development-schedule.
5) Test Recording Procedures
 The results of the tests must be systematically recorded.
 Auditing of the testing-process must be done to check that it has been carried out
correctly.
6) Hardware and Software Requirements
 This section should specify the software-tools required and estimated hardware
utilization.
7) Constraints
 Constraints affecting the testing process such as staff shortages or budget should be
anticipated in this section.
7b. Explain the characteristics of clean room software development. (06 Marks)

3-15
7c. Explain any one of the approaches to test case design. (07 Marks)
Ans:
PARTITION TESTING
• The input-data and output-results of a program usually fall into a number of different classes
that have common features such as
→ positive numbers &
→ negative numbers.
• Programs normally behave in a comparable way for all members of a class.
• Because of this equivalent behaviour, these classes are also called equivalence partitions.
• The basic idea is
1) Identify input & output partitions.
2) Then, design test-cases accordingly (Figure 23.8).
• This ensures that the system
→ executes inputs from all partitions and
→ generates outputs in all partitions.
• This can be used to design test-cases for both systems and components.
Figure 23.8: Equivalence partitioning Figure 23.9 Equivalence partitions
• If a set of partitions are identified, then choose test-cases from each of these partitions.
• A thumb rule for test-case selection:
1) Choose test-cases on the boundaries of the partitions.
2) Choose test-cases close to the mid-point of the partition (Figure 23.9).
Fig 23.10:Specification of a search routine Fig 23.11: Equivalence partitions for search routine
• The pre-condition states that the search routine will only work with sequences that are not
empty (Figure 23.10).
• The post-condition states that the variable „Found‟ is set if the key element is in the sequence.
• Search routine input partitions are (Figure 23.10):
1) Inputs which conform to the pre-conditions.
2) Inputs where a pre-condition does not hold.
3) Inputs where the key element is a member of the array (Found =true).
4) Inputs where the key element is not a member of the array (Found =false).

3-16
8a. Why people capability maturity model is used? Explain P-CMM model. (08 Marks)
Ans:
P-CMM (PEOPLE-CAPABILITY MATURITY MODEL)
• The P-CMM can be used as a framework for improving the way in which an organisation
manages its human assets.
Figure 25.9 The People Capability Maturity Model
• 5 five levels of P-CMM (Figure 25.9):
1) Initial
 Ad hoc, informal people management practices
2) Repeatable
 Establishment of policies for developing the capability of the staff
3) Defined
 Standardization of best people management practice across the organisation
4) Managed
 Quantitative goals for people management
5) Optimizing
 Continuous focus on improving individual competence and workforce
• Objectives of P-CMM:
1) To improve the capability of software organisations by increasing the capability of their
workforce.
2) To ensure that s/w development capability is an attribute of the organization rather
than of a few individuals.
3) To align the motivation of individuals with that of the organisation.
4) To retain valuable human assets (i.e., people with critical knowledge and skills) within
the organisation.
8b. List the factors that influence the effectiveness of communication. (04 Marks)

3-17
8c. Name the types of metrics used to estimate productivity. (02 Marks)
Ans:
1) Size-related Metrics
• These are related to the size of some output from an activity.
• The most common metric is lines of delivered source code.
• Other metrics that may be used are the number of delivered object code instructions or the
number of pages of system documentation.
2) Function-related Metrics
• These are related to the overall functionality of the delivered software.
• Productivity is expressed in terms of the amount of useful functionality produced in some given
time.
• Function points and object points are the best-known metrics of this type.
8d. Write a note on project duration and staffing. (06 Marks)
Ans:
PROJECT DURATION & STAFFING
• Project managers must estimate
→ The duration of time required to develop the software
→ man-power required to work on the project.
• The development time for the project is called the project schedule.
• Nowadays, organizations are demanding shorter development schedules. This is because they
want to bring their products into market before their competitor‟s.
• The relationship between i) no. of staff working on a project, ii) total effort required and iii)
development-time is not linear.
• For ex: Doubling the no. of staff does not mean that the duration of the project will be halved.
• COCOMO model is used to estimate the calendar time (TDEV) required to complete a project.
• TDEV predicts the nominal schedule for the project.
• In all COCOMO levels, the time computation formula is given by:
where PM is the effort computation
B is the exponent computed,
• In COCOMO-II model, the time computation formula is given by:
where SCEDPercentage is % increase or decrease in the nominal schedule.
• If the predicted figure differs from the planned schedule,
then it suggests that there is a high risk of problems delivering the software as planned.
• Inference of COCOMO model:
1) The time required to complete the project is a function of the total effort required for
the project.
2) The time does not depend on the number of software engineers working on the project.

4-1
1a. What is a software-process model? Explain the types of process models. (06 Marks)
Ans:
SOFTWARE-PROCESS MODEL
• This refers to a simplified representation of a software-process.
• This consists of
→ activities of software-process &
→ roles of the people involved.
THREE TYPES OF PROCESS MODELS
1) A Workflow Model
 This shows
→ sequence of activities in the process and
→ inputs & outputs of activities.
 The activities represent human-actions.
2) A Dataflow( or Activity model)
 This represents the process as a set of activities.
 Each activity carries out some data-transformation.
 This shows how the input to the process is transformed to an output.
For ex, how a specification is transformed to a design.
 The activities may be carried out by
→ people or
→ computers.
3) A Role/Action Model
 This represents
→ roles of the people involved &
→ activities for which the people are responsible.
THREE GENERAL MODELS
1) The Waterfall Approach
• This represents the activities as separate process-phases such as
→ requirements-specification
→ design
→ implementation &
→ testing.
• After each stage is defined, it is 'signed-off, and development goes on to the next stage.
2) Iterative Development
• This approach interleaves the activities of
→ specification
→ development &
→ validation.
• An initial-system is rapidly developed from very abstract-specifications.
• The initial-system is then refined with customer-input to satisfy the customer’s needs.
• The final-system may then be delivered to the customer.
3) CBSE (Component-based Software Engineering)
• This approach assumes that parts of the system already exist.
1b. Explain the key challenges facing software engineering. (06 Marks)
Ans: For answer, refer Solved Paper June-2014 Q.No.1a.(ii).

4-2
1c. With a neat diagram explain the systems engineering process-activities. (08 Marks)
Ans:
SYSTEM ENGINEERING
• This is the activity of
→ specifying, designing, implementing, validating & maintaining socio-technical systems.
• System-engineers are concerned with
→ software & hardware and
→ system's interactions with users & its environment (Figure 2.2).
• System-engineers must think about
→ system-services
→ constraints under which the system must be built &
→ ways in which the system is used.
Figure 2.2 The systems engineering process
• System engineering process vs. software development process
1) Limited scope for rework during System Development
 Once some system-engineering decisions are made, they are very expensive to change.
2) Interdisciplinary Involvement
 Many engineering-disciplines may be involved in system-engineering.
 There is a lot of scope for misunderstanding because
different engineers use different terms & conventions.
• System engineering is an inter-disciplinary activity because
it involves teams drawn from various backgrounds.
• System engineering teams are needed because
of the wide knowledge required to consider all aspects of design-decisions.
• There are almost infinite possibilities for trade-offs between different types of sub-systems.
• Different disciplines negotiate to decide how functionality should be provided.
• Often there is no ‘correct’ decision on how a system should be decomposed.
Rather, we may have several possible alternatives,
but we may not be able to choose the best technical solution.
2a. With a neat block diagram, explain the spiral process model. (08 Marks)
2b. Define dependability. Also explain briefly the four principle dimensions of
dependability. (06 Marks)

4-3
2c. With appropriate block diagram explain briefly the requirement engineering process
or software specification activities. (06 Marks)
Ans:
SOFTWARE SPECIFICATION
• This is also called requirements-engineering.
• The basic idea:
1) Understand & define what services are required from the system.
2) Identify the constraints on the system's operation & development.
• Errors at this stage lead to later problems in the design & implementation.
• Four phases are (Figure 4.6):
1) Feasibility Study
 An estimate is made of whether user-needs may be satisfied using current technologies.
 Current technologies include both software & hardware.
 This study should be relatively cheap & quick.
2) Requirements Elicitation & Analysis
 This is the process of deriving the system-requirements through
→ observation of existing-systems &
→ discussions with potential-users.
 This may involve the development of one or more system-models & prototypes.
3) Requirements Specification
 The information gathered in analysis-phase is translated into a document.
 The document defines a set of requirements.
 Two types of requirements:
i) User requirements
These are abstract statements of the system-requirements for the end-user.
ii) System-requirements
These are more detailed description of the system-functionality to be provided.
4) Requirements Validation
 Check the requirements for consistency & completeness.
 Errors in the requirements-document are discovered.
Figure 4.6 The requirements engineering process

4-4
3a. Assuming start date of project as 01 Nov.2014. For the set of tasks shown below
draw the project scheduling using,
i) Gantt/Bar chart ii) Staff allocation versus time chart. (10 Marks)
Ans:
Task Start Date End Date # Days Required
T1 1/11/14 8/11/14 8
T2 1/11/14 15/11/14 15
T3 9/11/14 24/11/14 15
T4 1/11/14 10/11/14 10
T5 16/11/14 25/12/14 10
T6 16/11/14 21/11/14 5
T7 9/11/14 28/11/14 20
T8 11/11/14 5/12/14 25
Figure 3.1 :Gantt/Bar chart
Figure 3.2 :Staff allocation versus time chart.

4-5
3b. Draw a state machine model of a simple microwave oven. (05 Marks)
3c. Draw sequence diagram for withdrawing money from ATM. (05 Marks)
Ans:
Figure 6.14 Sequence diagram of ATM withdrawal
4a. Write the IEEE format of writing SRS. (05 Marks)

4-6
4b. Differentiate between:
i) User requirements and system-requirements.
ii) Functional requirements and non-functional requirements. (05 Marks)
Ans (i):
USER REQUIREMENTS & SYSTEM REQUIREMENTS
1. User Requirements are
→ statements in a natural language &
→ diagrams (Figure 6.2).
• User requirements are statements of
→ what services the system is expected to provide and
→ constraints under which the system must operate.
2. System Requirements defines
→ functions of system
→ services of system &
→ operational constraints.
• The system requirements document must be precise.
• It should define exactly what is to be implemented.
• It may be part of the contract between
→ system buyer and
→ software developers.
Figure 6.2 Readers of different types of specification
Ans (ii):
FUNCTIONAL-REQUIREMENTS
• Functional requirements are statements of
i) What services the system should provide.
ii) How the system should react to particular inputs.
iii) How the system should behave in particular situations.
• They depend on
i) Type of software being developed.
ii) Expected user of the software.
iii) General approach taken by the organization when writing requirements.
• The system is considered to perform a set of high-level function.
• Each function is considered as a transformation of a set of input to corresponding set of output.
• Functional-requirement may be expressed as the user requirement-document.
• The requirement-specification should be complete and consistent.
1) Completeness: means all services required by the user should be defined.
2) Consistency: means requirement should not have any inconsistency.
NON-FUNCTIONAL-REQUIREMENTS
• Non-functional-requirements are not directly concerned with specific function of the system.
• They define constraint such as
i) Capabilities of I/O devices.
ii) Data representation used in the system-interface.
iii) What process should be used to develop the system?
• They specify the emergent property of the system.
• They may specify
i) Performance
ii) Security &
iii) Availability
• The non-functional-requirements are often more critical than functional-requirement.

4-7
4c. Explain briefly the techniques of requirements discovery. (10 Marks)
Ans:
REQUIREMENTS DISCOVERY
• Requirements discovery is the process of
→ gathering information about the proposed/existing systems and
→ finding the user/system requirements from the gathered-information
• Sources of information include
→ documentation
→ stakeholders of system and
→ specifications of similar systems.
• Three techniques for requirements discovery: 1) Viewpoints 2) Interviewing & 3) Scenarios.
1) VIEWPOINTS
 Viewpoints are used to organize both the elicitation process and the requirements.
 A key strength of viewpoint
→ it recognises multiple perspectives &
→ it discovers conflicts in requirements proposed by different stakeholders.
Three Generic Types of Viewpoint Example
Interactor viewpoints represent people or other
systems that interact directly with the system.
Bank’s customers.
bank’s account database.
Indirect viewpoints represent stakeholders who do
not use the system themselves but who influence the
requirements in some way.
Management of the bank.
Bank security staff.
Domain viewpoints represent domain characteristics
and constraints that influence the system
requirements.
Standards that have been
developed for interbank.
 Viewpoints can be used for classifying stakeholders and other sources of requirements.
 We should identify more specific viewpoint types:
1. Providers of services to the system and receivers of system services.
2. Systems that should interface directly with the system being specified.
3. Regulations and standards that apply to the system.
4. The sources of system business and non-functional-requirements.
5. Engineering viewpoints reflecting requirements of people.
6. Marketing viewpoints that generate requirements on product features.
2) INTERVIEWING
 Formal/informal interviews with system stakeholders are part of most requirements
engineering processes.
 Two types of interviews are:
1) Closed Interviews
 The stakeholder answers a predefined set of questions.
2) Open Interviews
 There is no predefined agenda.
 The team
→ explores a range of issues with system stakeholders.
→ develops a better understanding of their needs.
 Effective interviewers have 2 characteristics:
1) They
→ are open-minded
→ avoid preconceived ideas about the requirements and
→ are willing to listen to stakeholders.
 If the stakeholder comes up with surprising requirements, they are willing to
change their mind about the system.
2) They prompt the interviewee to start discussions with
→ question or
→ requirements proposal
 They prompt the interviewee to start discussions by suggesting working together
on a prototype system.
 Most people find it much easier to talk in a defined context rather than in general
terms.

4-8
3) SCENARIOS
 People usually find it easier to relate to real-life examples than to abstract descriptions.
 They can understand a scenario of how they might interact with a software system.
 Requirements engineers can use the information-gained to formulate the actual system
requirements.
 The scenario may include:
1) A description of what the system and users expect 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.
5a. List the system structuring styles and explain the repository model with a block
diagram. (06 Marks)
5b. With a neat block diagram, explain the object oriented decomposition for invoice
processing sub-system. (06 Marks)
Ans:
OBJECT ORIENTED DECOMPOSITION
• The system is decomposed into a set of loosely-coupled objects with well-defined interfaces.
• Objects call on the services offered by other objects.
• An object-oriented decomposition is concerned with
→ object-classes
→ class’s attributes/operations (Figure 11.5).
• When implemented,
→ objects are created from the classes
→ some control model are used to coordinate object-operations.
• For example:
The invoice processing system can
→ issue invoices to customers
→ receive payments and
→ issue receipts for the payments
• Notations used:
1) Operations are defined in the lower part of the rectangle representing the object.
2) Dashed arrows indicate that an object uses the attributes or services provided by
another object.
Figure 11.5 An object model of an invoice processing system
• Advantages:
1) Implementation of objects can be modified without affecting other objects.
2) System-structure is readily understandable.
3) Objects may reflect real-world entities.
4) Objects can be reused.
5) OOP languages provide direct implementations of architectural-components.
• Disadvantages:
1) To use services, objects must explicitly reference name & interface of other objects.
2) If an interface-change is required, the effect on all users of the changed-object must be
evaluated.
3) More complex entities are difficult to represent as objects.

4-9
5c. Explain briefly:
i) Call-Return control model.
ii) Broadcast control model. (08 Marks)
Ans (i): For answer, refer Solved Paper June-2015 Q.No.5b.
Ans(ii): For answer, refer Solved Paper June-2014 Q.No.5b.
6a. With block diagram, explain extreme programming process model. (10 Marks)

4-10
6b. With appropriate block diagram, explain the system evolution process. (10 Marks)
Ans:
SYSTEM EVOLUTION PROCESS
• The activities in the system evolution process:
1) Change Request
 Proposed changes includes
→ fault repair
→ adaptation and
→ new functionality.
2) Impact Analysis
 The cost and impact of these changes are assessed to see
→ how much the system is affected and
→ how much the system costs.
3) Release Planning
 If the proposed changes are accepted, a new release of the system is planned.
 During release planning, all proposed changes (fault repair, adaptation) are considered.
4) Change Implementation
 A decision is then made on which changes to implement in the next version of the
system.
5) System Release
 The changes are implemented and validated, and a new version of the system is
released.
 The process then iterates with a new set of changes proposed for the next release.
CHANGE IMPLEMENTATION (IN DETAIL)
• Here, the revisions to the system are designed, implemented and tested.
• The initial stage of change implementation is program understanding.
 During this phase, you have to understand
→ how the program is structured and
→ how the program delivers its functionality.
 When implementing a change, you use this understanding to make sure that the
implemented change does not adversely affect the existing system.
• Ideally, the change implementation stage should modify the following
1) System specification: New requirements that reflect system changes are proposed,
analysed and validated.
2) Design: System components are redesigned/implemented and the system is re-tested.
3) Analysis: If appropriate, prototyping of the proposed changes may be carried out.
4) Implementation: As you change software, you develop succeeding releases of system.
• Change requests sometimes relate to system problems that have to be tackled very urgently.
• The urgent changes can arise for 3 reasons:
1) If a serious fault occurs that has to be repaired to allow normal operation to continue.
2) If changes to system’s environment have unexpected effects that disturb normal operation.
3) If there are unanticipated changes to the business running the system such as
→ emergence of new competitors or
→ introduction of new legislation.

4-11
7a. Explain briefly the software inspection process (06 marks)
Ans:
PROGRAM INSPECTION PROCESS
• Program-inspections are reviews whose objective is defect-detection in a program.
INSPECTION ROLES
1) Author or Owner
→ producing the program or document and
→ fixing defects discovered during the inspection process.
2) Inspector
→ finding errors (or inconsistencies) in programs (or documents) and
→ identifying broader issues that are outside the scope of the inspection-team.
3) Reader
 He is responsible for presenting the code (or document) at an inspection meeting.
4) Scribe
 He is responsible for recording the results of the inspection meeting.
5) Chairman or Moderator
→ managing the process
→ facilitating the inspection and
→ reporting process-results to the chief moderator.
6) Chief Moderator
→ inspection process improvements
→ checklist updating and
→ standards development.
INSPECTION CHECKLISTS
• Inspection-team must have a precise specification of the code to be inspected (Figure 22.6).
• Inspection-team must be familiar with the organizational standards.
• An up-to-date, compatible version of the code must be distributed to the inspection-team.
Figure 22.6 The inspection process
STAGES IN INSPECTION PROCESS
1) Inspection Planning
 The moderator is responsible for inspection planning.
Inspection planning involves
→ selecting an inspection team
→ organising a meeting room and
→ ensuring that the material to be inspected and its specifications are complete
2) Overview Stage
 The program to be inspected is presented to the inspection team.
 Author of the code describes what the program is intended to do.
3) Individual Preparation
 Each member
→ studies the specification and the program and
→ looks for defects in the code.
4) Inspection Meeting
 The inspection should focus on
→ defect detection
→ standards conformance and
→ poor-quality programming
 The inspection team should not
→ suggest how these defects should be corrected nor
→ recommend changes to other components.

4-12
5) Rework
 The program’s author should make changes to correct the identified problems.
6) Follow-up Stage
 The moderator should decide whether a reinspection of the code is required.
 The program is then approved by the moderator for release.
7b. With a block diagram, explain the verification and validation process (06 marks)
7c. Perform the path testing for the following program flow graph by computing
cyclomatic complexity. (08 marks)
Figure 7.1: Program flow graph
Ans:
• Cyclomatic complexity gives the minimum number of paths that can generate all possible paths
through the module
• Cyclomatic complexity is given by
CC = E - N + P
Where
E = the number of edges of the graph
N = the number of nodes of the graph
P = the number of connected components
Solution:
Given, N=9, E=10, p=2
.’. CC=E-N+P=10-9+2=3
So, there are 3 independent paths:
Path 1: 1 -> 2 -> 3 -> 4 -> 8 -> 9
Path 2: 1 -> 2 -> 3 -> 5 -> 7 -> 8 -> 9
Path 3: 1 -> 2 -> 3 -> 5 -> 6 -> 8 ->9

4-13
8. Write short notes on: (20 Marks)
a. Legacy system
b. Capability maturity model
c. Software testing process.
d. COCOMO model
Ans(a): For answer, refer Solved Paper June-2014 Q.No.1c.
Ans(b): For answer, refer Solved Paper June-2014 Q.No.8a.
Ans(c):
SOFTWARE TESTING PROCESS
• Software Validation is intended to show that
→ the system conforms to its specification &
→ the system meets the expectations of the customer (Figure 4.9).
• Software Validation involves
→ checking processes such as inspections & reviews at each stage of the software-process.
Figure 4.9 The testing process
• Three stages in testing process (Figure 4.10):
1) Component Testing
 This is also called as unit testing.
 Individual components are tested to ensure that they operate correctly.
 Each component is tested independently, without other components.
 Components may be either
i) simple entities such as functions or object-classes or
ii) coherent groupings of these entities.
2) System Testing
 The components are integrated to make-up the system.
 This process is concerned with
i) Finding errors resulting from unanticipated interactions between components.
ii) Finding component interface-problems.
iii) Validating that the system meets its functional & non-functional requirements.
3) Acceptance Testing
 The system is tested with data supplied by the customer.
 The system is not tested with simulated test-data.
 This may reveal errors in the system-requirements definition.
Figure 4.10 Testing phases in the software process

4-14
Ans(d):
COCOMO
• The COCOMO model is an empirical model.
• The COCOMO model was derived by collecting data from a large no. of software-projects.
• These data were analysed to discover formulae that were the best fit to the observations.
• These formulae link the size of the system/product, project/team factors to the effort to
develop the system.
• COCOMO model is popular for following reasons:
1) It is well documented.
2) It is available in the public domain.
3) It is supported by public domain and commercial tools.
4) It has been widely used & evaluated in a range of organisations.
• Here 2 models are considered: i) COCOMO-81 & ii) COCOMO-II
1) COCOMO-81
• COCOMO 81 was the first version of the COCOMO model.
• COCOMO 81 was a three-level model.
• Here, the levels corresponded to the detail of the analysis of the cost-estimate.
1) The first level (basic) provided an initial rough estimate.
2) The second level modified this using a number of project and process multipliers.
3) The most detailed level produced estimates for different phases of the project.
where multiplier M reflects product, project and team characteristics.
2) COCOMO-II
• COCOMO II model recognizes different approaches to software development such as
→ prototyping
→ development by component composition and
→ use of database programming.
• COCOMO II supports a spiral model of development.
• COCOMO II embeds several sub-models that produce increasingly detailed estimates.
• These sub-models can be used in successive rounds of the development spiral.
Figure 26.7 The COCOMO II models

5-1
1a. What is Software Engineering? (02 Marks)
1b. i) List and explain the attributes of good software system.
ii) List and explain the key challenges facing software engineering. (10 Marks)
For answer, refer Solved Paper June-2014 Q.No.1a.(ii).
1c. What are legacy systems? Explain components of legacy system. (08 Marks)
2a. Explain dimensions of dependability properties and system properties that are
related to dependability. (08 Marks)
2b. Explain the approaches to improve reliability. (03 Marks)
Ans:
THREE APPROACHES TO IMPROVE RELIABILITY
1) Fault Avoidance
 Development-techniques are used.
 Development-techniques will either
i) Minimize the possibility of mistakes or
ii) Trap mistakes before they result in the introduction of faults.
 For example: Avoiding error-prone programming language constructs such as pointers.
2) Fault Detection and Removal
 The V&V techniques are used.
 V&V techniques increase chances of faults to be detected & removed before s/m is used
 For example: Testing and debugging.
3) Fault Tolerance
 Techniques that ensure that
→ faults in a system do not result in errors or
→ errors do not result in failures.
 For example: Incorporation of self-checking facilities in a system.
2c. With figure, explain the phases of RUP. (05 Marks)
2d. Explain testing phases with figure. (04 Marks)
Ans: For answer, refer Solved Paper Dec-2014 Q.No.8c.

5-2
3a. Distinguish between functional & non functional requirements with eg. (04 Marks)
Ans: For answer, refer Solved Paper Dec-2014 Q.No.4b.(ii).
3b. Explain the types of non-functional requirements with example. (06 Marks)
Ans:
TYPES OF NON-FUNCTIONAL-REQUIREMENTS
1) Product Requirements
• These requirements specify product behaviour.
• Examples include:
i) Performance requirements on how fast the system must execute.
ii) Reliability requirements that specifies the acceptable failure rate.
iii) Portability requirements.
iv) Usability requirements.
2) Organisational Requirements
• These requirements are derived from policies/procedures in the customer’s & developer’s
organisation.
• Examples include:
i) Process standards that must be used.
ii) Implementation requirements such as the programming language used.
iii) Delivery requirements that specify when the product is to be delivered.
3) External Requirements
• This covers all requirements that are derived from factors external to the system.
• These may include:
i) Interoperability requirements define how the system interacts with other systems.
ii) Legislative requirements must be followed to ensure that the s/m operates within law.
iii) Ethical requirements.
• Ethical requirements are requirements placed on a system to ensure that it will be acceptable
to the general public.
3c. Identify stakeholders of ATM system & classify according to viewpoints (10 Marks)
Ans:
SYSTEM STAKEHOLDERS FOR ATM SYSTEM
1) Current bank-customers who receive services from the system.
2) Representatives from other banks who have agreements that allow each other’s ATMs
to be used.
3) Managers of bank-branches who obtain management-information from the system.
4) Counter-staff at bank-branches who are involved in day-to-day running of the system.
5) Database admin who are responsible for integrating the system with the bank’s
customer database.
6) Bank security-managers who ensure that the system will not pose a security-hazard.
7) The bank’s marketing-department who are use the system as a means of marketing
the bank.
8) Hardware & software engineers who are responsible for maintaining h/w and s/w.
9) National banking-regulators who are responsible for ensuring that the system conforms
to banking regulations.
Three Generic Types of Viewpoint Example
Interactor viewpoints represent people or other systems that
interact directly with the system.
Bank’s customers.
bank’s account database.
Indirect viewpoints represent stakeholders who do not use the
system themselves but who influence the requirements in some way.
Management of the bank.
Bank security staff.
Domain viewpoints represent domain characteristics and
constraints that influence the system requirements.
Standards that have been
developed for interbank.

5-3
4a. Explain any 2 types of object models in detail. (08 Marks)
Ans:
THREE OBJECT-MODELS
1) Inheritance models
2) Object aggregation models and
3) Object Behaviour models
INHERITANCE MODEL
• Object-oriented modeling involves identifying the classes of object that are important in the
domain being studied.
• These are then organized into a taxonomy.
• A taxonomy is a classification scheme that shows how all class is related to other classes
through common attributes and services.
• To display the taxonomy, the classes are organised into an inheritance-hierarchy (Figure 8.11).
• Most general classes (parent) are at the top of the hierarchy.
• More specialized objects inherit parent’s attributes and services.
• The specialized objects may have their own attributes and services.
Figure 8.11 User class hierarchy
• In multiple inheritance models, a class has several parents (Figure 8.12).
Figure 8.12 Multiple inheritance
• Main problem of multiple inheritance:
1) Designing an inheritance-graph where objects do not inherit unnecessary attributes.
2) Difficulty of re-organizing the inheritance-graph when changes are required.
3) Resolving name clashes where attributes of 2 or more super-classes have the same
name but different meanings.

5-4
OBJECT BEHAVIOUR MODELING
• To model the behaviour of objects, you have to show how the operations provided by the
objects are used.
• In the UML, you model behaviours using scenarios that are represented as UML use cases.
• One way to model behaviour is to use UML sequence diagrams.
• Sequence diagrams show the sequence of actions involved in a use-case.
• In a sequence diagram (Figure 8.14),
1) Objects and actors are aligned along the top of the diagram.
2) Labeled arrows indicate operations.
3) Sequence of operations is from top to bottom.
Figure 8.14 The issue of electronic items

5-5
4b. Explain state machine model of micro oven. (06 Marks)
Ans:
Figure 8.5 State machine model of a simple microwave oven
MICROWAVE OVEN EXPLANATION
• The microwave oven has buttons
→ to set the power and the timer and
→ to start the system.
• The sequence of actions in using the microwave is:
1) Select the power level (either half-power or full-power).
2) Input the cooking time.
3) Press Start, and the food is cooked for the given time.

5-6
4c. Differentiate between milestones and deliverables. (02 Marks)
Ans:
MILESTONES DELIVERABLES
A recognizable end-point of a software-process
activity (Figure 5.3).
A project-result that is delivered to the
customer.
At each milestone, there should be a formal
output, such as a report, that can be presented
to management.
Usually delivered at the end of some major
project phase such as specification or design.
Milestones may be internal project results that
are used by the project-manager to check
project-progress but which are not delivered to
the customer.
Deliverables are usually milestones, but
milestones need not be deliverables.
Figure 5.3 Milestones in the requirements process
4d. List the activities of risk management with figure. (04 Marks)
Ans: For answer, refer Solved Paper Dec-2013 Q.No.4b.

5-7
5a. Explain client server architecture with example. (06 Marks)
Ans:
CLIENT SERVER MODEL
• This is a distributed system-model.
• Three major components (Figure 11.3):
i) Servers
 A set of servers provide specific services such as printing, data management, etc.
ii) Clients
 A set of clients call on the services offered by servers.
iii) Network
 A network allows the clients to access the servers.
• Clients have to know names of the available-servers.
However, servers need not know names of the available-clients.
• Clients access the services provided by a server through RPC (remote procedure call).
Figure 11.3 The architecture of a film and picture library system
• Advantages:
1) Distribution of data is straightforward.
2) Easy maintenance.
3) Flexibility: Easy to add new servers or upgrade existing servers.
4) Scalability: Any element can be upgraded when needed.
5) Centralization: Access, resources and data security are controlled through the server.
• Disadvantages:
1) No shared data-model across servers.
2) Subsystems may organize their data in different ways.
3) Data interchange may be inefficient.
4) No central register of names and services. It may be hard to find out what servers and
services are available.
5) Single point of failure: When servers go down, all operations stop.

5-8
5b. Explain with figures i) centralized control and ii) event driven systems. (10 Marks)
Ans (i):
CENTRALISED CONTROL
• One subsystem is chosen as the system-controller.
• The system-controller is responsible for managing the execution of other subsystems.
• Two models (based on sequential or parallel execution):1) Call-return model and
2) Manager model
CALL-RETURN MODEL
• This is a top-down subroutine model (Figure 11.7).
• In the hierarchy, control passes from a higher-level routine to a lower-level routine.
• The currently executing subroutine has responsibility for control.
• The currently executing subroutine can either
→ call other routines or
→ return control to its parent.
• This is only applicable to sequential-systems.
• This model is embedded in programming languages such as C and Pascal.
• This model may be used at the module level to control functions or objects.
Figure 11.7 The call-return model of control
• Advantage:
 It is relatively simple to
→ analyse control flows and
→ work out how the system will respond to particular inputs.
• Disadvantage:
 Exceptions to normal operation are awkward to handle.
MANAGER MODEL
• This is applicable to concurrent-systems.
• One system component is chosen as a system-manager (Figure 11.8).
• The system-manager controls the starting, stopping and coordination of other system-
processes.
• A process is a subsystem that can execute in parallel with other processes.
Figure 11.8 A centralised control model for a real-time system
• This model is used in 'soft' real-time systems which do not have tight time constraints.
• Disadvantage:
 It requires very powerful algorithm to control concurrent processes.
• The system controller checks whether other processes have produced information to be
processed or to pass information to them for processing.
• The controller usually loops continuously, polling sensors and other processes for events or
state changes. For this reason, this model is sometimes called an eventloop model.

5-9
5c. List the proposals made about how to identify object class. (04 Marks)
Ans:
OBJECT IDENTIFICATION
• This process is actually concerned with identifying object-classes (Figure 14.11).
• Guidelines to identify object-classes:
1) Use a Grammatical Analysis of a natural language description of a system.
 Objects and attributes are nouns.
 Operations or services are verbs.
2) Use Tangible Entities
 For example:
→ application domain such as aircraft
→ roles such as manager and
→ events such as request.
3) Use a Behavioural Approach
 The designer first understands the overall behaviour of the system.
 The various behaviours are assigned to different parts of the system.
 An understanding is derived of who initiates and participates in the behaviours.
4) Use a Scenario-based Analysis
 Various scenarios of system-use are identified and analyzed.
 As each scenario is analyzed, the team must identify
→ required objects,
→ required attributes and
→ required operations.
Figure 14.11: Identification of the weather station objects
6a. What is pair programming? Write its advantages. (04 Marks)
6b. What is extreme programming'? List principles of agile method. (06 Marks)

5-10
6c. Explain activities involved in reengineering process with figure. (10 Marks)
Ans:
REENGINEERING PROCESS
• Software re-engineering is concerned with re-implementing legacy systems to make them
more maintainable.
• Re-engineering includes
→ re-documenting the system
→ organizing/restructuring the system
→ translating the system to a modern programming language.
Figure 21.11 The reengineering process
• Advantages of software re-engineering:
1) Reduced Risk
 There is a high risk in re-developing business-critical software.
 Delays in introducing the new software may mean that
→ business is lost and
→ extra costs are incurred.
2) Reduced Cost
 The cost of re-engineering is significantly less than the cost of developing new software.
• The activities in re-engineering process:
1) Source Code Translation
 The program is converted from an old programming language to different language.
2) Reverse Engineering
 The program is analysed and information extracted from it.
 This helps to document its organisation and functionality.
3) Program Structure Improvement
 Control structure of program is analysed/modified to make it easier to read/understand.
4) Program Modularisation
 Related parts of the program are grouped together.
 Redundancy is removed.
 In some cases, a centralized system is modified to run on a distributed platform.
5) Data Re-engineering
 The data processed by the program is changed to reflect program changes.
• The principal factors that affect reengineering-costs:
1) Quality of the Software to be Re-engineered
 The lower the quality of the software, the higher the re-engineering costs.
2) Tool Support Available for Re-engineering
 It is not normally expensive to re-engineer a software system.
3) Extent of Data Conversion Required ‘
 If re-engineering requires large volumes of data-conversion, the cost increases.
4) Availability of Expert Staff
 If maintaining-staff cannot be involved in re-engineering process, costs will increase.
 This is ‘.’ system re-engineers will have to spend lot of time to understand the system.

5-11
7a. Write the difference between verification and validation? (10 Marks)
Ans:
Verification Validation
Are we building the product right? Are we building the right product?
Software should conform to its specification. Software should meet the customer’s
expectations.
This is a static V&V technique, as you don't
need to run the software on a computer.
This is a dynamic V & V technique. It always
involves executing the code
Static techniques can only check the
correspondence between
→ program and
→ specification (verification).
You examine the outputs of the software and
its operational behaviour to check that it is
performing as required.
Static techniques cannot demonstrate that the
software is operationally useful.
Dynamic techniques can demonstrate that
the software is operationally useful.
Includes reviews, inspections, unit-testing
and integration-testing.
Includes program-reviews, system-testing
and acceptance-testing.
Inspections can be done on any system-
representation such as
→ requirements-document
→ design-diagrams and
→ program source-code
System-testing involves running an
implementation of the software with test-
data.
Verification is done by QA team to ensure that
the software is as per the specifications in the
SRS document.
Validation is carried out with the involvement
of testing team.
It is human based checking of documents and
files.
It is computer based execution of program.
It can catch errors that validation cannot
catch. It is low level exercise.
It can catch errors that verification cannot
catch. It is High Level Exercise.
Following items are evaluated during
Verification: Plans, Requirement
Specifications, Design Specifications, Code,
Test Cases etc,
Following item is evaluated during Validation:
Actual product or Software under test
Cost of errors caught in Verification is less
than errors found in Validation.
Cost of errors caught in Validation is more
than errors found in Verification.
Verification is done by QA team to ensure that
the software is as per the specifications in the
SRS document.
Validation is carried out with the involvement
of testing team.
Figure 22.1 Static and dynamic verification and validation

5-12
7b. Explain clean room software development process with figure in detail. (05 Marks)
7c. List classes of interface errors. (05 Marks)
Ans:
THREE CLASSES OF INTERFACE ERRORS
1) Interface Misuse
 A calling-component
→ calls some other component and
→ makes an error in the use of its interface.
 Reasons for error may be
→ parameters are of wrong type or
→ parameters passed in the wrong order.
2) Interface Misunderstanding
 A calling-component
→ misunderstands the specification of interface of the called-component and
→ makes assumptions about the behaviour of the called-component.
 The called-component does not behave as expected.
 This causes unexpected behaviour in the calling-component.
 For example: A binary search routine may be called with an unordered array to be
searched. The search would then fail.
3) Timing Errors
 These occur in real-time systems that use
1) Shared memory or
2) Message-passing interface.
 The producer of data and the consumer of data may operate at different speeds.
 The consumer can access out-of-date information. This is because the producer of the
information has not updated the shared interface information.

5-13
8. Write short notes on the following: (20 Marks)
a. Factors governing staff selection
b. P-CMM levels
c. Sub-models of COCOMO II
d. Maslow’s hierarchy of needs.
Ans(a): For answer, refer Solved Paper June-2013 Q.No.8a.
Ans(b): For answer, refer Solved Paper June-2014 Q.No.8a.
Ans(c):
SUB-MODELS OF COCOMO-II
Figure 26.7 The COCOMO II models
1) Application-Composition Model
• This assumes that systems are created from
→ reusable components
→ scripting or
→ database programming.
• It is designed to make estimates of prototype development.
• Software-size estimates are based on application-points.
• A simple size/productivity formula is used to estimate the effort required.
2) Early Design Model
• This model is used
→ during early stages of the system design
→ after the requirements have been established.
• Estimates are based on function points.
• The function points are then converted to number of lines of source code.
• This model uses the standard formula for cost estimation.
• This model includes a simplified set of 7 multipliers.
3) Reuse Model
• This model is used to compute the effort required to integrate reusable components and/or
program code.
• It is usually used in conjunction with the post-architecture model.
4) Post-Architecture Model
• Once the system architecture has been designed, a more accurate estimate of the software size
can be made.
• Again, this model uses the standard formula for cost estimation.
• However, this model includes a more extensive set of 17 multipliers.
• The 17 multipliers reflect personnel capability and product and project characteristics.

5-14
Ans(d):
MASLOW’S HIERARCHY NEEDS
• Maslow suggests that
→ people are motivated by satisfying their needs and
→ people’s needs are arranged in a series of levels.
Figure 25.3 Human needs hierarchy
• As shown in Figure 25.3, human needs hierarchy has 5 needs:
1) Physiological Needs: represent fundamental needs for food, sleep, and so on.
2) Safety Needs: represent the need to feel secure in an environment.
3) Social Needs: are concerned with the need to feel part of a social grouping.
4) Esteem Needs: are the needs to feel respected by others.
5) Self-realization Needs: are concerned with personal development.
• Ensuring the satisfaction of 1) Social, 2) Esteem and 3) Self-realisation needs is most important
from a management point of view.
• From a management point of view, it is essential to ensure the satisfaction of
1) Social needs
2) Esteem needs &
3) Self-realisation needs.
1) How to satisfy social needs?
 You need to give people time to meet their co-workers.
 You need to provide places for the co-workers to meet.
 This is relatively easy when all of the members of a development-team work in the
same place.
 But nowadays, team members are not located
→ in the same building or
→ in the same town or state.
 Teleconferencing & e-mail may be used to support the remote working.
2) How to satisfy esteem needs?
 You need to show people that they are valued by the organization.
 Public-recognition of achievements is a simple yet effective way of doing this.
 Obviously, people must also feel that they are paid at a level that reflects their skills
and experience.
3) How to satisfy self-realization needs?
 You need to give people responsibility for their work
 You need to assign people the demanding (but not impossible) tasks.
 You need to provide a training programme where people can develop their skills.

VTU 5TH SEM CSE SOFTWARE ENGINEERING SOLVED PAPERS - JUN13 DEC13 JUN14 DEC14 JUN15

More Related Content

What's hot

Viewers also liked

Similar to VTU 5TH SEM CSE SOFTWARE ENGINEERING SOLVED PAPERS - JUN13 DEC13 JUN14 DEC14 JUN15

Recently uploaded

In this document

VTU 5TH SEM CSE SOFTWARE ENGINEERING SOLVED PAPERS - JUN13 DEC13 JUN14 DEC14 JUN15