Chapter 1.

1. Why is primary goal of software development now shifting from producing good
quality software to good quality maintainable software?
Due to increase in cost of maintaining software, is now shifting to produce quality
software that is maintainable, delivered on time, within budget, and also satisfies its
requirements

2. List the reasons for the “software crisis”? Why are CASE tools not normally able to
control it?
Reasons for Software Crisis:
- Nonexistence of communication between software developers and user
- Due to growth in size of software
- Due to growth in complexity of the problem
- Lack of understanding of the issue
- Due to poor approximation of cost, time, size and planning
Case tools are unable to control software crisis because the major reason of the software
crisis is that the mechanisms have become several orders of extent more powerful. To put
it rather bluntly, as long as there were no machines, software design was no problem at all.
When we had a few weak computers, programming became a mild problem, and now we
have gigantic computers, programming has become an equally gigantic problem

3. “The software crisis is aggravated by the progress in hardware Technology?” Explain with
examples.

4. What is software crisis? Was Y2K a software crisis?

Software Crisis is a term used in computer science for the difficulty of writing useful and
efficient computer programs in the required time. Software crisis was due to using same
workforce, same methods, and same tools even though rapidly increasing in software
demand, complexity of software and software challenges. With increase in the complexity
of software, many software problems arise because existing methods were in sufficient.

Y2K was both a software and hardware problem. Software and hardware companies raced
to fix the bug and provided "Y2Kcompliant" programs to help. The simplest solution was
the best: The date was simply expanded to a four-digit number.

Unlike hardware, software is logical rather than physical. It has to be designed well before
producing it. Inspire of availability of many automated software development tools, it is the
skill of the individual, creativity of the developers and proper management by the project
manager that counts for a good software product. (2).Software does not "wear out":-- As
time progresses, the hardware components start deteriorating-they are subjected to
environmental maladies such as dust, vibration, temperature etc. and at some point of time
they tend to breakdown. The defected components can then be traced and replaced. But,
 software is not susceptible to the environmental changes. Do, it does not wear out. The
software works exactly the same way even after years it was first developed unless any
charges are introduced to it.

5. What is the significance of software crisis in reference to software

Engineering discipline.

As the computing systems became larger & complex, the demand for computer software
grew faster than our ability to produce and maintain it. To control this software crisis, some
methodical approach was needed for software development. This is where “Software
Engineering” comes in, to deal with this crisis, the term ‘Software Engineering’ was
coined.
IEEE defines ‘software as the collection of a computer program, procedures, rules, and
associated documentation and data

6. How are software myths affecting software process? Explain with the help of examples.
Management perspective
- More skilled programmers will bring project back to schedule (only increase the time)
- More latest Tech will provide the best products(only one of the factors)
- Good standards and clear procedure (the taste of the food is in the eating not the recipe)
- Software is easy to change (the more changes the hard it is)

Customer’s perspective
- A general statement is enough to produce software(need details)
- Software can run at the first trial(not true)
- Software with more features is better(even harder to make)

Programmer Perspective
- Working software is enough (goal today is to provide maintainable software)
- Once program is demonstrated then its created(not true)
- Software quality should be assessed before testing(it should be throughout)
- Tested code is the only derivable(its only part)

7. State the difference between program and software. Why have documents
and documentation become very important.

1. Software :
Software, as name suggest, is simply a collection or set of programs, procedures, data or
instructions to instruct computer about what to do and are designed to perform well
defined function.
2. Program:
Program, as name suggests, is simply a collection of instructions or ordered operations
for computer to perform specific function or perform particular task and achieve a
specific result.
8. What is a software process? Why is it difficult to improve software process?

The software process is the way in which we produce software.

- Not enough time
- Lack of knowledge
- Wrong motivation
- Insufficient commitment

9. What is software engineering? Is it an art, craft or a science? Discuss.

What is aim of software engineering? What does the discipline of software engineering
discuss?

10. Define the term “Software engineering”. Explain the major differences between software
engineering and other traditional engineering disciplines.

11. Describe the characteristics of software contrasting it with the

Characteristics of hardware.

- Does not wear out

- Is not manufactured. For example by using raw materials
- Flexible
- Reusable

12. Write down the major characteristics of a software. Illustrate with a diagram that the
software does not wear out.

- Does not wear out

- Is not manufactured. For example by using raw materials
- Flexible
- Reusable

13. What are the components of a software? Discuss how a software differs from a program.
Software compresses of

- Program
- Documentation
- Operational procedure

14. Discuss major areas of the applications of the software.

Areas of Application:-
1) Embedded and Real-Time Systems. One of the application areas of software where
correctness is more critical is embedded systems. ...
2) Safety-Critical Systems.
3) Service Oriented Architectures.
 4) Security.

15. Is software a product or process? Justify your answer with example

16. Describe the role of management in software development with the help of examples.

