UNIT I

INTRODUCTION TO SOFTWARE ENGINEERING

➢ The Evolving Role Of Software

➢ Software
➢ The Changing Nature Of Software
➢ Legacy Software

PROCESS MODELS:

➢ The Waterfall Model

➢ Incremental Process Models
➢ Evolutionary Process Models
➢ Specialized Process Models.
A Generic Process Framework:

A software process framework defines the basic structure for activities carried out during software development.
Pressman outlines five framework activities common to most software processes:
• Communication – Understanding stakeholder needs through discussions.
• Planning – Estimating resources, timelines, and tasks.
• Modeling – Creating models (analysis and design) to understand system behavior and structure.
• Construction – Coding and testing.
• Deployment – Delivering software for use and gathering feedback.
THE EVOLVING ROLE OF A SOFTWARE

What is Software Engineering?

The term software engineering is the product of two words, software, and engineering. The
software is a collection of integrated programs.
Software subsists of carefully-organized instructions and code written by developers on any
of various particular computer [Link] programs and related documentation such as
requirements, design models and user manuals.

Engineering is the application of scientific and practical knowledge to invent, design, build,
maintain, and improve frameworks, processes, etc.
Software Engineering is an engineering branch related to the evolution of software product

using well-defined scientific principles, techniques, and procedures. The result of software
engineering is an effective and reliable software product.

THE EVOLVING ROLE OF SOFTWARE

Today, 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.
Whether it resides within a cellular phone or operates inside a mainframe computer, 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). Software delivers the most
important product of our time—information.
Software transforms personal data (e.g., an individual’s financial transactions) so that the data
can be more useful in a local context; it manages business information to enhance
competitiveness; it provides a gateway to worldwide information networks (e.g., Internet) and
provides the means for acquiring information in all of its forms.
The role of computer software has undergone significant change over a time span of little more
than 50 years. Dramatic improvements in hardware performance, profound changes in
computing architectures, vast increases in memory and storage capacity, and a wide variety of
exotic input and output options have all precipitated more sophisticated and complex computer-
based systems. The lone programmer of an earlier era has been replaced by a team of software
specialists, each focusing on one part of the technology required to deliver a complex
application.

CHANGING NATURE OF SOFTWARE:

The nature of software has changed a lot over the years.

1. System software: Infrastructure software come under this category like compilers, operating
systems, editors, drivers, etc. Basically system software is a collection of programs to provide
service to other programs.

2. Real time software: These software are used to monitor, control and analyze real world
events as they occur. An example may be software required for weather forecasting. Such
software will gather and process the status of temperature, humidity and other environmental
parameters to forcast the weather.

3. Embedded software: This type of software is placed in “Read-Only- Memory (ROM)”of the
product and control the various functions of the product. The product could be an aircraft,
automobile, security system, signalling system, control unit of power plants, etc. he embedded
software handles hardware components and is also termed as intelligent software .

4. Business software : This is the largest application area. The software designed to process
business applications is called business software. Business software could be payroll, file
monitoring system, employee management, account management. It may also be a data
warehousing tool which helps us to take decisions based on available data. Management
information system, enterprise resource planning (ERP) and such other software are popular
examples of business software.
5. Personal computer software: The software used in personal computers are covered in this
category. Examples are word processors, computer graphics, multimedia and animating tools,
database management, computer games etc. This is a very upcoming area and many big
organisations are concentrating their effort here due to large customer base.

6. Artificial intelligence software: Artificial Intelligence software makes use of non numerical
algorithms to solve complex problems that are not amenable to computation or straight forward
analysis. Examples are expert systems, artificial neural network,signal processing software etc.

7. Web based software: The software related to web applications come under this category.
Examples are CGI, HTML, Java, Perl, DHTML etc.
LEGACY SOFTWARE:

Legacy software is software that has been around a long time and still fulfills a business need. It
is mission critical and tied to a particular version of an operating system or hardware model
(vendor lock-in) that has gone end-of-life. Generally the lifespan of the hardware is shorter than
that of the software.
PROCESS MODELS:

