SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.

(AUTONOMOUS)
DEPARTMENT OF CSM

SUBJECT NAME/ CODE: SOFTWARE ENGINEERING AND DESIGN- 20CSE243

MID I EXAM

PART B

1 a) Explain software myths (5 marks)

Misleading attributes that leads to serious problem called myths

-It's like trying to correct old misunderstandings about software, even though some of those mistaken
beliefs still linger.
1) Management myths
2) Customer myths
3) Practitioner myths

Management myths: Managers with software responsibility are often under pressure to maintain
budgets, keep schedules from slipping, and improve quality. Following are the management myths:

Myth: We already have a book that’s full of standards and procedures for building software; won’t that
provide my people with everything they need to know?
Reality: The book of standards may very well exist, but isn’t used. Most software practitioners aren’t
aware of its existence. Also, it doesn’t reflect modern software engineering practices and is also complete.
Customer myths: Customer myths lead to false expectations (by the customer) and ultimately,
dissatisfaction with the developer. Following are the customer myths:

Myth: A general statement of objectives is sufficient to begin writing programs-we can fill in the details
later.
Reality: A poor up-front definition is the major cause of failed software efforts. A formal and detailed
description of the functions, behavior, performance, interfaces, design constraints, and validation criteria
is essential.
Practitioner’s myths:
Practitioners have following myths:

Myth: Once we write the program and get it to work, our job is done.
Reality: Industry data indicate that between 60 and 80 percent of all effort expended on software will be
expended after it is delivered to the customer for the first time.

Myth: Until I get the program “running” I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be applied from the
inception of a project—the formal technical review.
 SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.
(AUTONOMOUS)
DEPARTMENT OF CSM

1 b) Explain umbrella activities. (5 marks)

Umbrella Activities are as follows:

1. Software Project Tracking and Control
2. Formal Technical Reviews
3. Software Quality Assurance
4. Software Configuration Management
5. Document Preparation and Production
6. Re-usability Management
7. Measurement and Metrics
8. Risk Management

Software Project Tracking and Control:

Before the actual development begins, a schedule for developing the software is created. Based on that
schedule the development will be done. However, after a certain period of time it is required to review the
progress of the development to find out actions which are in need to be taken to complete the
development, testing etc. in time. The outcome of the review might require the development to be
rescheduled.
Formal Technical Reviews:
Software engineering is done in clusters or modules, after completing each module, it is good practice to
review the completed module to find out and remove errors so their propagation to the next module can
be prevented.
Software Quality Assurance:
The quality of the software such user experience, performance, load handling capacity etc. should be
tested and confirmed after reaching predefined milestones. This reduces the task at the end of the
development process. It should be conducted by dedicated teams so that the development can keep going
on.
Software Configuration Management:
Software configuration management (SCM) is a set of activities designed to control change by identifying
the work products that are likely to change, establishing relationships among them, defining mechanisms
for managing different versions of these work products.
Document preparation and production:
All the project planning and other activities should be hardly copied and the production gets started here.
Re-usability Management:
This includes the backing up of each part of the software project they can be corrected or any kind of
support can be given to them later to update or upgrade the software at user/time demand.
Measurement & Metrics:
This will include all the measurement of every aspects of the software project.
Risk Management:
Risk management is a series of steps that help a software team to understand and manage uncertainty. It’s
a really good idea to identify it, assess its probability of occurrence, estimate its impact, and establish a
contingency plan that─ ‘should the problem actually occur’.
 SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.
(AUTONOMOUS)
DEPARTMENT OF CSM

2. What is CMMI? Outline different levels of capability maturity model and list the KPA’s of each
level. (10 marks)

Capability Maturity Model Integration (CMMI) is a successor of CMM and is a more evolved model that
incorporates best components of individual disciplines of CMM like Software CMM, Systems
Engineering CMM, People CMM, etc.
CMMI Model – Maturity Levels : In CMMI with staged representation, there are five maturity levels
described as follows :
1. Maturity level 1 : Initial
 processes are poorly managed or controlled.
 unpredictable outcomes of processes involved.
 ad hoc and chaotic approach used.
 No KPAs (Key Process Areas) defined.
 Lowest quality and highest risk.

2. Maturity level 2 : Managed

 requirements are managed.
 processes are planned and controlled.
 projects are managed and implemented according to their documented plans.
 This risk involved is lower than Initial level, but still exists.
 Quality is better than Initial level.
3. Maturity level 3 : Defined
 processes are well characterized and described using standards, proper procedures, and methods, tools,