17. What are various factors of management dependency in software development? Discuss
each factor in detail.
People
Of course, the management has to deal with people in every stage
of the software developing process. From the ideation phase to the
final deployment phase, including the development and testing
phases in between, there are people involved in everything,
whether they be the customers or the developers, the designers or
the salesmen. Hence, how they contact and communicate with each
other must be managed so that all the required information is
successfully delivered to the relevant person and hence there is no
communication gap between the customers and the service
providers.
Project
From the ideation phase to the deployment phase, we term the
process as a project. Many people work together on a project to
build a final product that can be delivered to the customer as per
their needs or demands. So, the entire process that goes on while
working on the project must be managed properly so that we can
get a worthy result after completing the project and also so that the
project can be completed on time without any delay.
Process
Every process that takes place while developing the software, or we
can say while working on the project must be managed properly
and separately. For example, there are various phases in a software
development process and every phase has its process like the
designing process is different from the coding process, and
similarly, the coding process is different from the testing. Hence,
each process is managed according to its needs and each needs to
be taken special care of.
Product
Even after the development process is completed and we reach our
final product, still, it needs to be delivered to its customers. Hence
the entire process needs a separate management team like the
sales department.
 18. What is more important: Product or process? Justify your answer.

The product is more important. People buy products and not processes.
They do not care about the process. The product is all to the final arbiter,
the end user.

Having an efficient process is only important to the accountants to help

reduce costs and make a bigger profit for the manufacturer.

CHAPTER 2

1. Describe the type of situations where iterative enhancement model might lead to
difficulties

● When project is small.

● When project has changing requirements.

2. What are the advantages of developing the prototype of a system?

● Reduced time

● Reduced cost

● Increased user involvement

3. List the advantages and disadvantages of involving a software engineer throughout

the software development planning process.
● Estimates of period

● High chances of delivering satisfying software

● Reduced failure

● Shorter delivery time

4. Discuss the selection process parameters for a life cycle model.

1. Requirements characteristics:
● Reliability of Requirements

● How often the requirements can change

● Types of requirements
● Number of requirements
 ● Can the requirements be defined at an early stage
● Requirements indicate the complexity of the system
2. Development team :
● Team size

● Experience of developers on similar type of projects

● Level of understanding of user requirements by the developers
● Environment
● Domain knowledge of developers
● Experience on technologies to be used
● Availability of training
3. User involvement in the project :
● Expertise of user in project

● Involvement of user in all phases of the project

● Experience of user in similar project in the past
4. Project type and associated risk :
● Stability of funds

● Tightness of project schedule

● Availability of resources
● Type of project
● Size of the project
● Expected duration for the completion of project
● Complexity of the project
● Level and the type of associated risk

CHAPTER 3.

1. Discuss The Significance And Use Of Requirement Engineering. What Are The
Problems In Formulation Of Requirements?

Requirements engineering is the most important step in software development because

when you know "what to make" then you make "what to make". It also help you find and
apply boundaries/limits while developing a software.
Some of the problems
● requirement elicitation,
 ● requirement analysis,

● identifying function and nonfunctional requirements,

● stake holders roles etc

2. Requirements Analysis Is Unquestionably The Most Communication Intensive Step

In The Software Engineering Process. Why Does The Communication Path
Frequently Break Down ?

Requirements analysis involves frequent communication with system users to determine

specific feature expectations,

● resolution of conflict or ambiguity in requirements as demanded by the various users

or groups of users,

● avoidance of feature creep and documentation of all aspects of the project

development process from

3. What are crucial process steps of requirement engineering? Discuss with the help of a
diagram
Requirement Engineering is the process of defining, documenting and maintaining the
requirements. It is a process of gathering and defining service provided by the system.
Requirements Engineering Process consists of the following main activities:

● Requirements elicitation

● Requirements specification (Analysis)

● Requirements verification and validation

● Requirements management(Requirements Documentation)

CHAPTER 4 SOFTWARE PROJECT PLANNING.

1. Explain The Concept Of Function Points. Why Fps Are Becoming Acceptable In
Industry?

A Function Point (FP) is a unit of measurement to express the amount of business

