Software Engineering

BY
Prof. Shraddha Rokade
Introduction to Software Engineering
What is Software ?
Software is:
(1) instructions (computer programs) that when executed provide desired
features, function, and performance;
(2) data structures that enable the programs to adequately manipulate
information, and
(3) descriptive information in both hard copy and virtual forms that describes
the operation and use of the programs.
What is Software Engineering?
Software Engineering:
(1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.
(2) The study of approaches as in (1)
Software Engineering
1. System software
2. Application software
3. Engineering/scientific software
4. Embedded software
5. Product-line software
6. Web applications
7. Artificial intelligence software etc…..
Software Myths: The types of software-related myths are
(i) Management Myths:
Myth 1:
We have all the standards and procedures available for software development.
Fact:
● Software experts do not know all the requirements for the software development.
● And all existing processes are incomplete as new software development is based on new and different problem.

Myth 2:
The addition of the latest hardware programs will improve the software development.
Fact:
● The role of the latest hardware is not very high on standard software development; instead (CASE) Engineering
tools help the computer, they are more important than hardware to produce quality and productivity.
● Hence, the hardware resources are misused.
Myth 3:
● With the addition of more people and program planners to Software development can help meet project
deadlines (If lagging behind).

Fact:

● If software is late, adding more people will merely make the problem worse. This is because the people
already working on the project now need to spend time educating the newcomers, and are thus taken away
from their work. The newcomers are also far less productive than the existing software engineers, and so
the work put into training them to work on the software does not immediately meet with an appropriate
reduction in work.

(ii)Customer Myths:
The customer can be the direct users of the software, the technical team, marketing / sales department, or other
company. Customer has myths leading to false expectations (customer) & that’s why you create dissatisfaction with
the developer.
Myth 1:
A general statement of intent is enough to start writing plans (software development) and details of objectives can be done over time.
Fact:
● Official and detailed description of the database function, ethical performance, communication, structural issues and the
verification process are important.
● Unambiguous requirements (usually derived iteratively) are developed only through effective and continuous
communication between customer and developer.

Myth 2:

Software requirements continually change, but change can be easily accommodated because software is flexible
Fact:
● 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.
(iii)Practitioner’s Myths:
Myths 1:
They believe that their work has been completed with the writing of the plan.
Fact:
● It is true that every 60-80% effort goes into the maintenance phase (as of the latter
software release). Efforts are required, where the product is available first delivered to
customers.

Myths 2:
There is no other way to achieve system quality, until it is “running”.
Fact:
● Systematic review of project technology is the quality of effective software verification
method. These updates are quality filters and more accessible than test.
Myth 3:
An operating system is the only product that can be successfully exported project.
Fact:
● A working system is not enough, the right document brochures and booklets are also
required to provide guidance & software support.

Myth 4:
Engineering software will enable us to build powerful and unnecessary document & always
delay us.
Fact:
● 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
A Generic view of process:
Software engineering- a layered technology

a generic process framework for software engineering defines five framework

activities—communication, planning, modeling, construction, and
deployment.
In addition, a set of umbrella activities—project tracking and control, risk
management, quality assurance, configuration management, technical
reviews, and others—are applied throughout the process.
Software engineering- a layered technology
Process Patterns
Patterns can be defined at any level of abstraction. In some cases, a pattern
might be used to describe a problem (and solution) associated with a
complete process model (e.g., prototyping). In other situations, patterns can
be used to describe a problem (and solution) associated with a framework
activity (e.g., planning) or an action within a framework activity (e.g., project
estimating).
Ambler [Amb98] has proposed a template for describing a process pattern:
Pattern Name. The pattern is given a meaningful name describing it within
the context of the software process (e.g., Technical Reviews).
Forces. The environment in which the pattern is encountered and the issues
that make the problem visible and may affect its solution.
Type. The pattern type is specified. Ambler [Amb98] suggests three types:

1. Stage pattern—defines a problem associated with a framework activity for the

process. Since a framework activity encompasses multiple actions and work tasks, a
stage pattern incorporates multiple task patterns (see the following) that are relevant
to the stage (framework activity). An example of a stage pattern might be Establishing
Communication. This pattern would incorporate the task pattern Requirements
Gathering and others.

2. Task pattern—defines a problem associated with a software engineering action or

work task and relevant to successful software engineering practice (e.g.,
Requirements Gathering is a task pattern).

3. Phase pattern—define the sequence of framework activities that occurs within the
process, even when the overall flow of activities is iterative in nature. An example of
a phase pattern might be Spiral Model or Prototyping.3
Initial context. Describes the conditions under which the pattern applies.
Prior to the initiation of the pattern:
(1) What organizational or team-related activities have already occurred?
(2) What is the entry state for the process?
(3) What software engineering information or project information already
exists?
Process assessment
The existence of a software process is no guarantee that software will be delivered on
time, that it will meet the customer’s needs, or that it will exhibit the technical
characteristics that will lead to long-term quality characteristics.

In addition, the process itself can be assessed to ensure that it meets a set of basic
process criteria that have been shown to be essential for a successful software
engineering.

A number of different approaches to software process assessment and improvement have

been proposed over the past few decades:

Standard CMMI Assessment Method for Process Improvement

(SCAMPI)—provides a five-step process assessment model that incorporates five

phases: initiating, diagnosing, establishing, acting, and learning.
SDLC
Process models:
The Waterfall Model\The Linear Sequential Model
Incremental Process Models
Evolutionary Process Models: Prototyping
Evolutionary Process Models: The Spiral Model
THE RAD MODEL
Rapid application
development model
The unified process
In some ways the Unified Process is an attempt to draw on the best features and
characteristics of traditional software process models, but characterize them in a
way that implements many of the best principles of agile software
development.The Unified Process recognizes the importance of customer
communication and streamlined methods for describing the customer’s view of a
system (the use case). It emphasizes the important role of software architecture
and “helps the architect focus on the right goals, such as understandability,
reliance to future changes, and reuse. It suggests a process flow that is iterative
and incremental, providing the evolutionary feel that is essential in modern
software development
Agile Model