Unit 1- Introduction to

Software and Software

Subject : Software Engineering
Engineering Subject Code: 01IT0601
Semester: 6th

Asst. Prof. Kumar Parmar

Teaching Scheme
Topics
Introduction to Software and Software Engineering
Software engineering and its evolution, Software Process Models, The Linear
Sequential Model, The Prototyping Model, The RAD Model, Evolutionary Process
Models, Component-Based Development, Process, Product and Process.
Software Engineering
• Software Engineering is the application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software; that is, the application of
engineering to software.
• "Quantifiable methods" refer to techniques or practices that can be measured or
expressed using numbers, in order to ensure a high level of precision, accuracy, and
control in software engineering.
The Evolving Role Of Software
• Software takes on a dual role. It is a product and, at the same time, the vehicle for
delivering a product.
• As a product, it delivers the computing potential embodied by computer hardware or,
more broadly, a network of computers that are accessible by local hardware, 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 a
multimedia presentation.
• As the vehicle used to deliver the 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).
The Evolving Role Of Software
• Computer software has evolved greatly in 50 years due to advancements in hardware,
computing architecture, memory, storage and input/output options leading to more
sophisticated and complex systems. This can result in great success but also pose
challenges for those developing complex systems.
• The individual programmer of the past has been replaced by a team of software
specialists, each responsible for a specific aspect of creating complex computer
applications.
• Despite the team approach, the same questions that were asked of the individual
programmer still need to be addressed -
The Evolving Role Of Software
• Why does software take so long to complete?
• Why are development expenses so high?
• Why can't all errors be found before customer release?
• Why is it hard to track progress during software development?

These questions reflect the concern over software development and have led to the
implementation of software engineering practices.
Software Engineering: A Layered Technology
Software Engineering: A Layered Technology
• Software engineering is a layered technology with a focus on quality as its foundation.
• Total quality management leads to continuous process improvement, which supports the
software engineering process.
• The process layer is the foundation and glue that holds the technology layers together,
defining a framework for key process areas to ensure effective software delivery,
management control, and quality assurance.
• Software engineering methods provide technical guidance for building software, covering
tasks such as requirements analysis, design, programming, testing, and support. These
methods rely on basic principles and modeling activities.
Software Engineering: A Layered Technology
• Software engineering tools provide automated support for these methods, and when
integrated, form a system called computer-aided software engineering (CASE).
Software Process Models
• In industry, a software engineer or team must use a development strategy that includes the
process, methods, and tools layers, and generic phases, to solve real-world problems. This
strategy is known as a process model or software engineering paradigm.
Software Process Models
• Software development is a problem-solving loop that involves four stages:
• status quo, problem definition, technical development, and solution integration.
• Status quo represents the current state, problem definition identifies the problem, technical
development solves it through technology, and solution integration delivers the results to
the requester.
• The generic software engineering phases and steps fit into these stages.
The Linear Sequential Model
The Linear Sequential Model
• Sometimes called the classic life cycle or the waterfall model, the linear sequential
model suggests a systematic, sequential approach to software development.

• System/information engineering and modeling The software development

process starts with defining requirements for the entire system, including hardware,
people, databases, etc. and allocating some of these requirements to software.
• The process involves gathering requirements at system and business levels. System
engineering and analysis focus on system level while information engineering focuses
on business level.
The Linear Sequential Model
• Software requirements analysis. The requirements gathering process is intensified and
focused specifically on software. To understand the nature of the program(s) to be built,
the software engineer ("analyst") must understand the information domain for the
software. Requirements for both the system and the software are documented and
reviewed with the customer.
• Design. is actually a multistep process, focuses on four distinct attributes of a program:
data structure, software architecture, interface representations, and procedural
(algorithmic) detail. It translates requirements into a representation of the software that
can be assessed for quality before coding begins. Design is also documented.
The Linear Sequential Model
• Code generation. The design translated into a machine-readable form. If design is
performed in a detailed manner, code generation can be accomplished mechanistically.
• Testing. Program testing begins. Conducting tests to uncover errors and ensure that
defined input will produce actual results that agree with required results.
• Support. Software will undoubtedly undergo change after it is delivered to the
customer. Change will occur because errors have been encountered, because the
software must be adapted to accommodate changes in its external environment (e.g., a
change required because of a new operating system or peripheral device), or because the
customer requires functional or performance enhancements.
 The Linear Sequential Model
