1) Explain software engineering: a layered technology.

 Software Engineering : The application of a systematic, disciplined,

quantifiable approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.

Software engineering is a layered technology. Any engineering approach

(including software engineering) must rest on an organizational
commitment to quality. Total quality management, Six Sigma, and similar
philosophies foster a continuous process improvement culture, and it is
this culture that ultimately leads to the development of increasingly more
effective approaches to software engineering. The bedrock that supports
software engineering is a quality focus.

The foundation for software engineering is the process layer. The software
engineering process is the glue that holds the technology layers together
and enables rational and timely development of computer software.
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 encompass a broad array of tasks that include
communication, requirements analysis, design modelling , program
construction, testing, and support. Software engineering methods rely on a
set of basic principles that govern each area of the technology and include
modelling activities and other descriptive techniques.
Software engineering tools provide automated or semi-automated support
for the process and the methods. When tools are integrated so that
information created by one tool can be used by another, a system for the
support of software development, called computer-aided software
engineering, is established.
A process is a collection of activities, actions, and tasks that are performed
when some work product is to be created. An activity strives to achieve a
broad objective (e.g., communication with stakeholders) and is applied
 regardless of the application domain, size of the project, complexity of the
effort, or degree of rigor with which software engineering is to be applied.
An action (e.g., architectural design) encompasses a set of tasks that
produce a major work product (e.g., an architectural model). A task
focuses on a small, but well-defi ned objective (e.g., conducting a unit test)
that produces a tangible outcome.
In the context of software engineering, a process is not a rigid prescription
for how to build computer software. Rather, it is an adaptable approach
that enables the people doing the work (the software team) to pick and
choose the appropriate set of work actions and tasks. The intent is always
to deliver software in a timely manner and with sufficient quality to satisfy
those who have sponsored its creation and those who will use it.

2) What are customer's myths? Explain realities of each myth.

 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. Myths lead to false expectations (by the customer)
and, ultimately, dissatisfaction with the developer.

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, an ambiguous “statement of objectives” is a
recipe for disaster. Unambiguous requirements (usually derived
iteratively) are developed only through effective and continuous
communication between customer and developer.
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 upheaval that requires additional
resources and major design modification.

3) Explain any two software myth related to management myth with its reality.
  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. Like a
drowning person who grasps at a straw, a software manager often grasps
at belief in a software myth, if that belief will lessen the pressure (even
temporarily).

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.
Myth:
If we get behind schedule, we can add more programmers and
catch up (sometimes called the “Mongolian horde” concept).
Reality:
Software development is not a mechanistic process like manufacturing. In
the words of Brooks [Bro95]: “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.
Myth:
If I decide to outsource the software project to a third party, I can
just relax and let that fi rm 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.

4) What are the four P's of software project management? Explain it in detail.
 Effective software project management focuses on the four Ps: people,
product, process, and project. The order is not arbitrary. The manager who
forgets that software engineering work is an intensely human endeavour
will never have success in project management. A manager who fails to
encourage comprehensive stakeholder communication early in the
evolution of a product risks building an elegant solution for the wrong
problem. The manager who pays little attention to the process runs the risk
of inserting competent technical methods and tools into a vacuum. The
manager who embarks without a solid project plan jeopardizes the
success of the project.
1. The People
The cultivation of motivated, highly skilled software people has been
discussed since the 1960s. In fact, the “people factor” is so important
that the Software Engineering Institute has developed a People
Capability Maturity Model(People-CMM), in recognition of the fact that
“every organization needs to continually improve its ability to attract,
develop, motivate, organize, and retain the workforce needed to
accomplish its strategic business objectives”. The people capability
maturity model defi nes the following key practice areas for software
people: staffing, communication and coordination, work environment,
performance management, training, compensation, competency
analysis and development, career development, workgroup
development, and team/culture development, and others.
Organizations that achieve high levels of People-CMM maturity have a
higher likelihood of implementing effective software project
management practices. The People-CMM is a companion to the
Software Capability Maturity Model–Integration that guides
organizations in the creation of a mature software process.
2. The Product
Before a project can be planned, product objectives and scope
should be established, alternative solutions should be considered, and
technical and management constraints should be identified. Without
this information, it is impossible to define reasonable (and accurate)
estimates of the cost, an effective assessment of risk, a realistic
breakdown of project tasks, or a manageable project schedule that
provides a meaningful indication of progress.
As a software developer, you and other stakeholders must meet
to define product objectives and scope. In many cases, this activity
begins as part of the system engineering or business process
engineering and continues as the first step in software requirements
engineering. Objectives identify the overall goals for the product (from
the stakeholders’ points of view) without considering how these goals
will be achieved. Scope identifies the primary data, functions,
and behaviours that characterize the product, and more important,
attempts to bound these characteristics in a quantitative manner.
Once the product objectives and scope are understood,
alternative solutions are considered. Although very little detail is
discussed, the alternatives enable managers and practitioners to select
a “best” approach, given the constraints imposed by delivery deadlines,
budgetary restrictions, personnel availability, technical interfaces, and
myriad other factors.
3. The Process
A software process (Chapters 3–5) provides the framework from which
a comprehensive plan for software development can be established. A
 small number of framework activities are applicable to all software
