ise_questionsanswers

Subject Name: Introduction to Software Engineering Subject Code: 4340702
IMP Question with Answers
Unit-1
1) Define Software Engineering. Tell why there is a need for Software Engineering.
Definition:
Software engineering is the application of a systematic, disciplined and quantifiable approach to the
development, operation and maintenance of software.
Need of Software Engineering:
 To help developers to obtain high quality software product.
 To develop the product in appropriate manner using life cycle models.
 To acquire skills to develop large programs.
 To acquire skills to be a better programmer.
 To provide a software product in a timely manner.
 To provide a quality software product.
 To provide a software product at a agreed cost.
 To develop ability to solve complex programming problems.
2) Explain types of software with examples.
Software is the “collection of computer programs, procedures, rules, associated documents and
concerned data with the operation of data processing system”.
 Software Application Domain types:

 System Software
 Application Software
 Embedded software
 Web application
 Artificial intelligence (AI) software
 System Software
Prepared By: Department of Computer Engineering Page 1

 It is responsible for controlling, integrating the hardware components of a system so the

software and the users can work with them.
 Example: Operating System, Device drivers.
 Application Software
 It is used to accomplish some specific task.
 It should be collection of small programs.
 Example: Microsoft Word, Excel etc.
 Embedded Software
 Embedded software is a software that is embedded in hardware or non-PC devices.
 It is written specifically for the particular hardware that it runs on. It usually has
processing and memory constraints.
 Examples of embedded software:factory robots, some calculators and dedicated GPS
devices.
 Web Application
 A web-application is an application program that is usually stored on a remote server, and
users can access it through the use of Software known as web-browser.
 It is a type of computer program that usually runs with the help of a web browser and also
uses many web technologies to perform various tasks on the internet.
Example: tools like Google docs,CMS
 Artificial intelligence Software
 Artificial intelligence is the simulation of human intelligence processes by machines,
especially computer systems.
 Specific applications of AI include expert systems, natural language processing, speech
recognition and machine vision.
 Artificial Intelligence (AI) Software is a computer program which mimics human
behavior by learning various data patterns and insights.
 Top features of AI software include Machine Learning, Speech & Voice Recognition,
Virtual Assistant etc.
3) Explain software engineering layered approach with neat sketch.
Software engineering can be viewed as a layered technology.

It contains process, methods, and tools that enables software product to be built in a timely manner.
tools
methods
process model
a “quality” focus
 A Quality Focus Layer
 Software engineering mainly focuses on quality product.
 It checks whether the output meets with its requirement specification or not.
 Every organization should maintain its total quality management.
 Process Layer
 It is the heart of software engineering.
 It is also work as foundation layer.
 Software process is a set of activities together if ordered and performed properly, then the
desired result would be produced.
 It defines framework activities.
 The main objective of this layer is to deliver software in time.
 Method Layer
 It describes ‘how-to’ build software product.
 It creates software engineering environment to software product using CASE tools
 Tools Layer
 It provides support to below layers.
 Due to this layer, process is executed in proper manner.
4) Explain Umbrella Activities.

Umbrella activities are performed throughout the process.

These activities are independent of any framework activity.
The umbrella activities are given below:
 Software project tracking and control:
 It assess progress against the plan and take actions to maintain the schedule.
 Formal Technical Review:
 This includes reviewing the techniques that has been used in the project.
 Software Quality Assurance:
 This is very important to ensure the quality management of each part to ensure them.
 Document Preparation and production
 All the project planning and other activities should be hardly copied and the production gets
started here.
 Reusability 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.
 Software configuration management:
 It manages the impact of changes throughout the software development process.
 Documentation
 All the project planning and other activities should be hard copied and the production gets
started here.
 Reusability 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(estimation)
 This will include all the measurement of every aspects of the software project, like time
estimation, cost estimation.
 Risk Management
 Risk management is a series of steps that help a software team to understand and manage
uncertainty.
 It identifies problems and deal with it.
5) Explain Waterfall Model with diagram.
 Waterfall model was proposed by Royce in 1970.

 It is also called as “traditional waterfall model” or “conventional waterfall model”.
 This model break down the life cycle into set of phases like.
 Feasibility study
 Requirements analysis and specification
 Design
 Coding and unit testing
 Integration and system testing
 Maintenance.
 During each phase of life cycle, a set of well defined activities are carried out. And each phase
required different amount of efforts.
 The phases between feasibility study and testing known as development phases.
 Among all life cycle phases maintenance phase consumes maximum effort.
 Feasibility Study:
 Aim of this phase is to determine whether the system would be financially and technically
feasible to develop the product.

 Requirement Analysis and Specification:

 Aim of this phase is to understand the exact requirements of the customer and to document
them properly.
 Design:
 The goal of design phase is to transform the requirements specified in SRS document into a
