1. Explain the nature of software.

Ans:
 Today, software takes on a dual role.
 It is a product, and the vehicle for delivering a product.
 As a product, it delivers the computing potential embodied by
computer hardware or, more broadly, by a network of computers
that are accessible by local hardware.
 Whether it resides within a mobile device, on the desktop, in the
cloud, or within a mainframe computer or autonomous machine,
software is an information transformer—producing, managing,
acquiring, modifying, displaying, or transmitting information that
can be as simple as a single bit or as complex as an augmented
reality representation derived from data acquired from dozens of
independent sources and then overlaid on the real world.
 As the vehicle used to deliver a product, software acts as the basis
for the control of the computer (operating systems), the
communication of information (networks), and the creation and
control of other programs (software tools and environments).

Software delivers the most important product of our time—

information. It transforms personal data (e.g., an individual’s
financial transactions) so that the data can be more useful in a local
context;
1. Software manages business information to enhance
competitiveness;
2. Software provides a gateway to worldwide information networks
(e.g., the Internet).
3. Software provides the means for acquiring information in all of its
forms.

You also have to write below points for nature of software

i) Define software and characteristics – refer answer in your running

notes
ii) Software applications domains – refer answer in your running notes
iii) Legacy software – refer answer in your running notes

2. Explain software engineering layers.

Ans:
A Layered Technology
  It is a layered technology
 Any engineering approach(including software engineering) must
rest on an organizational commitment to Quality
 TQM, Six Sigma and similar philosophies foster a continuous
process improvement culture leads to the development of
increasingly more effective approaches to SE.
 The bedrock that supports software engineering is a Quality
Focus.
 The foundation for software engineering is the process
layer.
 Process defines a framework that must be established for
effective delivery of software engineering technology.
 The software process forms the basis for management
control of software projects and establishes the context in
which
 technical methods are applied,
 work products (models, documents, data, reports, forms,
etc.) are produced,
 milestones are established,
 quality is ensured, and
 Change is properly managed.
 Software engineering methods provide the technical how-
to’s for building software methods include a broad array of
tasks that include:
 Requirements Analysis
 Design
 Program Construction
 Testing
 Support
 SE tools provide automated or semi-automated support
for the process and the methods. When tools are
integrated so that the information created by one tool can be
used by another system for the support of software
development called CASE is established.

3. What is Software Process? Describe the five generic process

framework activities?
Ans:
A process is a collection of activities, actions, and tasks that are
performed when some work product is to be created.
 Activity - An activity strives to achieve a broad objective
Ex: communication with stakeholders
 Action - It encompasses a set of tasks that produce a major
work product
  Task - Focuses on a small, but well-defined objective that
produces a tangible outcome

“Process defines who is doing what, when and how to reach a certain
goal”.

 A process framework establishes the foundation for a complete

software engineering process by identifying a small number of
framework activities that are applicable to all software projects,
regardless of their size or complexity.
 In addition, the process framework encompasses a set of umbrella
activities that are applicable across the entire software process.

A generic process framework for software engineering encompasses five

activities:
i) Communication
 It involves heavy communication and collaboration with
customer
 Other stakeholders are businessman, end-users, software
engineers, support people.
 It includes requirements gathering and other related
activities.
ii) Planning
 Describes the technical task to be conducted
 The risks that are likely
 Resources that will be required
 Work products to be produced
 Work schedule
iii)Modeling
 It includes the creation of models that allow the
developer and customer to better understand software
requirements and the design that will achieve these
requirements.
 Modeling activity is composed of two software
engineering actions that is Analysis and Design.
 iv) Construction
 This activity combines code generation either manual
or automated.
 Testing that is required to uncover errors in the code.
v) Deployment
 Software as a complete entity or partially completed
increment is delivered to the customer who evaluates the
delivered product and provides feedback based on the evaluation

4. Explain Software Engineering umbrella activities?

Ans:
 Software engineering process framework activities are
complemented by a number of umbrella activities. In general,
umbrella activities are applied throughout a software project and
help a software team manage and control progress, quality,
change, and risk. Typical umbrella activities include:
i. Software project tracking and control—
Allows the software team to assess progress against the
project plan and take any necessary action to maintain the
schedule.
ii. Risk management—
Assesses risks that may affect the outcome of the project or the
quality of the product.
iii. Software quality assurance —
Defines and conducts the activities required to ensure software
quality.
iv. Technical reviews —
Assesses software engineering work products in an effort to
uncover and remove errors before they are propagated to the
next activity.
v. Measurement—
Defines and collects process, project, and product measures
that assist the team in delivering software that meets
stakeholders’ needs.
vi. Software configuration management—
Manages the effects of change throughout the software
process.
vii. Reusability management—
Defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable
components.
viii. Work product preparation and production—
Encompasses the activities required to create work products such
as models, documents, logs, forms, and lists.