etc.
 Medium quality and medium risk involved.
 Focus is process standardization.
4. Maturity level 4 : Quantitatively managed
 quantitative objectives for process performance and quality are set.
 quantitative objectives are based on customer requirements, organization needs, etc.
 process performance measures are analyzed quantitatively.
 higher quality of processes is achieved.
 lower risk
5. Maturity level 5 : Optimizing
 continuous improvement in processes and their performance.
 improvement has to be both incremental and innovative.
 highest quality of processes.
 lowest risk in processes and their performance.

CMMI Model – Capability Levels A capability level includes relevant specific and generic practices for
a specific process area that can improve the organization’s processes associated with that process area.
For CMMI models with continuous representation, there are six capability levels as described below:
1. Capability level 0 : Incomplete
 incomplete process – partially or not performed.
 one or more specific goals of process area are not met.
 No generic goals are specified for this level.
 this capability level is same as maturity level 1.
 SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.
(AUTONOMOUS)
DEPARTMENT OF CSM

2. Capability level 1 : Performed

 process performance may not be stable.
 objectives of quality, cost and schedule may not be met.
 a capability level 1 process is expected to perform all specific and generic practices for this level.
 only a start-step for process improvement.
3. Capability level 2 : Managed
 process is planned, monitored and controlled.
 managing the process by ensuring that objectives are achieved.
 objectives are both model and other including cost, quality, schedule.
 actively managing processing with the help of metrics.
4. Capability level 3 : Defined
 a defined process is managed and meets the organization’s set of guidelines and standards.
 focus is process standardization.
5. Capability level 4 : Quantitatively Managed
 process is controlled using statistical and quantitative techniques.
 process performance and quality is understood in statistical terms and metrics.
 quantitative objectives for process quality and performance are established.

6. Capability level 5 : Optimizing

 focuses on continually improving process performance.
 performance is improved in both ways – incremental and innovation.
 emphasizes on studying the performance results across the organization to ensure that common causes
or issues are identified and fixed.

3 a) Explain Spiral model. (5 marks)

 Initially proposed by Boehm in 1986.
 It is a risk driven software development model and prototyping model.
 It is combination of waterfall model, Iterative model and prototyping model.
 Software is developed in a series of incremental releases as per each spiral.
 Example: Microsoft, gaming industry
 Also called as meta model.

1) Planning:(Requirement gathering and project head)

- Communication between customers and project head
- Collect all the requirements from customers.
 SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.
(AUTONOMOUS)
DEPARTMENT OF CSM

- Analysis estimated cost, schedule and required resource.

2) Risk analysis:
- Identification of all the potentials risks.
- Risk mitigation strategy is planned for solving risks.
- Design a prototype of model.(replica of actual s/w development)

3) Engineering and Execution:

- Actual development start
- Designer design the product as per final prototype.
- Developer perform actual coding or implementation
- Tester perform all testing methods
- deploy product to the customer environment.

4) Evaluation:
- take a feedback from customer
- if iteration want any changes,goes to next planning or next spiral iteration

Advantages of Spiral Model

• High amount of risk analysis.
• Risky part can be developed earlier which help in better risk management.
• Allows extensive use of prototype(solve all error in prototype).
• There is always a space for customer feedback.
• Changing the requirement can be accommodated.
• Development is fast

Disadvantages of Spiral Model

• Risk analysis needed highly particular expertise.
• Can be a costly model to use.
• Doesn’t work for smaller projects.
• Spiral process is complex sometimes because spiral may be infinitely.
• Large number of spiral stages required excessive documentation.

b) Discus waterfall model with suitable diagram. Give its advantages and disadvantages. (5 marks)

-It is the first approach used in software development process.

-It is also called as classical life cycle model or linear sequential model.
-In waterfall model any phase of development process begins only if previous phase is completed.
1) Requirement Analysis
2) Design
3) Implementation
4) Verification/ Testing
 SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.
(AUTONOMOUS)
DEPARTMENT OF CSM

5) maintenance

Advantages of Waterfall Model

- It is very simple to understand and easy to use.
- Phases of waterfall model do not overlap with each other.
- It is useful for small projects in which requirements are clear at the beginning.
- Since development is linear it is easy to manage development
process.
Disadvantages of Waterfall Model
• It is not useful for large projects.
• Not suitable for projects in which requirement are not clear initially.
• Product is available only at the end of development process.
• It is very difficult to modify system requirement in the middle of development process.

4a Compare functional requirements and Non-functional requirements. (5 marks)

 SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.