structure that is suitable for implementation in some programming language.
 Coding and Unit Testing
 It is also called as implementation phase.
 Aim of this phase is to translate the software design into source code and unit testing is done
module wise.
 Integration and System Testing
 Once all the modules are coded and tested individually, integration of different modules is
undertaken.
 Goal of this phase is to ensure that the developed system works well to its requirements
described in the SRS document.
 Maintenance
 It requires maximum efforts to develop software product.
 This phase is needed to keep system operational.

 General maintenance is needed due to change in the environment or the requirement of the
system.
 Waterfall Model – Advantages
 It is simple and easy to understand and use.
 Each phase has well defined input and output.
 Waterfall model works well for smaller projects where requirements are very well understood.
 In divides complex tasks into smaller, more manageable works.
 Waterfall Model – Disadvantages
 It is a theoretical model, as it is very difficult to strictly follow all the phases in all types of
projects.
 It may happen that the error may be generated at any phase and encountered in later phase. So,
it is not possible to go back and solve the error in this model.
 High amount of risk.
 It is a document driven process that requires formal documents at the end of each phase.
 Waterfall Model – When to use?
 Requirements are very well known and fixed.
 Product definition is stable.
 Technology is understood.
 When the project is short.
6) Explain the incremental process model for software development.
 The incremental model is also referred as the successive version of waterfall model using
incremental approach.
 In this model, the system is broken down into several modules which can be incrementally
implemented and delivered.
 First develop the core product of the system.
 The core product is used by customers to evaluate the system.
 The initial product skeleton is refined into increasing levels of capability: by adding new
functionality in successive version.

Incremental Model – Advantages

 Each successive version performing more useful work than previous version.
 The core modules get tested thoroughly, there by reducing chance of error in final product.
 The model is more flexible and less costly to change the scope and requirements.
 User gets a chance to experiment with partially developed software.
 Feedback providing at each increment is useful for determining the better final product.
Incremental Model – Disadvantages.
 Sometimes it is difficult to subdivide problems into functional unit.
 Model can be used for very large problems.
 It needs good planning and design.
Incremental Model – When to use?
 The incremental model is used when the problem is very large and user requirements are not
well specified at initial stage.
7) Explain Prototype Model.
 Prototype is a working physical system or subsystem.

 Prototype is nothing but a tip implementation of a system.
 In this model, before starting actual development, a working prototype of the system should be
built first.
 A prototype is actually a partial developed product.
 Compared to the actual software, a prototype usually have,
 Limited functional capabilities

 Low reliability
 Inefficient performance
 Prototype model is very useful in developing GUI part of system.
 In working of the prototype model, product development starts with initial requirements gathering
phase.
 Then, quick design is carried out and prototype is built.
 The developed prototype is then submitted to the customer for his evaluation.
 Based on customer feedback, the requirements are refined and prototype is modified.
 This cycle of obtaining customer feedback and modifying the prototype continues till the
customers approve the prototype.
 The actual system is developed using different phases of iterative waterfall model.
 Prototype Model – Advantages
 A partial product is built at initial stage, so customers can get a chance to have a look of the
product.
 New requirements can be accommodate easily.
 Quicker user feedback is available for better solution.
 As the partial product is evaluated by the end users, more chance of user satisfaction.
 Prototype Model – Disadvantages
 The code for prototype model is usually thrown way. So wasting of time is there.
 The construction cost of developing the prototype is very high.

 If the end user is not satisfied with the initial prototype, then he/she may lose interest in the
final product.
 Prototype Model – When to Use?
 This model is used when the desired system needs to have a lot of interactions with end users.
 This type of model generally used in GUI type of development.
8) Explain Spiral models with diagram.
 This model is proposed by Boehm in 1986.
 In application development, spiral model uses fourth generation (4GL) languages and
development tools.
 In pictorial view, this model appears like a spiral with many loops.
 Each loop of the spiral represents a phase of the software process.
 The innermost loop might be concerned with system feasibility
 The next loop with system requirement definition.
 The next one with system design and so on.
 Each loop in the spiral split into four sectors. (quadrants)
 1st Quadrant: Determine Objectives

 2nd Quadrant: Identify and resolve risks
 3rd Quadrant: Develop next level product
 4th Quadrant: Review and planning
 In spiral model, at any point, Radius represents: cost and Angular dimension represent:
progress of the current phase.
Spiral Model – Advantages
 It is more flexible, as we can easily deal with changes.
 Due to user involvement, user satisfaction is improved.

 New idea and functionality can be easily added at later stage.
Spiral Model – Disadvantages
 It is applicable for large problem only.
 It can be more costly to use.
 It is more complex to understand.
 More number of documents are needed as more number of spirals.
Spiral Model – When to Use?
 Used when medium to high risk projects.
 When user are unsure for their needs.
 When requirement are complex.