functionality, an information system (as a product) provides to a user. FPs measure
software size. They are widely accepted as an industry standard for functional sizing.
For sizing software based on FP, several recognized standards and/or public specifications
have come into existence. As of 2013, these are −
Function Point Analysis (FPA) technique quantifies the functions contained within
software in terms that are meaningful to the software users. FPs consider the number of
functions being developed based on the requirements specification.
Function Points (FP) Counting is governed by a standard set of rules, processes and
guidelines as defined by the International Function Point Users Group (IFPUG). These are
published in Counting Practices Manual (CPM).
Elementary Process (EP)
Elementary Process is the smallest unit of functional user requirement that −
• Is meaningful to the user.
• Constitutes a complete transaction.
• Is self-contained and leaves the business of the application being counted in a consistent
state.
Functions:-
There are two types of functions −
• Data Functions
• Transaction Functions
Data Functions:-
There are two types of data functions −
• Internal Logical Files
• External Interface Files
Data Functions are made up of internal and external resources that affect the system.
Internal Logical Files
Internal Logical File (ILF) is a user identifiable group of logically related data or control
information that resides entirely within the application boundary. The primary intent of an
ILF is to hold data maintained through one or more elementary processes of the application
being counted. An ILF has the inherent meaning that it is internally maintained, it has some
logical structure and it is stored in a file.
External Interface Files
External Interface File (EIF) is a user identifiable group of logically related data or
control information that is used by the application for reference purposes only. The data
resides entirely outside the application boundary and is maintained in an ILF by another
application. An EIF has the inherent meaning that it is externally maintained, an interface
has to be developed to get the data from the file.
2. What Are Size Metrics? How Is Function Point Metric Advantageous Over LOC
Metric? Explain.

Based on the “size” of the software produced. Project data measured, including cost and
effort, pages, defects…etc. Mainly uses the LOC as the normalization value Advantages:
easily counted, large body of literature and data based on LOC Disadvantages: language
dependent, programmer dependent. Useful for projects with similar environment.
Therefore, size-oriented metrics are not universally accepted as the best way to measu re
the software process.

Productivity = Size / Effort = kLOC/ person-month Quality= Errors / Size = Errors / kLOC
Cost= $ / kLOC Documentation= pages / kLOC Other metrics can also be developed
like:errors/KLOC, page/KLOC...etc. Or errors/person-month,
LOC/person-month,cost/page.

Function Points Function Point Analysis is an objective and structured technique to

measure software size by quantifying its functionality provided to the user, based on the
requirements and logical design. This technique breaks the system into smaller components
so they can be better understood and analyzed. Function Point count can be applied to
Development projects, Enhancement projects, and existing applications as well. There are
5 major components of Function Point Analysis which capture the functionality of the
application. These are: External Inputs (EIs), External Outputs (EOs), External Inquiries
(EQs), Internal Logical Files (ILFs) and External Interface File

3. There are significant risks even in student projects. Analyze a student project and list the
risks.
o BUILDING THE WRONG PRODUCT Risk: Student may not understand the
project requirements correctly, and waste time developing the wrong product.
o PROBLEMATIC TEAM MEMBERS Risk: Some team members might fail to
contribute as expected, or behave in other ways
o Communication problems
o Illness and social problems
o Motivation level
o Documentation problems
o Scheduling problems
o Third-party components
o Group related problems

4. It Seems Odd That Cost And Size Estimates Are Developed During Software Project
Planning-Before Detailed Software Requirements Analysis Or Design Has Been
 Conducted. Why Do We Think This Is Done? Are There Circumstances When It
Should Not Be Done?
Defining the price of the software is a big issue in software development. For example, say
someone asked how much money it took to make a X software (or any software). They did
not say anything about this software but asked only how much it costs (without
requirement). But what could be the answer, because without the necessary information it
can't be answered. In the case of software development many have a cost estimation but
have no way to do a software development cost estimation without requirement collection.
Is this also a problem you have come across?

5. Is it possible to estimate software size before coding? Justify your answer with
suitable example.

A vital part of 'Software Project Management' is estimating the size of the computer.
Different types are used in estimating the size of the project. Some of the following are:

Lines of Code count the total number of lines of source code in a project.

The number of entities in the ER model can be used to measure the estimation of the size of
the project.

Making use of the number of functions required in the data flow diagram to predict
'software size.

Function points count based on the number and type of functions supported by the
software.
 SOFTWARE DESIGN

1. What is design? Describe the difference between conceptual design and technical
design.
Conceptual and Technical Designs

To transform requirements into a working system designers must satisfy both customers
and the system builders. The customers should understand what the system it to do at the
same time the system builders must understand how to do. To accomplish these design is
divided into two parts as shown in fig 5.2, and is called as the two parts iterative process.
The two parts are given below:

● Conceptual design or preliminary design.

● Technical design or detailed design.

First the conceptual design is produced that tells the customer exactly what the system will
do. It beings to the part of the solution. Once the customer approves it is translated into a
much more detailed document i. e. the technical design which allows system builders to
understand the actual hardware and software needed to solve the customer’s problem. It
belongs to the how part of the solution.

The process is iterative because in actuality, the designers move back and forth among
activities involving understanding the requirements possible solution testing aspects of a
solution for feasibility, presenting possibilities of the customers and documenting the
design for the programmers.

As we know system is defined by its boundary entities attributes and relationships. The
conceptual design describes each of these system aspects by answering questions such as
the following:

● Where will the data come from?

● What will happen to the data in the system?
● What will the system look like to users?
● What choices will be offered to users?