projects, regardless of their size or complexity. A number of different
task sets—tasks, milestones, work products, and quality assurance
points—enable the framework activities to be adapted to the
characteristics of the software project and the requirements of the
project team. Finally, umbrella activities—such as software quality
assurance, software configuration management, and measurement—
overlay the process model. Umbrella activities are independent of any
one framework activity and occur throughout the process.
4. The Project
We conduct planned and controlled software projects for one
primary reason—it is the only known way to manage complexity. And
yet, software teams still struggle. In a study of 250 large software
projects between 1998 and 2004, Capers Jones found that “about 25
were deemed successful in that they achieved their schedule, cost, and
quality objectives. About 50 had delays or overruns below 35 percent,
while about 175 experienced major delays and overruns, or were
terminated without completion.” Although the success rate for present-
day software projects may have improved somewhat, our project failure
rate remains much higher than it should be.
To avoid project failure, a software project manager and the
software engineers who build the product must avoid a set of common
warning signs, understand the critical success factors that lead to good
project management, and develop a common sense approach for
planning, monitoring, and controlling the project. Each of these issues
is discussed in Section 31.5 and in the chapters that follow.

5) What do you mean by S/w process? explain common process framework

 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:

Communication:
Before any technical work can commence, it is critically important to
communicate and collaborate with the customer (and other stakeholders).
The intent is to understand stakeholders’ objectives for the project and to
gather requirements that help defi ne software features and functions.
Planning:
Any complicated journey can be simplified if a map exists. A software
project is a complicated journey, and the planning activity creates a “map”
that helps guide the team as it makes the journey. The map—called a
 software project plan—defines the software engineering work by
describing the technical tasks to be conducted, the risks that are likely, the
resources that will be required, the work products to be produced, and a
work schedule.
Modelling:
Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a
carpenter, or an architect, you work with models every day. You create a
“sketch” of the thing so that you’ll understand the big picture—what it will
look like architecturally, how the constituent parts fi t together, and many
other characteristics. If required, you refine the sketch into greater and
greater detail in an effort to better understand the problem and how you’re
going to solve it. A software engineer does the same thing by creating
models to better understand software requirements and the design that will
achieve those requirements.
Construction:
What you design must be built. This activity combines code generation
(either manual or automated) and the testing that is required to uncover
errors in the code.
Deployment:
The software (as a complete entity or as a partially completed
increment) is delivered to the customer who evaluates the delivered
product and provides feedback based on the evaluation. These five
generic framework activities can be used during the development of small,
simple programs, the creation of Web applications, and for the engineering
of large, complex computer-based systems. The details of the software
process will be quite different in each case, but the framework activities
remain the same.
For many software projects, framework activities are applied iteratively
as a project progresses. That is, communication, planning, modelling,
construction, and deployment are applied repeatedly through a number of
project iterations. Each iteration produces a software increment that
provides stakeholders with a subset of overall software features and
functionality. As each increment is produced, the software becomes more
and more complete.

6) Explain RAD model in detail with advantages & disadvantages.

 It is Rapid Application Development model. It is a type of incremental