9) Explain Agile model.
 The meaning of Agile is swift or versatile.

 Agile means responsive to continuously changing requirements, technology and people.
 "Agile process model" refers to a software development approach based on iterative development.
 Agile methods break tasks into smaller iterations.
 Each iteration involves a team working through a full software development life cycle. It includes
planning, analysis, design, coding and testing before a working product is demonstrated to the
client.
 It takes minimum time for software development with greater accuracy.
 Advantages:

 Supports customer involvement and customer satisfaction

 Little planning required
 Efficient design
 Anytime changes are accepted(Adapt changes)
 Reduces total development time
 Frequent Delivery- Updated versions of functioning software are released every week.
 Disadvantages:
 Lack of proper documentation
 Depends heavily on customer interactions, if customer is not clear, the team can be driven in
wrong direction.
 When to use the Agile Model?
 When frequent changes are required.
 When a highly qualified and experienced team is available.
 When a customer is ready to have a meeting with a software team all the time.
 When project size is small.
10) Compare traditional model approaches Vs. Agile Model approach.
Traditional approach Agile approach
It is process oriented. It is people oriented.
Project scope and requirements are Project scope and requirements are more
less flexible. flexible.
Linear approach Iterative approach
Better for Large projects Better for Small and medium projects
Clear initital requirements Creative, innovative and unclear requirements
More rigid and structured. More flexible and adaptable.
In general- Waterfall, spiral or Evolutionary approach.

prototype approach

Unit-2
1) List characteristics of good software.
 Complete
 Consistent
 Structured
 Black-Box View
 Verifiable
 Adaptable
 Maintainable
 Portable
 Unambiguous
 Traceable
2) List requirement gathering techniques. Explain it.
 Requirement gathering is the first activity performed during the software development.
 The goal of requirement gathering activity is to collect all relevant information from the customer
regarding the product to be developed.

 In this phase, meeting with customers, analyzing market demand and features of the product are
mainly focused.
 Requirement gathering activities are
Studying the existing documents
Interview with end users
Task analysis
Scenario analysis
Brainstorming
Questionnaires
3) Differentiate analysis and design.
System Analysis System Design

Factors
System Analysis is the process of gathering System Design is the process of

and analyzing information to assess the specifying elements of a system such
Purpose
suitability of a current system and to as modules, architecture,
determine the requirements of a new system. components, and their interfaces.
System Design is a bottom-up

System Analysis is a top-down approach
approach where the analyst starts
Approach where the analyst looks at the big picture
with the details and moves up to the
first and then delves into the details.
big picture.
System Design focuses on the design

System Analysis focuses on the needs of the
of the system, its architecture, and
Scope user, the current system, and the business
the components that make up the
processes that the system must support.
system.
System Analysis produces the requirements System Design produces the design
Output
document that describes the desired system. document that describes the

System Analysis System Design

Factors
architecture and components of the

system.
System Design is an ongoing

System Analysis is a one-time process that
Time process that occurs throughout the
occurs at the beginning of the project.
project.
4) Differentiate Functional and Non-functional requirements.
Functional Requirement of SRS

 The functional requirements define the functions of the software and its components.
 It forms the core of requirement documents.
 The functional requirements for a system describe the functionalities or services that the system
is expected to provide.
 They provide how the system should react to particular input and how the system should behave
in a particular condition.
 The Goal of functional requirement is to capture the behavior of the software in terms of functions
and technology.
Non Functional Requirement of SRS

 Non functional requirements are requirements that specify criteria that can be used to judge the
operation of a system in particular conditions, rather than specific behavior.
 Sometimes these requirements are known as quality attributes.
 Non functional requirements describes the characteristics that cant be expressed
functionally,lke…
 Portability
 Reliability

 Security
 Scalability
 Usability
 Performance
 Inter operability
 Availability
5) Explain Cohesion with their classification.
 Cohesion is a measure of function strength of a module.

 Cohesion keeps the internal module together and represent the function strength.
 Cohesion of a module represents how tightly bound the internal element of a module are to one
another.
 Classification of cohesion (Types)
i. Coincidental(Low)
ii. Logical
iii. Temporal
iv. Procedural
v. Communicational
vi. Sequential
vii. Functional(High)
I. Coincidental cohesion
 It is lowest cohesion.
 It occurs when there is no meaningful relationship between the elements.
 A module is said to have coincidental cohesion if it perform a set of task that relate
each other very loosely.
II. Logical Cohesion
 A module is said to be logically cohesive if there is some logical relationship between
the element of module and element perform functions that fall into same logical class.

III. Temporal Cohesion

 It is same as logical cohesion except that the elements are related in time and are
executed together.
 A module is in temporal cohesion when a module contains functions that must be
executed in the same time span.
 Example: modules that perform activities like initialization, cleanup, startup and shut
down.
IV. Procedural cohesion
 A module has procedural cohesion when it contains elements that belongs to common
procedural unit.
 A module is said to have procedural cohesion, if the set of the module and all the part