The conceptual design describes the system in language that the customer can
understand. It may even list acceptable responses and the actions that may result. A good
conceptual design should have the following characteristics:

● It is written in the customer language.

● It contains no technical jargon.
 ● It describes the functions of the system.
● It is independent of implementation
● It is linked to the requirements documents.

By contrast, the technical design describes the hardware configuration, the software needs.
Communication interfaces. The input and output of the system, the software architecture,
and anything else’s that translates their requirements into a solution to the customer
problem. That is the technical design description is a technical picture of the system
specification. It usually include at least three items given below:

A description of the major hardware components and their functions,

The hierarchy and function of the software components, and

The data structures and the data flow.

2. Discuss the objectives of software design. How do we transform an informal design to

a detailed design?

Objectives of Software Design:

● Correctness:
A good design should be correct i.e. it should correctly implement all the functionalities of
the system.
● Efficiency:
A good software design should address the resources, time and cost optimization issues.
● Understandability:
A good design should be easily understandable, for which it should be modular and all the
modules are arranged in layers.
● Completeness:
The design should have all the components like data structures, modules, and external
interfaces, etc.
● Maintainability:
A good software design should be easily amenable to change whenever a change request is
made from the customer side.

3. Do we design software when we “write” a program? What makes software design different
from coding?
o Step 1 of 1
 o Design software
o No, writing a program is the different concept in design software. Design is the place where
software quality is established. Before starting of design software, first requirements should
be analyzed and specified.
o In the software design process, design engineering is the one of the concept. While
beginning software, requirements have been analyzed and modeled. This model can be
accessed for quality and improved before code is generated.
o In a software engineering context, first need to develop the models of program. Not the
program themselves.
o Software design different from coding:
o At first it is very clear that, design is not coding and coding is not design. It is created
from program components.
o Design is the description of the logic, which is used in solving the problem. Coding is the
language specification which is implementation of the design. It runs on the computer and,
provides the expected result.

12.1. Do you design software when you “write” a program? What makes software design
different from coding?
No, writing a program is the different concept in design software. Design is the place where
software quality is established. Before starting of design software, first requirements should be
analyzed and specified. In the software design process, design engineering is the one of the
concept. While beginning software, requirements have been analyzed and modeled. This model
can be accessed for quality and improved before code is generated. In a software engineering
context, first need to develop the models of program. Not the program themselves.Software design
different from coding:Emmergency Contact:[email protected]
PRESSMAN BOOKS QUESTION SOLUTION(Collected Form Google)At first it is very clear
that, design is not coding and coding is not design. Itis created from program components.Design is
the description of the logic, which is used in solving the problem. Coding is thelanguage
specification which is implementation of the design. It runs on the computer and,provides the
expected result.12.2. If a software design is not a program (and it isn’t), then what is it?Yes,
software design is not a program. Coding or programming is a language which is usedto represent
the design. Programming is not good for representing details of architecture,components or their
collaborations.Software design contains a set of principles, concepts, and practices which leads
todevelopment of high quality product. Design plays an important role in the development of
asuccessful software product.The main aim of design is to create a model that presents firmness,
commodity, and delightto customers those who use it. Software engineering continuously changes
with newmethods for better analysis and to evolve broader understanding.Software design is like a
kernel of software engineering. Software design is an action with thesoftware engineering
modelling activity, followed by code generation and testing.The following are design methods
which are implemented in software engineering:• Object/Class design• Architectural design•
Interface design• Component design12.3. How do we assess the quality of a software design?The
quality of software is assessed based on the design even before it is implemented. During design,
the quality is assessed by conducting a series of technical reviews. The following are the guidelines
to assess the quality of the software design:• A design should be simple created by using
recognizable patterns which are easier for implementation and testing.• A design should be
modular that is, it can be broken down into smaller sub systems.Emmergency
Contact:[email protected]
PRESSMAN BOOKS QUESTION SOLUTION(Collected Form Google)• A design should lead to
data structures, components, and interfaces that are appropriate for classes and in turn reduce the
complexity of connection with the externalenvironmen
4. What Is Modularity? List The Important Properties Of A Modular System
Modularity and its Properties
The module simply means the software components that are been created by dividing the software.
The software is divided into various components that work together to form a single functioning
item but sometimes they can perform as a complete function if not connected with each other. This
process of creating software modules is known as Modularity in software engineering.
It simply measures the degree to which these components are made up than can be combined. Some
of the projects or software designs are very complex that it’s not easy to understand its working and
functioning. In such cases, modularity is a key weapon that helps in reducing the complexity of
such software or projects.
The basic principle of Modularity is that “Systems should be built from cohesive, loosely coupled
components (modules)” which means s system should be made up of different components that are
united and work together in an efficient way and such components have a well-defined function. To
define a modular system, several properties or criteria are there under which we can evaluate a
design method while considering its abilities.
These criteria are defined by Meyer. Some of them are given below:
1. Modular Decomposability –
Decomposability simply means to break down something into smaller pieces. Modular
decomposability means to break down the problem into different sub-problems in a systematic
manner. Solving a large problem is difficult sometimes, so the decomposition helps in reducing
the complexity of the problem, and sub-problems created can be solved independently. This
helps in achieving the basic principle of modularity.