(AUTONOMOUS)
DEPARTMENT OF CSM

b) Compare user requirement and system requirement. (5 marks)

5. Explain about software requirement document (10 marks)

The software requirements document (sometimes called the software requirements. specification or SRS)
is the official statement of what the system developers should implement.
• It should include both the user requirements for a system and a detailed specification of the system
requirements.
• In some cases, the user and system requirements may be integrated into a single description. In other
cases, the user requirements are defined in an introduction to the system requirements specification. If
there are a large number of requirements, the detailed system requirements may be presented in a separate
document.
• The requirements document has a diverse set of users, ranging from the senior management of the
organisation that is paying for the system to the engineers responsible for developing the software.
 SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.
(AUTONOMOUS)
DEPARTMENT OF CSM

A number of large organisations, such as the US Department of Defense and the IEEE, have defined
standards for requirements documents.
• The most widely known standard is IEEE/ANSI 830-1998 (IEEE, 1998). This IEEE standard suggests
the following structure for requirements documents:
1 .Introduction
1.1 Purpose of the requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements cover functional, non-functional and interface requirements. This is obviously
the most substantial part of the document but because of the wide variability in organizational practice, it
is not appropriate to define a standard structure for this section. The requirements may document external
interfaces, describe system functionality and performance, specify logical database requirements, design
constraints, emergent system properties
and quality characteristics.
4. Appendices
5. Index
 SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.
(AUTONOMOUS)
DEPARTMENT OF CSM

6. Explain in detail about requirements Engineering process (10 marks)

The goal of the requirements engineering process is to create and maintain a system requirements
document.
➢ The overall process includes four high-level requirements engineering sub-processes. These are
concerned with assessing whether the system is useful to the business (feasibility study); discovering
requirements (elicitation and analysis); converting these requirements into some standard form
(specification);and checking that the requirements actually define the system that the customer wants
(validation) and shown in figure
➢ The people involved develop a better understanding of what they want the software to do; the
organization buying the system changes; modifications are made to the system's hardware, software: and
organizational environment.
 SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.
(AUTONOMOUS)
DEPARTMENT OF CSM

➢ The process of managing these changing requirements is called requirements management.

➢ The alternative perspective presents the process as a three-stage activity where the activities are
organized as an iterative process around a spiral and is shown in figure.
➢ The amount of time and effort devoted to each activity in an iteration depends on the stage of the
overall process and type of system being developed. Early in the process, most effort will be spent on
understanding high-level business and non-functional requirements and the user requirements.
➢ Later in the process, in the outer rings of the spiral, more effort will be devoted to system requirements
engineering and system modeling.

1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software that is
acceptable to users, flexible to change and conformable to established standards.
Types of Feasibility:
1. Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to
accomplish customer requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the required software
performs a series of levels to solve business problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software can generate
financial profits for an organization.
2. Requirement Elicitation and Analysis:
This is also known as the gathering of requirements. Here, requirements are identified with the help of
customers and existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of relationships
and also resolve conflicts if any.
Problems of Elicitation and Analysis
o Getting all, and only, the right people involved.
o Stakeholders often don't know what they want
 SREENIVASA INSTITUTE OF TECHNOLOGY AND MANAGEMENT STUDIES.
(AUTONOMOUS)
DEPARTMENT OF CSM

o Stakeholders express requirements in their terms.

o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software analyst after the
requirements collected from the various sources - the requirement received by the customer written in
ordinary language. It is the job of the analyst to write the requirement in technical language so that they
can be understood and beneficial by the development team. The models used at this stage include ER
diagrams, data flow diagrams (DFDs), function decomposition diagrams (FDDs), data dictionaries, etc.
o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a company, an
organization, a set of procedures, a computer hardware system, a software system, or any
combination of the preceding. The DFD is also known as a data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store information about all data
items defined in DFDs. At the requirements stage, the data dictionary should at least define
customer data items, to ensure that the customer and developers use the same definition and
terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is the entity-
relationship diagram, often called an "E-R diagram." It is a detailed logical representation of the
data for the organization and uses three main constructs i.e. data entities, relationships, and their
associated attributes.
4. Software Requirement Validation:
After requirement specifications developed, the requirements discussed in this document are validated.
The user might demand illegal, impossible solution or experts may misinterpret the needs. Requirements
can be the check against the following conditions -
o If they can practically implement
o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe
Requirements Validation Techniques
o Requirements reviews/inspections: systematic manual analysis of the requirements.
o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured requirements
descriptions.