of a procedure in which certain sequence of steps are carried out achieve an objective.
V. Communicational Cohesion
 A module is said to have communicational cohesion, if all functions of the module
refer to or update the same data structure.
VI. Sequential Cohesion.
 When the output of one element in a module forms the input to another module, we
get sequential cohesion.
 Sequential cohesion does not provide any guideline how to combine these
elements into modules.
VII. Functional Cohesion
 Functional cohesion is the strongest cohesion.
 In it, all the elements of the module are related to perform a single task.
 All elements are achieving a single goal of a module.
6) Explain classification of Coupling.
 Coupling between two modules is a measure of the degree of interaction between two modules.
 Coupling refers to the no of connections between „calling‟ and a „called‟ module.

 There must be at least one connection between them.

 It refers to the strengths of relationship between modules in a system. It indicates how closely two
modules interact and how they are interdependent.
 As modules become more interdependent, the coupling increases. And loose coupling minimize
interdependency that is better for any system development.
 High coupling between modules make the system difficult to understand and increase the
development efforts. So low coupling is the best.
 Classification of coupling
1. Data (Low) (Best)

2. Stamp
3. Control
4. Common
5. Content (High) (Worst)
I. Data Coupling
 Two modules are data coupled, if they communicate using an elementary data item that
is passed as a parameter between the two.
 Ex: an int, a char etc
 It is a lowest coupling and best for software development.
II. Stamp Coupling

 Two modules are stamp coupled, if they communicate using a composite data item such
as a record in PASCAL or a structure in C.
III. Control Coupling

 Control coupling exists between two modules, if data from one module is used to direct
the order of instructions execution in another.
 Ex: - flag set in one module and tested in another module.

IV. Common Coupling

 Two modules are common coupled, if they share data through some global data items.
V. Content Coupling
 Content coupling exists between two modules, if they share code.
 Ex:- a branch from one module into another module.
 It is a highest coupling and creates more problems in S/W development.
7) Explain the Data Flow Diagram with its primitive symbols and example.
 DFD is also called as bubble chart or data flow graph.

 DFDs are very useful in understanding the system and can be effectively used during analysis.
 It shows the flow of data through a system visually.
 The DFD is a hierarchical graphical model of a system that shows the different processing
activities or functions that the system performs and the data interchange among these functions.
 It views a system as a function that transforms the inputs into desired outputs.
 Each function is considered as a process that consumes some input data and produces some output
data.
 Primitive Symbols of DFD
 Process (Function)
i. Process is represented by circle or bubble.

ii. Circles are annotated with names of the corresponding functions.
iii. A process shows the part of the system that transforms inputs into outputs.
iv. The process is named using a single word that describe what the system does
functionality.

 External Entity
i. Entity is represented by rectangle.
ii. Entities are external to the system which interacts by inputting data to the
system or by consuming data produced by the system.
iii. It can also define source or destination of the system.
 Data Flow
i. Data flow is represented by an arc or by an arrow.
ii. It is used to describe the movement of the data.
iii. It represents the data flow occurring between two processes or between an
external entity and a process.
iv. It passes data from one part of the system to another part.
v. Data flow arrows usually annotated with the corresponding data names.
 Data Store
i. Data store is represented by two parallel lines.
ii. Generally it is a logical file or database.
iii. It can be either a data structure or a physical file on the disk.
 Output
i. Output is used when a hardcopy is produced.
ii. It is graphically represented by a rectangle cut either a side.

8) List the advantages of using the DFD model.
 It helps us to understand the functioning and the limits of a system.

 It is a graphical representation which is very easy to understand as it helps visualize contents.
 Data Flow Diagram represent detailed and well explained diagram of system components.
 It is used as the part of system documentation file.
 Data Flow Diagrams can be understood by both technical or nontechnical person because they
are very easy to understand.

9) Define use case diagram. Explain it with example.
 Use case model in UML provides system behavior.

 Use cases represent the different ways in which a system can be used by the users.
 The purpose of use case is to define the logical behavior of the system without knowing the
internal structure of it.
 UML describes “who can do what in a system”
 A use case represents a sequence of interactions between the user and the system.
 Components of Use Case Diagram:
 Use Case
i. Each use case is represented by ellipse with the name of the use case written
inside the ellipse.
ii. All the use cases are enclosed with a rectangle representing system boundary.
iii. Rectangle contains the name of the system.
 Actor
i. An actor is anything outside the system that interacts with it.
ii. Actors in the use case diagram are represented by using the stick person icon.
iii. An actor may be a person, machine or any external system.
iv. In use case diagrams, actors are connected to use cases by drawing a simple line
connected to it.
v. Actor triggers use case.
vi. Each actor must be linked to a use case, while some use cases may not be linked
to actors.
 Relationship
i. Actors are connected to the use cases through relationship.
ii. An actor may have relationship with more than one use case and one use case
may relate to more than one actor.
iii. Types of relationship
1. Association