Software Processes is a coherent set of activities for specifying, designing, implementing and
testing software systems. A software process model is an abstract representation of a process that
presents a description of a process from some particular perspective. There are many different
software processes but all involve:
• Specification – defining what the system should do;
• Design and implementation – defining the organization of the system and
implementing the system;
• Validation – checking that it does what the customer wants;
• Evolution – changing the system in response to changing customer needs.

TYPES OF SOFTWARE PROCESS MODEL:

Software processes, methodologies and frameworks range from specific prescriptive steps
that can be used directly by an organization in day-to-day work, to flexible frameworks that an
organization uses to generate a custom set of steps tailored to the needs of a specific
project or group. In some cases a “sponsor” or “maintenance” organization distributes an
official set of documents that describe the process.
Software Process and Software Development Lifecycle Model
One of the basic notions of the software development process is SDLC models which stands for
Software Development Life Cycle models. There are many development life cycle models that
have been developed in order to achieve different required objectives. The models specify the
various stages of the process and the order in which they are carried out. The most used, popular
and important SDLC models are given below:
• Waterfall model
• V model
• Incremental model
• RAD model
• Agile model
• Iterative model
• Spiral model
• Prototype model

WATERFALL MODEL
The waterfall model is a breakdown of project activities into linear sequential phases, where each
phase depends on the deliverables of the previous one and corresponds to a specialisation of
tasks. The approach is typical for certain areas of engineering design.

V MODEL
The V-model represents a development process that may be considered an extension of the
waterfall model and is an example of the more general V-model. Instead of moving down in a
linear way, the process steps are bent upwards after the coding phase, to form the typical V
shape. The V-Model demonstrates the relationships between each phase of the development life
cycle and its associated phase of testing. The horizontal and vertical axes represent time or
project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction
uppermost), respectively.

INCREMENTAL MODEL
The incremental build model is a method of software development where the model is designed,
implemented and tested incrementally (a little more is added each time) until the product is
finished. It involves both development and maintenance. The product is defined as finished when
it satisfies all of its requirements. Each iteration passes through the requirements, design, coding
and testing phases. And each subsequent release of the system adds function to the previous
release until all designed functionally has been implemented. This model combines the elements
of the waterfall model with the iterative philosophy of prototyping.
ITERATIVE MODEL
An iterative life cycle model does not attempt to start with a full specification of requirements by
first focusing on an initial, simplified set user features, which then progressively gains more
complexity and a broader set of features until the targeted system is complete. When adopting
the iterative approach, the philosophy of incremental development will also often be used
liberally and interchangeably.
In other words, the iterative approach begins by specifying and implementing just part of the
software, which can then be reviewed and prioritized in order to identify further requirements.
This iterative process is then repeated by delivering a new version of the software for each
iteration. In a light-weight iterative project the code may represent the major source of
documentation of the system; however, in a critical iterative project a formal software
specification may also be required.
Iterative Model
RAD model
Rapid application development was a response to plan-driven waterfall processes, developed in
the 1970s and 1980s, such as the Structured Systems Analysis and Design Method (SSADM).
Rapid application development (RAD) is often referred as the adaptive software development.
RAD is an incremental prototyping approach to software development that end users can
produce better feedback when examining a live system, as opposed to working strictly with
documentation. It puts less emphasis on planning and more emphasis on an adaptive process.
RAD may resulted in a lower level of rejection when the application is placed into production,
but this success most often comes at the expense of a dramatic overruns in project costs and
schedule. RAD approach is especially well suited for developing software that is driven by
user interface requirements. Thus, some GUI builders are often called rapid application
development tools.

Evolutionary Process Models:

• Evolutionary models are iterative type models.

• They allow to develop more complete versions of the software.

The Following are the evolutionary process Model:

1. The prototype Model

2. The Spiral Model
3. Concurrent development model
1. THE PROTOTYPING MODEL
• Prototype is defined as first or preliminary form using which other forms are
copied or derived.
▪ Prototype model is a set of general objectives for software.
▪ It does not identify the requirements like detailed input, output.
▪ It is software working model of limited functionality.
▪ In this model, working programs are quickly produced.

The different phases of Prototyping model are:

1. Communication
In this phase, developer and customer meet and discuss the overall objectives of the
software.
2. Quick design
• Quick design is implemented when requirements are known.
• It includes only the important aspects like input and output format of the software.
• It focuses on those aspects which are visible to the user rather than the detailed plan.

• It helps to construct a prototype.

3. Modeling quick design
• This phase gives the clear idea about the development of software because the software
is now built.
• It allows the developer to better understand the exact requirements.
4. Construction of prototype
The customer themselves evaluates the prototype.

5. Deployment, delivery, feedback

• If the user is not satisfied with current prototype then it refines according to the
requirements of the user.
• The process of refining the prototype is repeated until all the requirements of users are met.
• When the users are satisfied with the developed prototype then the system is developed
on the basis of final prototype.
Advantages of Prototyping Model
• Prototype model need not know the detailed input, output, processes, adaptability of
operating system and full machine interaction.
• In the development process of this model users are actively involved.
• The development process is the best platform to understand the system by the user.
• Errors are detected much earlier.
• Gives quick user feedback for better solutions.
• It identifies the missing functionality easily. It also identifies the confusing or
difficult functions.
Disadvantages of Prototyping Model:
• The client involvement is more and it is not always considered by the developer.
• It is a slow process because it takes more time for development.
• Many changes can disturb the rhythm of the development team.
• It is a thrown away prototype when the users are confused with it.
2. THE SPIRAL MODEL

• Spiral model is a risk driven process model.

• It is used for generating the software projects.
• In spiral model, an alternate solution is provided if the risk is found in the risk
analysis, then alternate solutions are suggested and implemented.
• It is a combination of prototype and sequential model or waterfall model.
 • In one iteration all activities are done, for large project's the output is small.

The framework activities of the spiral model are as shown in the following figure.

Advantages of Spiral Model

▪ It reduces high amount of risk.
▪ It is good for large and critical projects.
▪ It gives strong approval and documentation control.
▪ In spiral model, the software is produced early in the life cycle process.
Disadvantages of Spiral Model
▪ It can be costly to develop a software model.
▪ It is not used for small projects.

3. THE CONCURRENT DEVELOPMENT MODEL

• The concurrent development model is called as concurrent model.

• The communication activity has completed in the first iteration and exits in the
awaiting changes state.
• The modeling activity completed its initial communication and then go to the
 underdevelopment state.
• If the customer specifies the change in the requirement, then the modeling activity moves
from the under development state into the awaiting change state.
• The concurrent process model activities moving from one state to another state.

Advantages of the concurrent development model

• This model is applicable to all types of software development processes.
• It is easy for understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current state of a project.
Disadvantages of the concurrent development model
▪ It needs better communication between the team members. This may not be
achieved all the time.
▪ It requires to remember the status of the different activities.
SPECIALIZED PROCESS MODELS
Special process models take many features from one or more conventional models. However
these special models tend to be applied when a narrowly defined software engineering approach
is chosen.
Types in Specialized process models:
1. Component based development (Promotes reusable components)
2. The formal methods model (Mathematical formal methods are backbone here)
3. Aspect oriented software development (Uses crosscutting technology)

COMPONENT BASED DEVELOPMENT

What is a Component?

A component is a modular, portable, replaceable, and reusable set of well-defined functionality

that encapsulates its implementation and exporting it as a higher-level interface.

A component is a software object, intended to interact with other components, encapsulating

certain functionality or a set of functionalities. It has an obviously defined

interface and conforms to a recommended behavior common to all components within an

architecture.

A software component can be defined as a unit of composition with a contractually specified

interface and explicit context dependencies only. That is, a software component can be
deployed independently and is subject to composition by third parties.

Views of a Component

A component can have three different views − object-oriented view, conventional view, and
process-related view.

Object-oriented view

A component is viewed as a set of one or more cooperating classes. Each problem domain class
(analysis) and infrastructure class (design) are explained to identify all attributes and operations
that apply to its implementation. It also involves defining the interfaces that enable classes to
communicate and cooperate.
Conventional view

It is viewed as a functional element or a module of a program that integrates the processing

logic, the internal data structures that are required to implement the processing logic and an
interface that enables the component to be invoked and data to be passed to it.