• the problems that are sometimes encountered when the linear sequential model is
applied are:
• Real projects rarely follow the sequential flow that the model proposes.
• It is often difficult for the customer to state all requirements explicitly.
• The customer must have patience. A working version of the program(s) will not be
available until late. A major blunder, if undetected until the working program is reviewed,
can be disastrous.
• Each of these problems is real. classic life cycle paradigm has important place in software
engineering work. It provides a template. The classic life cycle remains a widely used for software
engineering. While have weaknesses, it is significantly better than a haphazard approach to software
development.
The Prototyping Model
The Prototyping Model
• The prototyping paradigm begins with requirements gathering.
• Developer and customer meet and define the overall objectives for the software,
identify whatever requirements are known.
• A "quick design" then occurs. It focuses on a representation of those aspects of the
software that will be visible to the customer/user (e.g.,input approaches and output
formats).
• The quick design leads to the construction of a prototype. It is evaluated by the
customer/user and used to refine requirements for the software to be developed.
• Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at
the same time enabling the developer to better understand what needs to be done.
The Prototyping Model
• If a working prototype is built, the developer attempts to use existing program
fragments that enable working programs to be generated quickly.
• Users get a feel for the actual system and developers get to build something
immediately. Yet, prototyping can also be problematic for the following reasons:
1. A customer thinks a prototype software is working, but it's actually just held together
temporarily without consideration for quality or maintenance. When told it needs to be
rebuilt, the customer protests and demands only fixes.
2. A developer sacrifices proper implementation for a quick working prototype, using
available and familiar resources, even if they are inefficient.
The Prototyping Model
• Prototyping can be effective in software engineering with clear definition of goals from
the start, where the prototype is used to define requirements. After that, the actual software
is developed with focus on quality and maintainability, discarding parts of the prototype.
The RAD Model
The RAD Model
• Rapid Application Development (RAD) is a software development process with a short
development cycle, achieved by using components.
• It's a fast version of the linear sequential model. If requirements are clear and scope is
limited, it can result in a fully functional system in a short period of time (60-90 days). It
includes specific phases.
• Business modeling involves modeling the flow of information among business functions
to understand the source, generation, destination, and processing of information.
• Data modeling involves refining the information flow defined in business modeling into a
set of data objects with defined attributes and relationships between them to support the
business.
The RAD Model
• Process modeling involves transforming the data objects defined in data modeling to
achieve the necessary information flow for implementing business functions. It involves
creating processing descriptions for actions such as adding, modifying, deleting, or
retrieving data objects.
• Application generation aims to reuse existing program components or create reusable
ones, using automated tools to facilitate software construction.
• Testing and turnover. Since the RAD process emphasizes reuse, many of the program
components have already been tested. This reduces overall testing time. However, new
components must be tested.
The RAD Model
• If a business application can be modularized in a way that enables each major function to
be completed in less than three months (using the approach described previously), it is a
candidate for RAD.
• Each major function can be addressed by a separate RAD team and then integrated to
form a whole.
• Like all process models, the RAD approach has drawbacks
• requires sufficient human resources, committed developers and customers,
• require appropriate applications that can be modularized.
• It may not be suitable for systems with high technical risks, such as heavy use of new
technology or high interoperability requirements.
Evolutionary Process Models
• The linear sequential and prototyping models of software engineering are not suitable for
evolving software products, as they do not account for changes in business and product
requirements over time.
• An evolutionary model is needed, as it is iterative and enables the development of
increasingly complete versions of the software.
The Incremental Model
The Incremental Model
• The incremental model combines elements of the linear sequential model (applied
repetitively) with the iterative philosophy of prototyping. incremental model applies linear
sequences in a staggered fashion as calendar time progresses.
• Each linear sequence produces a deliverable “increment” of the software For example,
word-processing software developed using the incremental paradigm might deliver basic
file management, editing, and document production functions in the first increment; more
sophisticated capabilities in the second increment; and advanced page layout capability in
the fourth increment.
• It should be noted that the process flow for any increment can incorporate the prototyping
paradigm.
The Incremental Model
• When an incremental model is used, Basic requirements are addressed, but many
supplementary features remain undelivered.
• The core product is used by the customer (or undergoes detailed review).
• As a result of use and/or evaluation, a plan is developed for the next increment.
• The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality.
• This process is repeated following the delivery of each increment, until the complete
product is produced
The Incremental Model
• The incremental process model, like prototyping and other evolutionary approaches, is
iterative in nature.
• But unlike prototyping, the incremental model focuses on the delivery of an operational
product with each increment.
• Early increments are stripped down versions of the final product, but they do provide
capability that serves the user and also provide a platform for evaluation by the user.
• Incremental development is particularly useful when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project.
The Incremental Model
• If the core product is well received, then additional staff (if required) can be added to
implement the next increment. In addition, increments can be planned to manage technical
risks.
• For example, a major system might require the availability of new hardware that is under
development and whose delivery date is uncertain.
• It might be possible to plan early increments in a way that avoids the use of this hardware,
thereby enabling partial functionality to be delivered to end-users without inordinate
delay.
The Spiral Model