2. Include Relationship
3. Extend Relationship.
 Association
i. This relationship is the interface between an actor and a use case.
ii. It is represented by joining a line from actor to use case.
 Include Relationship
i. It involves one use case including the behavior of another use case.
ii. The “include” relationship occurs when a chunk of behavior that is similar
across a number of use cases.
 Extend Relationship
i. It allows you to show optional behavior of the system.
ii. This relationship among use cases is represented as a stereotype <<extend>>.
iii. Extend relationship exists when one use case calls another use case under
certain condition.

Unit-3
1) List out responsibilities of Project manager and skills required in project manager.
 Software project managers take the overall responsibility of project to success.
 The job responsibility of a project manager ranges from invisible activities like building up team
morale to highly visible customer presentations.
 Most managers take responsibility for project proposal writing, project cost estimation,
scheduling, project staffing, deciding software process, project monitoring and control, software
configuration management, risk management, interfacing with clients, and presentations.
 These activities can be classified into project planning, and project monitoring and control
activities.
 Skills necessary for software project manager
 A theoretical knowledge of different project management techniques is certainly necessary to
become a successful project manager.
 In addition to having a good understand of the latest software project management techniques
such as cost estimation, risk management, configuration management, project managers need
good communication skills.
 However, some skills such as tracking and controlling the progress of the project, customer
interaction, managerial presentations, and team building are largely acquired through experience.
2) Explain COCOMO model.

 COCOMO (Constructive Cost Estimation Model) was proposed by Boehm (1981). According to
the Boehm any software development project can be classified into one of the following three
categories based on the development complexity: organic, semidetached, and embedded.
 Organic: A development project can be considered of organic type, if the project deals with
developing a well understood application program, the size of the development team is small, and
the team members are experienced in developing similar types of projects.
 Semidetached: A development project can be considered of semidetached type, if the
development consists of a mixture of experienced and inexperienced staff.
 Embedded: A development project is considered to be of embedded type, if the software being

developed is strongly coupled to complex hardware.
 Types of COCOMO Model:
I. Basic COCOMO Model
II. Intermediate COCOMO model
III. Complete COCOMO model
 Basic COCOMO Model

The basic COCOMO model gives an approximate estimate of the project parameters. The basic
COCOMO estimation model is given by the following expressions:
Effort = a1 × (KLOC)a2 PM
Tdev = b1 × (Effort)b2 Months
Where
KLOC is the estimated size of the software product expressed in Kilo Lines of Code
a1, a2, b1, b2 are constants for each category of software products
Tdev is the estimated time to develop the software, expressed in months
Effort is the total effort required to develop the software product, expressed in person months
(PMs)
 Intermediate COCOMO model
The intermediate COCOMO model recognizes this fact and refines the initial estimate obtained
using the basic COCOMO expressions by using a set of 15 cost drivers (multipliers) based on
various attributes of software development.
For example, if modern programming practices are used, the initial estimates are scaled
downward.
If there are reliability requirements on the software product, this initial estimate is scaled upward.
In general, the cost drivers can be classified as being attributes of the following items:
Product: The characteristics of the product like reliability requirements of the product.
Computer: Characteristics of the computer like execution speed required, storage space required
etc.
Personnel: experience level of personnel, programming capability, analysis capability, etc.

Development Environment: use of the automation (CASE) tools used for software development.
 Complete COCOMO model
A major shortcoming of both the basic and intermediate COCOMO models is that they consider
a software product as a single entity.
However, most large systems are made up several smaller sub-systems. These subsystems may
have widely different characteristics.
For example, some subsystems may be considered as organic type, some semidetached, and some
embedded. Not only that the development complexity of the subsystems may be different, but also
for some subsystems the reliability requirements may be high, for some the development team
might have no previous experience of similar development, and so on.
The complete COCOMO model considers these differences in characteristics of the subsystems
and estimates the effort and development time as the sum of the estimates for the individual
subsystems.
3) 3. Explain the Line of Code (LOC) Size Estimation Technique.
 LOC metric is very popular because it is the simplest to use. Using this metric, the project size is
estimated by counting the number of source instructions in the developed program.
 Lines used for commenting the code and the header lines should be ignored.
 Determining the LOC count at the end of a project is a very simple job.
 To estimate the LOC count at the beginning of a project, project managers usually divide the
problem into modules and each module into sub modules and so on, until the sizes of the different
leaf-level modules can be approximately predicted.
 Disadvantages of Lines of Code (LOC) metric
 A good problem size measure should consider the overall complexity of the problem and the effort
needed to solve it. That is, it should consider the effort needed to specify, design, code, test, etc.
and not just the coding effort.
 LOC focuses on the coding activity alone; it only computes the number of source lines in final
program.

4) Explain different types of risks in brief.

 Project risks
 Project risks concern varies forms of budgetary, schedule, personnel, resource, and customer-