Process-related view

In this view, instead of creating each component from scratch, the system is building from
existing components maintained in a library. As the software architecture is formulated,
components are selected from the library and used to populate the architecture.

• A user interface (UI) component includes grids, buttons referred as controls, and utility
components expose a specific subset of functions used in other components.

• Other common types of components are those that are resource intensive, not frequently
accessed, and must be activated using the just-in-time (JIT) approach.

• Many components are invisible which are distributed in enterprise business applications
and internet web applications such as Enterprise JavaBean (EJB), .NET components,
and CORBA components.

Characteristics of Components

• Reusability − Components are usually designed to be reused in different situations in

different applications. However, some components may be designed for a specific task.

• Replaceable − Components may be freely substituted with other similar

components.

• Not context specific − Components are designed to operate in different

environments and contexts.

• Extensible − A component can be extended from existing components to provide

new behavior.

• Encapsulated − A A component depicts the interfaces, which allow the caller to use its
functionality, and do not expose details of the internal processes or any internal variables
or state.
 • Independent − Components are designed to have minimal dependencies on other
components.

FORMAL METHODS MODEL

The formal methods model is concerned with the application of a mathematical technique
to design and implement the software. This model lays the foundation for developing a
complex system and supporting the program development. The formal methods used
during the development process provide a mechanism for eliminating problems, which are
difficult to overcome using other software process models. The software engineer creates
formal specifications for this model. These methods minimize specification errors and this
result in fewer errors when the user begins using the system.

Table Advantages and Disadvantages of Formal Methods Model

Advantages Disadvantages

▪ Discovers ambiguity, incompleteness, ▪ Time consuming and expensive.

and inconsistency in the software. ▪ Difficult to use this model as a
▪ Offers defect-free software. communication mechanism for non
▪ Incrementally grows in effective technical personnel.
solution after each iteration. ▪ Extensive training is required since only
▪ This model does not involve high few developers have the essential
complexity rate. knowledge to implement this model.
▪ Formal specification language
semantics verify self-consistency.

ASPECT ORIENTED SOFTWARE DEVELOPMENT

Aspect-oriented software development (AOSD) is a software programming solution built
to address modularity deficiencies of traditional software development approaches such as
structural, procedural and object-oriented programming methods. It is an approach that is
designed to complement the conventional designs rather than replace them.
Features Of Aspect-Oriented Software Development
▪ AOSD focuses on core areas of identification and investigation, specification, and
representation of concerns that can present crosscutting concerns
▪ AOSD gives complementary benefits and can be used along with other coding
standards.
▪ AOSD ensures better modularization mechanisms of program designs, thereby reducing
software design, maintenance and development costs.
▪ AOSD is a better way to handle the localization of concerns that are cross-cutting
because concerns are compressed into various modules.
▪ AOSD makes available software coding methods and tools to support modularization at
▪ the source code stage.
▪ AOSD ensures improved and smaller size of code as a result of addressing the cross-
cutting issues
➢ AOSD encourages the reuse of code created by the modularization technique
AGILE METHODOLOGY:
Agile development is a flexible, iterative approach to software development that emphasizes
collaboration, customer feedback, and rapid delivery.
It's characterized by short development cycles (sprints) where teams deliver working software
in incremental steps, allowing for adjustments based on feedback.
Agile development contrasts with traditional, waterfall methods by prioritizing adaptability and
continuous improvement over rigid, upfront planning.
Key Features of Agile:

• Iterative and incremental delivery

• Continuous feedback and improvement
• Regular integration and testing
• Active involvement of all stakeholders