2. Modular Composability –
Composability simply means the ability to combine modules that are created. It’s actually the
principle of system design that deals with the way in which two or more components are related
or connected to each other. Modular composability means to assemble the modules into a new
system that means to connect the combine the components into a new system.
3. Modular Understandability –
Understandability simply means the capability of being understood, quality of comprehensible.
Modular understandability means to make it easier for the user to understand each module so
that it is very easy to develop software and change it as per requirement. Sometimes it’s not
easy to understand the process models because of its complexity and its large size in structure.
Using modularity understandability, it becomes easier to understand the problem in an efficient
way without any issue.
4. Modular Continuity –
Continuity simply means unbroken or consistent or uninterrupted connection for a long period
of time without any change or being stopped. Modular continuity means making changes to the
 system requirements that will cause changes in the modules individually without causing any
effect or change in the overall system or software.
5. Modular Protection –
Protection simply means to keep something safe from any harms, to protect against any
unpleasant means or damage. Modular protection means to keep safe the other modules from
the abnormal condition occurring in a particular module at run time. The abnormal condition
can be an error or failure also known as run-time errors. The side effects of these errors are
constrained within the module.

5. Discuss the objectives of modular software design. What are the effects
of module coupling and cohesion?
Modularity- subdivide the system
In the same way, modularity in design means to subdivide a system into smaller parts so that these
parts can be created independently and then use these parts in different systems to perform different
functions.

Coupling refers to the interdependencies between modules, while cohesion describes how related
the functions within a single module are. Low cohesion implies that a given module performs tasks
which are not very related to each other and hence can create problems as the module becomes
large.
6.What problems arise if two modules have high coupling?
Coupling means the interconnection of dissimilar modules with each other or we can say, it tells
about the interrelationship of dissimilar modules of a system. A system with high coupling means
there are strong interconnections among its modules. If two modules are concerned in high
coupling, it means their interdependence will be very high. Any changes applied to single module
will affect the functionality of the other module. Greater the degree of change, greater will be its
effect on the other. As the dependence is higher, such modify will affect modules in a negative
manner and in-turn, the maintainability of the project is decreased. This will further decrease the
reusability factor of individual modules and as lead to unsophisticated software. So, it is always
desirable to have inter-connection & interdependence among modules.

7. What problems are likely to arise if a module has low cohesion?

Cohesion often refers to how the elements of a module belong together. Related code should be
close to each other to make it highly cohesive.

Easy to maintain code usually has high cohesion. The elements within the module are directly
related to the functionality that module is meant to provide. By keeping high cohesion within our
code, we end up trying DRY code and reduce duplication of knowledge in our modules. We can
easily design, write, and test our code since the code for a module is all located together and works
together.
Low cohesion would mean that the code that makes up some functionality is spread out all over
your code-base. Not only is it hard to discover what code is related to your module, it is difficult to
jump between different modules and keep track of all the code in your head.

8Describe the various strategies of design. Which design strategy is most

popular and practical?

Top-Down Strategy
The top-down strategy uses the modular approach to develop the design of a system. It is called so
because it starts from the top or the highest-level module and moves towards the lowest level
modules.
In this technique, the highest-level module or main module for developing the software is
identified. The main module is divided into several smaller and simpler submodules or segments
based on the task performed by each module. Then, each submodule is further subdivided into
several submodules of next lower level. This process of dividing each module into several
submodules continues until the lowest level modules, which cannot be further subdivided, are not
identified.

Bottom-Up Strategy
Bottom-Up Strategy follows the modular approach to develop the design of the system. It is called
so because it starts from the bottom or the most basic level modules and moves towards the
highest level modules.
In this technique,

● The modules at the most basic or the lowest level are identified.

● These modules are then grouped together based on the function performed by each module
to form the next higher-level modules.

● Then, these modules are further combined to form the next higher-level modules.
 ● This process of grouping several simpler modules to form higher level modules continues
until the main module of system development process is achieved.

9. If some existing modules are to be re-used in building a new system,

which design strategy is used and why?

Bottom-up Design
The bottom up design model starts with most specific and basic components. It proceeds with
composing higher level of components by using basic or lower level components. It keeps
creating higher level components until the desired system is not evolved as one single component.
With each higher level, the amount of abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from some existing
system, where the basic primitives can be used in the newer system.
Both, top-down and bottom-up approaches are not practical individually. Instead, a good
combination of both is used.

10. What is the difference between a flow chart and a structure chart?
Difference between Structure chart and Flow chart :
Structure chart Flow chart