related problems. An important project risk is schedule. It is very difficult to monitor and
control a software project.
 The invisibility of the product being developed is an important reason why many software
projects suffer from the risk of schedule.
 Technical risks
 Technical risks concern design, implementation, interfacing, testing, and maintenance
problems.
 Technical risks also include ambiguous specification, incomplete specification, changing
specification, technical uncertainty. Most technical risks occur due to the development team’s
insufficient knowledge about the project.
 Business risks
 This type of risks include risks of building an excellent product that no one wants, losing
budgetary or personnel commitments, etc.
5) Define Projects scheduling. Give full form of LOC, FP, COCOMO

 Project-task scheduling is a significant project planning activity. It comprises deciding which
functions would be taken up when.
LOC-Lines of Code
FP-Functional Point
COCOMO- Constructive Cost Model

6) Draw Gantt chart and flow chart for Online shopping system.
 Gantt chart
 Flowchart

7) Explain Risk Assessment in detail.

 Risk assessment involves identifying risk, analyzing them and then assigns priority to them on the
basis of the analysis.
 The objective of risk assessment is to rank the risks in terms of their damage. For risk assessment,
first each risk should be rated in two ways:
 The probability of a risk coming true (denoted as r).
 The result of the problems associated with that risk (denoted as s).
 Based on these two factors, the priority of each risk can be computed:
 p=r*s
 Where, p is the priority with which the risk must be handled, r is the probability of the risk
becoming true, and s is the result of damage caused due to the risk becoming true. If all identified
risks are prioritized, then the most likely and damaging risks can be handled first and reject
procedures can be designed for these risks.
8) Explain Risk identification in detail.

 A software project can be affected by a large variety of risks. In order to be able to systematically
identify the important risks which might affect a software project, it is necessary to categorize
risks into different classes.
 The project manager can then examine which risks from each class are relevant to the project.
There are three main categories of risks which can affect a software project:
 There are different types of risks which can affect a software project:
 Technology risks: Risks that assume from the software or hardware technologies that are used
to develop the system.
 People risks: Risks that are connected with the person in the development team.
 Organizational risks: Risks that assume from the organizational environment where the
software is being developed.
 Tools risks: Risks that assume from the software tools and other support software used to
create the system.

Unit - 4
1) Define code review. List code review techniques. Explain them in detail.
 Code review for a model is carried out after all the syntax errors have been eliminated.
 This is the cost-effective strategies for reduction in coding errors and to produce high quality code.
 Two types code review techniques are code inspection and code walkthrough.
 Code Inspection:
 The aim of code inspection is to discover common types of errors caused due to improper
programming.
 During code inspection the code is examined for the presence of certain kinds of errors.
 Error will be discovered by looking for these kinds of mistakes in the code.
 Coding standards is also checked during code inspection
 Good software development companies collect different types of errors commonly committed
by their engineers and identify the type of errors most frequently committed.
 List of commonly committed errors can be used during code inspection to look out for possible
errors.
 Following is a list of some errors which can be checked during code inspection:
 Use of uninitialized variables
 No terminating loops
 Incompatible assignments
 Array indices out of bounds
 Improper storage allocation and deallocation
 Mismatches between actual and formal parameter in procedure calls
 Use of incorrect logical operators or incorrect precedence among operators
 Code walkthrough:
 Code walk through is a code analysis technique.
 In this technique carried out after a module has been coded, successfully compiled and all
syntax errors eliminated.
 A few members of the development team are given the code few days before the walkthrough
meeting to read and understand code.
 Each member selects some test cases and simulates execution of the code by hand (i.e. trace
execution through each statement and function execution).
 The main objectives of the walk through are to find the algorithmic and logical errors in the
code.
 The members note down their findings to discuss these in a walk through meeting where the
coder of the module is present.
 Some of the guidelines for this technique:
 It should consist of between three to seven members.
 Discussion should focus on find the errors and not on how to fix the errors.
 Managers should not attend the walk through meetings
2) Describe white box testing.
 In this method of testing the test cases are calculated based on analysis internal structure of the
system based on Code coverage, branches coverage, paths coverage, condition Coverage etc.
 White box testing involves the testing by looking at the internal structure of the code & when you
completely aware of the internal structure of the code then you can run your test cases & check
whether the system meet requirements mentioned in the specification document.
 Based on derived test cases the user exercised the test cases by giving the input to the system and
checking for expected outputs with actual output.
 Statement coverage
 The statement coverage strategy aims to design test cases so that every statement in a program
is executed at least once.
 The principal idea governing the statement coverage strategy is that unless a statement is
executed, it is very hard to determine if an error exists in that statement.
 Unless a statement is executed, it is very difficult to observe whether it causes failure due to
some illegal memory access, wrong result computation, etc.
 For ex.
If(a>b)
printf(“a is greater”)

else
printf(“b is greater than”)

 Test cases for above example: {a=5,b=10}, {a=10,b=5}
 Branch coverage
 In the branch coverage-based testing strategy, test cases are designed to make each branch