5. How do process models differ from one another?

Ans:
Software process adaptation (the process of changing to suit
different conditions) is essential for project success. Therefore, a
process adopted for one project might be significantly different than a
process adopted for another project.
Among the differences are
 Overall flow of activities, actions, and tasks and the
interdependencies among them
 Degree to which actions and tasks are defined within each
framework activity
 Degree to which work products are identified and required.
 Manner in which quality assurance activities are applied
 Manner in which project tracking and control activities are applied
 Overall degree of detail and rigor with which the process is
described
 Degree to which the customer and other stakeholders are involved
with the project
 Level of autonomy given to the software team
 Degree to which team organization and roles are prescribed

6. Explain about Software Myths

Ans:
 Erroneous beliefs about software and the process that is used to
build it.
 It can be traced to the earliest days of computing.
Management myths.
Managers with software responsibility, like managers in most
disciplines, are often under pressure to
 Maintain budgets,
 keep schedules from slipping, and
 Improve quality.
 1. Myth: We already have a book that’s full of standards and
procedures for building software. Won’t that provide my
people with everything they need to know?
Reality:
 The book of standards may very well exist, but is it used?
 Are software practitioners aware of its existence?
 Does it reflect modern software engineering practice?
 Is it complete?
 Is it adaptable?
 Is it streamlined to improve time-to-delivery while still
maintaining a focus on quality?
 In many cases, the answer to all of these questions is “no.”

2. Myth: If we get behind schedule, we can add more

programmers and catch up
Reality:
Software development is not a mechanistic process like
manufacturing.
 “Adding people to a late software project makes it
later.”
 At first, this statement may seem counterintuitive. However, as
new people are added, people who were working must spend
time educating the newcomers, thereby reducing the
amount of time spent on productive development effort.
 People can be added but only in a planned and well-
coordinated manner.
3. Myth: If I decide to outsource the software project to a third
party, I can just relax and let that firm build it.
Reality:
 If an organization does not understand how to manage and
control software projects internally, it will invariably struggle
when it outsources software projects.

Customer myths.
 A customer who requests computer software may be a person at
the next desk, a technical group down the hall, the marketing/sales
department, or an outside company that has requested software
under contract.
 In many cases, the customer believes myths about software
because software managers and practitioners do little to correct
misinformation.
1. Myth: A general statement of objectives is sufficient to begin
writing programs—we can fill in the details later.
Reality:
 Although a comprehensive and stable statement of requirements is
not always possible
 Unambiguous(completely clear) requirements are developed only
through effective and continuous communication between customer
and developer.
 Myths lead to false expectations (by the customer) and,
ultimately, dissatisfaction with the developer.
2. Myth: Software requirements continually change, but change
can be easily accommodated because software is flexible.
 Reality:
 It is true that software requirements change, but the impact of
change varies with the time at which it is introduced.
 When requirements changes are requested early (before
design or code has been started), the cost impact is relatively
small.
 However, as time passes, the cost impact grows rapidly—
resources have been committed, a design framework has been
established, and change can cause disturbance that requires
additional resources and major design modification.

Practitioner’s myths.
1. Myth: Once we write the program and get it to work, our job is
done.
Reality:
 Someone once said that “the sooner you begin ‘writing code,’ the
longer it’ll take you to get done.” Industry data indicate that
between 60 and 80 percent of all effort expended on software will
be expended after it is delivered to the customer for the first time.
2. Myth: Until I get the program “running” I have no way of
assessing its quality.
Reality:
 One of the most effective software quality assurance mechanisms
can be applied from the inception of a project—the technical review.
 Software reviews are a “quality filter” that have been found to be
more effective than testing for finding certain classes of software
defects.

3. Myth: The only deliverable work product for a successful

project is the working program.
Reality:
 A working program is only one part of a software configuration
that includes many elements.
  A variety of work products (e.g., models, documents, plans)
provide a foundation for successful engineering and, more
important, guidance for software support.
4. Myth: Software engineering will make us create voluminous
(great size) and unnecessary (not needed) documentation and
will invariably (always) slows us down.
Reality:
 Software engineering is not about creating documents.
 It is about creating a quality product.
 Better quality leads to reduced rework.
 And reduced rework results in faster delivery times.