Structure chart represents the Flow chart represents the flow of

software architecture. control in program.

It is easy to identify the different It is difficult to identify the

modules of the software from different modules of the software
 Structure chart Flow chart

structure chart. from the flow chart.

Symbols used in structure chart are Symbols used in flow chart are
complex. simple.

Data interchange among

Data interchange between different different modules is not
modules is represented here. represented in flow chart.

In structure chart different types of Only a single type of arrow is

arrows are used to represent data flow used to show the control flow in
and module invocation. flow chart.

It suppresses the sequential ordering It demonstrates the sequential

of tasks inherent in a flow chart. ordering of inherent tasks.

Structure chart is complex to

construct in comparison of flow Flow chart is easier to construct
chart. in comparison of structure chart.

Structure chart is hard to understand. Flow chart is easy to understand.

11. Explain why it is important to use different notations to describe

software designs.
Many notations and languages exist to represent software design artifacts. Some are used mainly
to describe a design’s structural organization, others to represent software behavior. Certain
notations are used mostly during architectural design and others mainly during detailed design,
although some notations can be used in both steps. In addition, some notations are used mostly in
the context of specific. Here, they are categorized into notations for describing the structural
(static) view vs. the behavioral (dynamic) view.
12. List a few well-established function oriented software design
techniques.

Function Oriented Design Strategies are as follows:

1. Data Flow Diagram (DFD):
A data flow diagram (DFD) maps out the flow of information for any process or system. It uses
 defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between each destination.
2. Data Dictionaries:
Data dictionaries are simply repositories to store information about all data items defined in
DFDs. At the requirement stage, data dictionaries contains data items. Data dictionaries include
Name of the item, Aliases (Other names for items), Description / purpose, Related data items,
Range of values, Data structure definition / form.
3. Structure Charts:
It is the hierarchical representation of system which partitions the system into black boxes
(functionality is known to users but inner details are unknown). Components are read from top
to bottom and left to right. When a module calls another, it views the called module as black
box, passing required parameters and receiving results.
Pseudo Code:
Pseudo Code is system description in short English like phrases describing the function. It use
keyword and indentation. Pseudo codes are used as replacement for flow charts. It decreases
the amount of documentation required.

13.
Define the following terms: Objects, Message, Abstraction, Class,
Inheritance and Polymorphism.
i) Data abstraction: Abstraction refers to the act of representing essential
features without including the background details or explanation. Data
abstraction is the process of defining a data type, often called abstract
data type (ADT), together with the principle of data hiding.

(ii) Class: Class is a collection of objects of same data types. Class

contents data and functions that operate on data.

(iii) Dynamic binding: Linking of function call to function definition at

run time is defined as dynamic binding

(iv) Polymorphism: Polymorphism means ability to take more than one

form at different instances depending on the type or number of
arguments.
14. What is the relationship between abstract data types and classes?

According to Code Complete, ADT is a collection of data and operations that work on that data.

Example for ADT:

List

● Initialize list
 ● Insert item in list
● Remove item from list
● Read next item from list
ADT form the foundation for the concept of classes. In languages that support classes, you can
implement each abstract data type as its own class. Classes usually involve the additional concepts
of inheritance and polymorphism. One way of thinking of a class is as an abstract data type plus
inheritance and polymorphism.
n ADT defines operations for the given type and mathematically expresses their behaviour.
Concrete implementations of an ADT can differ from each other. In that way classes are
implementing the ADT and methods implement operations.

Classes have a slightly different terminology than ADTs and add other characteristics, like:

● they for example may live in packages

● their members are called attributes and methods
● attributes and methods have a certain visibility constraint
And methods:

● can be abstract, too. but then, their behaviour isn't defined - only their method signature - an
inheriting concrete class must provide an implementation
Don't confuse abstract data types with abstract classes in a concrete language

15. Can we have inheritance without polymorphism? Explain.

Yes we can. Just don't override any virtual functions and that's inheritance without polymorphism.

Kinda pointless though. If the point was to copy the functionality from one class into a derived
class, you can do that more reasonably by composition — that is, have the new class have an
instance of an object of the old class.

The point of inheritance isn't “it does the same thing but adds more,” but rather “the way you
interact with it is the same, but underneath it's something different.” it's a relationship of “is a” and
not a relationship of “has a.”

16. Discuss the differences between object oriented and function oriented
design.

The first difference that we would discuss is the fundamental concept of each programming
paradigm. In function oriented design, the function of the program is the most important. On the
other hand, object oriented program, the focus is on data and its manipulation rather than functions.
Objects in object oriented programming are independent entities that hold all state and
representation and is subject to quick change.
Another difference between programming paradigms is that function oriented programming adopts
iterative procedural decomposition which is a top-down strategy. A function oriented program is
treated as a hierarchy of increasing levels of details where first the high level description of the
program is understood and then in each step, a part of our high level description is refined. It
basically means that the program is elaborated, beginning from a highly conceptual model and then
proceeding to lower level details. This process is repeated until the statement level of the particular
programming language is achieved.