• A spiral model is divided into a number

of framework activities, also called task
regions. Typically, there are between
three and six task regions.
The Spiral Model
• The spiral model, originally proposed by Boehm (evolutionary model) that couples the
iterative nature of prototyping with the aspects of the linear sequential model.
• Using the spiral model, software is developed in a series of incremental releases.
• During early iterations, the incremental release might be a paper model or prototype.
During later iterations, increasingly more complete versions of the engineered system are
produced.
• A spiral model is divided into a number of framework activities, also called task regions.
Typically, there are between three and six task regions.
The Spiral Model
• Customer communication—tasks required to establish effective communication between
developer and customer.
• Planning—tasks required to define resources, timelines, and other project related
information.
• Risk analysis—tasks required to assess both technical and management risks.
• Engineering—tasks required to build one or more representations of the application.
• Construction and release—tasks required to construct, test, install, and provide user
support (e.g., documentation and training).
• Customer evaluation—tasks required to obtain customer feedback based on evaluation
of the software representations created during earlier stage.
The Spiral Model
• the spiral model is not a panacea (that cure all probs).
• It may be difficult to convince customers (particularly in contract situations) that the
evolutionary approach is controllable.
• It demands considerable risk assessment expertise and relies on this expertise for success.
If a major risk is not uncovered and managed, problems will undoubtedly occur.
• Finally, the model has not been used as widely as the linear sequential or prototyping
paradigms.
• It will take a number of years before effectiveness of this important paradigm can be
determined with absolute certainty.
The WINWIN Spiral Model (cx req)
COMPONENT-BASED DEVELOPMENT
COMPONENT-BASED DEVELOPMENT
• It incorporates many of the characteristics of the spiral model.
• It is evolutionary in nature, the component-based development model composes
applications from prepackaged software components (called classes).
• The component-based development model leads to software reuse, and reusability
provides software engineers with a number of measurable benefits.
PRODUCT AND PROCESS
• If the process is weak, the end product will undoubtedly suffer, but an obsessive
overreliance on process is also dangerous.
• People derive as much (or more) satisfaction from the creative process as they do from the
end product.
• A creative software professional should derive as much satisfaction from the process as
the end-product.
• The duality of product and process is one important element in keeping creative people
engaged as the transition from programming to software engineering is finalized.