START Phase
Initiate Project: Project kickoff—goals, team, budget, and scope are defined.
Define Requirements: Initial set of user stories or features are gathered.
2. Development Cycles (Add Functionality)
Iterative Cycles: The core of Agile—each iteration focuses on adding specific, working
functionality.
Integrate & Test: After each small addition, code is integrated and tested immediately to catch
bugs early.
3. Review & Feedback
Review: A sprint review or demo is conducted at the end of the cycle.
Feedback: Stakeholders (clients, users, testers) provide input, guiding the next changes.
4. Approval Check
Approve?
If Yes: The feature or product is released to the market.
If No: Continue to next steps for improvement.
5. Improve & Iterate
Record & Incorporate Changes: Feedback is documented and translated into actionable items.
Adjust & Track: Developers adjust the backlog, prioritize features, and track progress.
Next Iteration: A new cycle begins with the updated set of features and improvements.
Continuous Visibility
Clients, Developers, Users are involved throughout the process.
Ensures transparency, communication, and shared ownership.
Release to Market
When the product is approved, it is released to users, often as a minimum viable product
(MVP) or in continuous delivery mode.
Why This Agile Model Works Well:
Customer-focused: Feedback-driven development.
Risk-managed: Frequent testing and iteration reduce late surprises.
Flexible: Can adapt quickly to changes in user needs or market demands.
PROCESS ASSESSMENT:
Process assessment determines the maturity and capability of software processes within an
organization.
It helps in continuous improvement by identifying strengths and weaknesses.
Common Models:
CMMI (Capability Maturity Model Integration):
Levels from 1 (Initial) to 5 (Optimizing)
Emphasizes process standardization and improvement
SPICE (ISO/IEC 15504):
International standard for software process assessment
Uses a capability dimension (0–5) for evaluating process performance
ISO 9001:2000:
General quality management standard applicable to software
Focuses on documented procedures and customer satisfaction
Level 1: Initial
At this level, the organization lacks formal processes. The work gets done, but in an ad-hoc or
chaotic manner, depending heavily on individual effort rather than a structured method.
There are no standard guidelines or documentation. Everyone may follow their own method,
leading to errors and inefficiencies.
Level 2: Managed

At this level, each project has its own process, which is planned, documented, monitored, and
controlled. While these processes may differ from project to project, project management
practices are in place.
Processes are project-specific
Each project may use different processes, not standardized across the organization. There's no
uniform process for all projects.
Planned
Every project has a defined plan, including schedules, budgets, and resources.
Tracked
Progress is monitored and controlled against the plan. Deviations are identified and managed.
Still lacks organization-wide consistency.
Level 3
At this level, the organization has standardized its processes across all projects, and those
processes are well-documented, understood, and consistently followed.
Well-documented
Processes are clearly written down in process manuals, guidelines, and templates. Everyone
knows what to do and how to do it.
Standardized
A common set of processes is followed across all projects in the organization. They are not just
project-specific.
Consistent
Processes are followed in the same way, regardless of who is doing the work or which team is
involved, leading to predictable outcomes.
Level 4
Level 4, the organization measures and controls its processes using quantitative data.
Processes are not just defined—they are also predictable and measurable.
Measurable
Detailed metrics and performance data (e.g., defect rates, productivity, cost) are collected for
all key processes.
Predictable
The performance of processes can be predicted using statistical and quantitative techniques.
Data-driven decisions
Management decisions are based on quantitative analysis rather than intuition.
Performance baselines
The organization establishes performance baselines for processes, allowing them to compare
expected vs. actual performance.
In a software company at Level 4:
The number of defects per 1000 lines of code is tracked.
Teams know, based on historical data, how long a task will likely take and how many errors
might occur.
If a defect rate goes beyond the acceptable limit, the team is alerted automatically.
Management uses control charts and statistical tools to identify performance trends.
Level 5:
At Level 5, the focus shifts to continuous process improvement. The organization uses
quantitative feedback from Level 4 and innovative ideas to optimize and enhance its processes
continuously.
Continuous improvement
Processes are not just followed—they are regularly evaluated and improved.
Innovation-focused
New tools, techniques, and ideas are encouraged and tested to improve quality and efficiency.
Root cause analysis
Problems are not just fixed—they are analyzed deeply to prevent future occurrences.
Organizational learning
Lessons from past projects are captured and used to refine organizational processes.
A Level 5 software company might:
Use AI tools to identify areas for productivity gains.
Regularly conduct root cause analysis on defects to eliminate systemic issues.
Experiment with new methodologies (e.g., DevOps or Agile variants) and adopt them if
beneficial.
Continuously update and refine processes based on metrics, feedback, and evolving needs.