On the other hand, Object-oriented programming is more associated with real world “things”
which are translated to objects in object oriented programming. Every object has characteristics in
terms of their attributes and behaviour. These objects might be distributed and hence they either
execute sequentially or in parallel.

17. What documents should be produced on completion of the design

phase?

Construction documents are compiled from design development documents. They include all the
architectural drawings and specifications necessary to complete the project, and are the basis of the
bid documents and the construction contract. The estimated project costs are reviewed and updated
to reflect current construction costs, and are compared with the established project budget. If it is
no longer feasible to complete the project within the established budget, alternative approaches and
practical cost reductions are identified.

At the end of the Design Phase, the project is ready to be constructed and the construction budget is
ready for your approval. The deliverables of the Design Phase are the design documents,
construction documents and the preliminary contract document package. Once the construction
budget is approved, the Construction Phase begins
SOFTWARE METRICS
1. Define software metrics. Why do we really need metrics in software?

- A software metric is a measure of software characteristics which are measurable

or countable. Software metrics are valuable for many reasons, including
measuring software performance, planning work items, measuring productivity,
and many other uses.
- Within the software development process, many metrics are that are all
connected. Software metrics are similar to the four functions of management:
Planning, Organization, Control, or Improvement.
- Comparative study of various design methodology of software systems.
- For analysis, comparison, and critical study of different programming language
concerning their characteristics.
- In comparing and evaluating the capabilities and productivity of people involved
in software development.
- In the preparation of software quality specifications.
- In the verification of compliance of software systems requirements and
specifications.
- In making inference about the effort to be put in the design and development of
the software systems.
- In getting an idea about the complexity of the code.
- In taking decisions regarding further division of a complex module is to be done
or not.
- In guiding resource manager for their proper utilization.
- In comparison and making design tradeoffs between software development and
maintenance cost.
- In providing feedback to software managers about the progress and quality during
various phases of the software development life cycle.
- In the allocation of testing resources for testing the code.
-
2. Discus the areas of applications of software metrics? What are the problems during
implementation of metrics in any organizations?
Implementing and executing software metrics is a cumbersome task as it is difficult to manage the
technical and human aspects of the software measurement. Also, there exist many issues which
prevent the successful implementation and execution of software metrics. These issues are listed
below.

● Lack of management commitment: It is observed that management is not committed

towards using software metrics due to the following reasons
● § Management opposes measurement.
● § Software engineers do not measure and collect data as management does not realize
their importance.
● § Management charters a metrics program, but does not assist in deploying the program
into practice.

● Collecting data that is not used: Data collected during the measurement process should be
such that it can be used to enhance the process, project, or product. This is because collecting
incorrect data results in wrong decision making, which in turn leads to deviation from the
software development plan.
● Measuring too much and too soon: In a software project, sometimes excess data is
collected in advance, which is difficult to manage and analyze. This results in unsuccessful
implementation of the metrics.
● Measuring the wrong things: Establishing metrics is a time consuming process and only
those data that provide valuable feedback should be measured in an effective and efficient
manner. To know whether data needs to be measured, a few questions should be addressed
(if answers are no, then metrics should not be established).

§ Do data items collected relate to the key success strategies for business?
§ Are managers able to obtain the information they need to manage projects and
people on time?
§ Is it possible to conclude from data obtained that process changes are working?

● Imprecise metrics definitions: Vague or ambiguous metrics definition can be

misinterpreted. For example, some software engineers may interpret a software feature as
unnecessary while some software engineers may not.
● Measuring too little, too late: Measuring too less, provides information, which is of little or
no importance for the software engineers. Thus, software engineers tend to offer resistance
in establishing metrics. Similarly, if data is collected too late, the requested data item may
result in unnecessary delay in software project as project managers and software engineers
do not get the data they need on time.
● Misinterpreting metrics data: Interpretation of metrics data is important to improve the
quality of software. However, software metrics are often misinterpreted. For example, if the
number of defects in the software increases despite effort taken to improve the quality, then
software engineers might conclude that software improvement effort are doing more harm
than good.
● Lack of communication and training: Inadequate training and lack of communication
results in poor understanding of software metrics and measurement of unreliable data. In
 addition, communicating metrics data in an ineffective manner results in misinterpretation of
data.

In order to resolve or avoid these issues, the purpose for which data will be used should be clearly
specified before the measurement process begins. Also, project managers and software engineers
should be adequately trained and measured data should be properly communicated to them.
Software metrics should be defined precisely so that they work effectively.

3. What are the various categories of software metrics? Discuss with the help of
suitable example.

Software metrics is a standard of measure that contains many activities which involve some
degree of measurement. It can be classified into three categories: product metrics, process metrics,
and project metrics.

