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)
Ans: For answer, refer Solved Paper June-2013 Q.No.8b.

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

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

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

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

Recently uploaded

Recently uploaded (20)

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