model. In RAD model the components or functions are developed in
parallel as if they were mini projects. The developments are time boxed,
delivered and then assembled into a working prototype. This can quickly
give the customer something to see and use and to provide feedback
regarding the delivery and their requirements.
Diagram of RAD-Model:
The phases in the rapid application development (RAD) model are:
Business modelling: The information flow is identified between various
business functions.
Data modelling: Information gathered from business modelling is used to
define data objects that are needed for the business.
Process modelling: Data objects defined in data modelling are converted
to achieve the business information flow to achieve some specific
business objective. Description are identified and created for CRUD of
data objects.
Application generation: Automated tools are used to convert process
models into code and the actual system.
Testing and turnover: Test new components and all the interfaces.

Advantages of the RAD model:

 Reduced development time.
 Increases reusability of components
  Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.
Disadvantages of RAD model:
 Depends on strong team and individual performances for identifying
business requirements.
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost of modeling and automated
code generation is very high.

7) Explain Spiral model in detail with advantages & disadvantages.

 The spiral model, initially proposed by Boehm, is an evolutionary software
process model that couples the iterative feature of prototyping with the
controlled and systematic aspects of the linear sequential model. It
implements the potential for rapid development of new versions of the
software. Using the spiral model, the software is developed in a series of
incremental releases. During the early iterations, the additional release
may be a paper model or prototype. During later iterations, more and more
complete versions of the engineered system are produced.

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of
purpose for that cycle, the various alternatives that are possible for
achieving the targets, and the constraints that exists.
Risk Assessment and reduction: The next phase in the cycle is to
calculate these various alternatives based on the goals and constraints.
The focus of evaluation in this stage is located on the risk perception for
the project.
Development and validation: The next phase is to develop strategies
that resolve uncertainties and risks. This process may include activities
such as benchmarking, simulation, and prototyping.
Planning: Finally, the next step is planned. The project is reviewed, and a
choice made whether to continue with a further period of the spiral. If it is
determined to keep, plans are drawn up for the next step of the project.

The development phase depends on the remaining risks. For example, if

performance or user-interface risks are treated more essential than the
program development risks, the next phase may be an evolutionary
development that includes developing a more detailed prototype for
solving the risks. The risk-driven feature of the spiral model allows it to
accommodate any mixture of a specification-oriented, prototype-oriented,
simulation-oriented, or another type of approach. An essential element of
the model is that each period of the spiral is completed by a review that
 includes all the products developed during that cycle, including plans for
the next cycle. The spiral model works for development as well as
enhancement projects.

Advantages
 High amount of risk analysis
 Useful for large and mission-critical projects.
Disadvantages
 Can be a costly model to use.
 Risk analysis needed highly particular expertise

8) Explain W5HH principle in detail & also explain three generic team
organizations.
 Created by software engineer Barry Boehm, the purpose behind the
W5HH principle is to work through the objectives of a software project, the
project timeline, team member responsibilities, management styles, and
necessary resources. In an article he wrote on the topic, Boehm stated
that an organizing principle is needed that works for any size project. So
he developed W5HH as a guiding principle for software projects.
The W5HH principle may have a funny-sounding name, but it too is
designed for practicality. The W5HH principle outlines a series of
questions that can help project managers more efficiently manage
software projects. Each letter in W5HH stands for a question in the series
of questions to help a project manager lead. (Notice there is five ''W''
questions and two ''H'' questions).
9) What are practitioner's myths? Explain realities of each myth.
 Practitioner’s myths: Myths that are still believed by software
practitioners have been fostered by over 60 years of programming culture.
During the early days, programming was viewed as an art form. Old ways
and attitudes die hard.
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.
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 (described in Chapter 20) are a “quality filter” that have been
 found to be more effective than testing for finding certain classes of
software defects.
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.
Myth:
Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow 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.

10)Explain umbrella activities in detail.

 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:
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.
Risk management—assesses risks that may affect the outcome of the
project or the quality of the product.
Software quality assurance—defines and conducts the activities
required to ensure software quality.
Technical reviews—assess software engineering work products in an
effort to uncover and remove errors before they are propagated to the next
activity.
Measurement—defines and collects process, project, and product
measures that assist the team in delivering software that meets
stakeholders’ needs; can be used in conjunction with all other framework
and umbrella activities.
Software configuration management—manages the effects of change
throughout the software process.
Reusability management—defines criteria for work product reuse
(including software components) and establishes mechanisms to achieve
reusable components.
Work product preparation and production—encompass the activities
required to create work products such as models, documents, logs, forms,
and lists