● Product metrics describe the characteristics of the product such as size, complexity,
design features, performance, and quality level.

● Process metrics can be used to improve software development and maintenance.

Examples include the effectiveness of defect removal during development, the pattern of
testing defect arrival, and the response time of the fix process.

● Project metrics describe the project characteristics and execution. Examples include the
number of software developers, the staffing pattern over the life cycle of the software,
cost, schedule, and productivity.
Some metrics belong to multiple categories. For example, the in-process quality metrics of a
project are both process metrics and project metrics.

Explain the Halstead theory of software science. Is it significant in today’s scenario of component
based software development?
According to Halstead's "A computer program is an implementation of an algorithm considered to
be a collection of tokens which can be classified as either operators or operand."
Token Count
In these metrics, a computer program is considered to be a collection of tokens, which may be
classified as either operators or operands. All software science metrics can be defined in terms of
these basic symbols. These symbols are called as a token.
The basic measures are
n1 = count of unique operators.
n2 = count of unique operands.
N1 = count of total occurrences of operators.
N2 = count of total occurrence of operands.
In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2.
Halstead metrics are:
Program Volume (V)
The unit of measurement of volume is the standard unit for size "bits." It is the actual size of a
program if a uniform binary encoding for the vocabulary is used.
V=N*log2n
Program Level (L)
The value of L ranges between zero and one, with L=1 representing a program written at the
highest possible level (i.e., with minimum size).
L=V*/V
Program Difficulty
The difficulty level or error-proneness (D) of the program is proportional to the number of the
unique operator in the program.
D= (n1/2) * (N2/n2)
Programming Effort (E)
The unit of measurement of E is elementary mental discriminations.
E=V/L=D*V
Estimated Program Length
According to Halstead, The first Hypothesis of software science is that the length of a well-
structured program is a function only of the number of unique operators and operands.
N=N1+N2
4. What is the significance of use case metrics? Is it really important to design such
metrics?
o Provides early during Market Requirement Development phase from object oriented
analysis perspective. Generally at this stage design(Class, functions, APIs, Data...) is not
available.
o 2. Though tors, uses case scenarios, required third party integration needs, environment etc.
are known.
o 3. Its simple and quick that can help the Product Owners to take decision of feature list
prioritization (High Business Value with least cost FIRST).
CHAPTER 7.
SOFTWARE RELIABILITY

1. What is software reliability? Does it exist?

- Software Reliability means Operational reliability. It is described as the ability

of a system or component to perform its required functions under static conditions
for a specific period.
- Software reliability is also defined as the probability that a software system
fulfills its assigned task in a given environment for a predefined number of input
cases, assuming that the hardware and the input are free of error.
- Software Reliability is an essential connect of software quality, composed with
functionality, usability, performance, serviceability, capability, installability,
maintainability, and documentation.
- Software Reliability is hard to achieve because the complexity of software turn to
be high. While any system with a high degree of complexity, containing software,
will be hard to reach a certain level of reliability, system developers tend to push
complexity into the software layer, with the speedy growth of system size and
ease of doing so by upgrading the software

2. What is software quality? Discuss software quality attributes.

Software quality is defined as a field of study and practice that describes the
desirable attributes of software products.
 - Functionality - It evaluates the feature set and capabilities of the program.
- Usability It is accessed by considering the factors such as human factor,
consistency and documentation.
- Reliability - It is evaluated by measuring parameters like frequency and
security of failure, output result accuracy, the mean-time-to-failure (MTTF),
recovery from failure and the the program predictability.
- Performance - It is measured by considering processing speed, response time,
resource consumption, throughput and efficiency.
- Supportability
It combines the ability to extend the program, adaptability, serviceability. These
three term define maintainability.
Testability, compatibility and configurability are the terms using which a
system can be easily installed and the problems can be found easily.
Supportability also consists of more attributes such as compatibility,
extensibility, fault tolerance, modularity, reusability, robustness, security,
portability, scalability.

3. Compare hardware reliability with software reliability.

Software reliability
Software Reliability is the probability of failure-free software operation for a
specified period of time in a specified environment. Software Reliability is
also an important factor affecting system reliability
Hardware reliability...
A statement of the ability of hardware to perform its functions for some period
of time. It is usually expressed as MTBF (mean time between failures). A
Dictionary of Computing. × "hardware reliability"...
4. What is software failure? How is it related with a fault?
Failure is the inability of software to perform its intended or required function
according to specifications.
A fault is a defect in a program, or a condition that causes software to fail to perform
its function. Hence the relationship is that a fault in a system leads to failure of the
system.
5. Discuss the various ways of characterizing failure occurrences with respect to
time
There are four general ways of characterizing a fault with respect to time
- Time of failure
- Time interval between failures
- Cumulative failures experienced upto a given time.
- Failures experienced in a time interval.