condition to assume true and false values in turn.
 Branch testing is also known as edge testing as in this testing scheme, each edge of a program’s
control flow graph is traversed at least once.
 It is obvious that branch testing guarantees statement coverage and thus is a stronger testing
strategy compared to the statement coverage-based testing.
 For example, find maximum from three number:
If(a>b && a>c)
max=a;
else if (b>c)
max=b;
else
max=c;
}
 Test cases for above example: {a=5,b=10,c=15}, {a=5,b=15,c=10}, {a=15, b=5, c=10}

 Condition coverage
 In this structural testing, test cases are designed to make each component of a composite
conditional expression to assume both true and false values.
 For example, in the conditional expression ((c1.and.c2).or.c3), the components c1, c2 and c3
are each made to assume both true and false values.
 Branch testing is probably the simplest condition testing strategy where only the compound
conditions appearing in the different branch statements are made to assume the true and false
values.
 Thus, condition testing is a stronger testing strategy than branch testing and branch testing is
stronger testing strategy than the statement coverage-based testing.
 For a composite conditional expression of n components, for condition coverage, 2ⁿ test cases
are required. Thus, for condition coverage, the number of test cases increases exponentially
with the number of component conditions.
 Therefore, a condition coverage-based testing technique is practical only if n (the number of
conditions) is small.
 Path coverage
 The path coverage-based testing strategy requires us to design test cases such that all linearly
independent paths in the program are executed at least once.
 A linearly independent path can be defined in terms of the control flow graph (CFG) of a
program.
 Path testing is used for module or unit testing.
 It requires complete knowledge of the program structure.
3) Describe Unit testing and Integration testing.
 Unit testing
 Unit testing is undertaken after a module has been coded and successfully reviewed.
 Unit testing (or module testing) is the testing of different units (or modules) of a system in
separately.

 When developer is coding the software it may happen that the dependent modules are not
completed for testing, in such cases developers use stubs and drivers to simulate the called
(stub) and caller (driver) units.
 Unit testing requires stubs and drivers, stub represent the called unit and driver represent the
calling unit.
 Integration Testing
 Integration testing is the second level of the software testing process comes after unit testing.
 In this testing, units or individual components of the software are tested in a group.
 The focus of the integration testing level is to expose defects at the time of interaction between
integrated components or units.
4) Differentiate Unit testing and Integration testing.
Unit Testing Integration Testing
In unit testing, each module of the software In integration testing, all modules of the
is tested separately. software are tested combined.
In unit testing tester knows the internal Integration testing doesn’t know the internal
design of the software. design of the software.
Unit testing is performed first of all testing Integration testing is performed after unit
processes. testing and before system testing.
Unit testing is white box testing. Integration testing is black box testing.
Unit testing is performed by the developer. Integration testing is performed by the tester.
Detection of defects in integration testing is

Detection of defects in unit testing is easy.
difficult.
It tests parts of the project without waiting for
It tests only after the completion of all parts.
others to be completed.
Unit testing is less costly. Integration testing is more costly.

Unit testing is responsible to observe only the Error detection takes place when modules are
functionality of the individual units. integrated to create an overall system.
Module specification is done initially. Interface specification is done initially.
The proper working of your code with the The proper working of your code with the
external dependencies is not ensured by unit external dependencies is ensured by
testing. integration testing.
Maintenance is cost effective. Maintenance is expensive.
Fast execution as compared to integration Its speed is slow because of the integration of
testing. modules.
Unit testing results in in-depth exposure Integration testing results in the integration
to the code. structure’s detailed visibility.
5) Differentiate alpha testing and beta testing.
Alpha Testing Beta Testing
Alpha testing involves both the white box Beta testing commonly uses black-box
and black box testing. testing.
Alpha testing is performed by testers who are
Beta testing is performed by clients who are
usually internal employees of the
not part of the organization.
organization.
Alpha testing is performed at the developer’s Beta testing is performed at the end-user of
site. the product.
Reliability and security testing are not Reliability, security and robustness are
checked in alpha testing. checked during beta testing.
Beta testing also concentrates on the quality
Alpha testing ensures the quality of the of the product but collects users input on the
product before forwarding to beta testing. product and ensures that the product is ready
for real time users.
Alpha testing requires a testing environment Beta testing doesn’t require a testing
or a lab. environment or lab.
Alpha testing may require a long execution Beta testing requires only a few weeks of
cycle. execution.

Most of the issues or feedback collected from

Developers can immediately address the
the beta testing will be implemented in future
critical issues or fixes in alpha testing.
versions of the product.
Multiple test cycles are organized in alpha Only one or two test cycles are there in beta
testing. testing.
6) Prepare test cases for online shopping system.
 User Registration:
 Test case 1: Verify that a new user can successfully register with valid credentials.
 Test case 2: Verify that registration fails if the user provides invalid or incomplete information.
 Test case 3: Verify that registration fails if the user tries to register with an existing email
address.
 User Login:
 Test case 4: Verify that a registered user can log in with correct credentials.
 Test case 5: Verify that login fails with incorrect credentials.
 Test case 6: Verify that login fails if the user provides invalid input.
 Browsing Products:
 Test case 7: Verify that the user can browse products without logging in.
 Test case 8: Verify that the user can search for products using the search functionality.
 Test case 9: Verify that the user can filter products based on different criteria (e.g., price,
category).
 Test case 10: Verify that the user can view detailed information about a product.
 Adding Items to Cart:
 Test case 11: Verify that the user can add items to the cart.
 Test case 12: Verify that the user cannot add more items to the cart than the available stock.
 Test case 13: Verify that the user can update the quantity of items in the cart.
 Checkout Process:
 Test case 14: Verify that the user can proceed to checkout from the cart.
 Test case 15: Verify that the user can select a shipping address during checkout.

 Test case 16: Verify that the user can select a payment method during checkout.
 Test case 17: Verify that the user can place an order successfully.
 Order Management:
 Test case 18: Verify that the user can view their order history.
 Test case 19: Verify that the user can track the status of an order.
 Test case 20: Verify that the user can cancel an order before it is shipped.
 Account Management:
 Test case 21: Verify that the user can update their account information (e.g., name, address).
 Test case 22: Verify that the user can change their password.
 Test case 23: Verify that the user can delete their account.
 Security:
 Test case 24: Verify that sensitive information (e.g., passwords, payment details) is encrypted
and securely stored.
 Test case 25: Verify that the system prevents unauthorized access to user accounts.
 Performance:
 Test case 26: Verify that the system can handle a large number of simultaneous users.
 Test case 27: Verify that the response time for critical actions (e.g., adding items to cart,
checkout) is acceptable under normal load conditions.
 Compatibility:
 Test case 28: Verify that the website is compatible with different web browsers (e.g., Chrome,
Firefox, Safari).
 Test case 29: Verify that the website is responsive and works well on different devices (e.g.,
desktops, tablets, smartphones).
==== XXX====

ise_questionsanswers

Uploaded by

Copyright:

Available Formats

ise_questionsanswers

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ise_questionsanswers

Uploaded by

Copyright:

Available Formats

Subject Name: Introduction to Software Engineering Subject Code: 4340702

IMP Question with Answers

2) Explain types of software with examples.

 Software Application Domain types:

Prepared By: Department of Computer Engineering Page 1

 It is responsible for controlling, integrating the hardware components of a system so the

Software engineering can be viewed as a layered technology.

Prepared By: Department of Computer Engineering Page 3

Umbrella activities are performed throughout the process.

 Waterfall model was proposed by Royce in 1970.

Prepared By: Department of Computer Engineering Page 5

 Requirement Analysis and Specification:

Prepared By: Department of Computer Engineering Page 6

Prepared By: Department of Computer Engineering Page 7

Incremental Model – Advantages

 Prototype is a working physical system or subsystem.

Prepared By: Department of Computer Engineering Page 8

Prepared By: Department of Computer Engineering Page 9

 1st Quadrant: Determine Objectives

 Due to user involvement, user satisfaction is improved.

 The meaning of Agile is swift or versatile.

Prepared By: Department of Computer Engineering Page 11

 Supports customer involvement and customer satisfaction

Traditional approach Agile approach

It is process oriented. It is people oriented.

Linear approach Iterative approach

Clear initital requirements Creative, innovative and unclear requirements

More rigid and structured. More flexible and adaptable.

In general- Waterfall, spiral or Evolutionary approach.

Prepared By: Department of Computer Engineering Page 12

2) List requirement gathering techniques. Explain it.

Prepared By: Department of Computer Engineering Page 13

3) Differentiate analysis and design.

System Analysis System Design

System Analysis is the process of gathering System Design is the process of

System Design is a bottom-up

System Design focuses on the design

Prepared By: Department of Computer Engineering Page 14

System Analysis System Design

architecture and components of the

System Design is an ongoing

4) Differentiate Functional and Non-functional requirements.

Functional Requirement of SRS

Non Functional Requirement of SRS

Prepared By: Department of Computer Engineering Page 15

5) Explain Cohesion with their classification.

 Cohesion is a measure of function strength of a module.

Prepared By: Department of Computer Engineering Page 16

III. Temporal Cohesion

6) Explain classification of Coupling.

Prepared By: Department of Computer Engineering Page 17

 There must be at least one connection between them.

1. Data (Low) (Best)

II. Stamp Coupling

III. Control Coupling

Prepared By: Department of Computer Engineering Page 18

IV. Common Coupling

 DFD is also called as bubble chart or data flow graph.

i. Process is represented by circle or bubble.

Prepared By: Department of Computer Engineering Page 19