Software Engineering

Module 1: Software Process and Agile Development – Chapters: 2,4,5

Introduction to Software Engineering

Software: Software is a set of instructions, data or programs used to operate computers and
execute specific tasks. Unlike hardware, which describes the physical aspects of a computer.
Software is a generic term used to refer to applications, scripts and programs that run on a
device. It can be thought of as the variable part of a computer, while hardware is the
invariable part.

Types of Software:

1. System software
a. OS
b. Language processor
c. Device drivers
2. Application software
a. General purpose application software
b. Customized application software
c. Utility application software

Software Engineering (SE): Software engineering encompasses a process, a collection of

methods (practice) and an array of tools that allow professionals to build high-quality software.
It is the systematic and disciplined approach to software development which includes the
process of designing, developing, testing, and maintaining software.

Aim & Purpose: to create high-quality, reliable and maintainable software.

Layers of SE: Quality Focus <--> Process <--> Method <--> Tools

Objectives:

1. Maintainability
2. Efficiency
3. Correctness
4. Reusability
5. Testability
6. Reliability
7. Portability
8. Adaptability

Page 1 of 13
 Key Principles of SE:

1. Modularity: Breaking the software into smaller, reusable components that can
be developed and tested independently.
2. Abstraction: Hiding the implementation details of a component and exposing
only the necessary functionality to other parts of the software.
3. Encapsulation: Wrapping up the data and functions of an object into a single
unit and protecting the internal state of an object from external modifications.
4. Reusability: Creating components that can be used in multiple projects, which
can save time and resources.
5. Maintenance: Regularly updating and improving the software to fix bugs, add
new features, and address security vulnerabilities.
6. Testing: Verifying that the software meets its requirements and is free of bugs.
7. Design Patterns: Solving recurring problems in software design by providing
templates for solving them.
8. Agile methodologies: Using iterative and incremental development processes
that focus on customer satisfaction, rapid delivery, and flexibility.
9. Continuous Integration & Deployment: Continuously integrating the code
changes and deploying them into the production environment.

Software Process: It is not a rigid prescription for how to build computer software. Rather, it
is an adaptable approach that enables software team to pick and choose the appropriate set of
work actions and tasks.

Process framework: it establishes the foundation for a complete software

engineering process. A generic process framework for software engineering
encompasses 5 activities:
1. Communication
2. Planning
3. Modelling
4. Construction
5. Deployment

General activities under the process framework:

1. Software project tracking and control

2. Risk management
3. Quality assurance
4. Technical review
5. Reusability management
6. Work product preparation & production

Process adaptation: Previously we discussed that the software engineering process is

not rigid that must be followed by a software team, and that it should be adaptable (to
the problem, to the project, to the team, Umbrella activities occur throughout the
software process and focus primarily on project management, tracking, and control.

Page 2 of 13
 Therefore, a process adopted for one project might be significantly different than a
process adopted for another project.

SE Practice:

The essence of practice:

1. Understand the problem (communication and analysis).

2. Plan a solution (modelling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

General principles: Amongst many principles that would be proposed there are 7
major principles (by David Hooker) that would focus on software engineering, while
others consider a specific generic framework activity (e.g., communication), and still
others focus on software engineering actions (e.g., architectural design) or technical
tasks (e.g., write a usage scenario).

1. First Principle – The reason it all exists

2. Second Principle – Keep it simple
3. Third Principle – Maintain the vision
4. Fourth Principle – What you produce, others will consume
5. Fifth Principle – Be open to the future
6. Sixth Principle – Plan ahead for reuse
7. Seventh Principle – Think

Software development myths: the wrongful beliefs about software and the process
that is used to build it. Myths have several attributes that make them treacherous. For
instance, they appear to be reasonable statements of fact, sometimes containing few
elements of truth but the whole belief would be falsified.
Types of myths:

1. Manager myths
2. Customer myths
3. Practitioner’s myths

Manager myths vs realities

Sl_No Myth Reality
Manuals will have simple Whereas standards that are scripted in
procedures, principles, and modules can be outdated, inadaptable,
standards that are required for and incomplete. Hence, developers
1 developers to enquire about every are not aware of every standard
piece of information as they are mentioned in the manual as it can
necessary for software reduce the delivery time and enhance
development. the quality
If we get behind schedule, we can However, adding more people to
2 add more programmers and catch delayed projects can increase the
up issues. Hence, developers who work

Page 3 of 13
 on projects must teach newcomers
and this may delay the project. Also,
the newcomers are much less
productive compared to the
developers. Therefore, they find it
difficult to meet the deadline due to
the extra time spent on newcomers.
If an organization does not understand
If I decide to outsource the
how to manage and control software
software project to a third party, I
3 projects internally, it will invariably
can just relax and let that fi rm
struggle when it outsources software
build it.
projects.

Customer myths vs realities

Sl_No Myth Reality
Unambiguous requirements (usually
A general statement of objectives
derived iteratively) are developed
is sufficient to begin writing
1 only through effective and continuous
programs, we can fill in the details
communication between customer and
later.
developer.
As software development progresses
over time, it becomes increasingly
challenging to accommodate changes.
Software requirements continually Making alterations at later stages of
change, but change can be easily development results in additional
2
accommodated because software costs due to the need for redesigning
is flexible. and requiring extra resources. The
longer the project goes on, the more
significant the impact of changes on
the overall process and budget.

Practitioner’s myths vs realities

Sl_No Myth Reality
A substantial portion, approximately
50-60%, of developers’ efforts, is
dedicated to post-delivery tasks once
Once we write the program and the software is provided to the
1
get it to work, our job is done. customer. During this phase,
developers encounter major missing
requirements, discover new bugs, and
encounter various challenges.
At any point during software
development, the quality of the
Until I get the program “running” software can be evaluated by applying
2 I have no way of assessing its a QA mechanism. Quality Assurance
quality. techniques allow developers to
measure the software’s performance
and identify potential issues, ensuring

Page 4 of 13
 that the final product meets the
desired standards
A working program is only one part of
a software configuration that includes
many elements. A variety of work
The only deliverable work
products (e.g., models, documents,
3 product for a successful project is
plans) provide a foundation for
the working program.
successful engineering and, more
important, guidance for software
support.
Software engineering is not about
Software engineering will make creating documents. It is about
us create voluminous and creating a quality product. Better
4
unnecessary documentation and quality leads to reduced rework. And
will invariably slow us down. reduced rework results in faster
delivery times.

Software Development Life Cycle (SDLC): Software development life cycle (SDLC) is a
structured process that is used to design, develop, and test good-quality software. SDLC, or
software development life cycle, is a methodology that defines the entire procedure of
software development step-by-step.

Page 5 of 13
 Process Models

A process model provides a specific roadmap for software engineering work. It defines the
flow of all activities, actions and tasks, the degree of iteration, the work products, and the
organization of the work that must be done.

Prescriptive process model: The name 'prescriptive' is given because the model prescribes
a set of activities, actions, tasks, quality assurance and change the mechanism for every
project. The different models are:

1. Waterfall model
2. Incremental process model
3. Evolutionary process model
a. Spiral model
b. Prototyping

Waterfall Model: In "The Waterfall" approach, the whole process of software development
is divided into separate phases. In this Waterfall model, typically, the outcome of one phase
acts as the input for the next phase sequentially.

situations where the use of Waterfall model is most appropriate are:

a. Requirements are very well documented, clear and fixed.

b. Product definition is stable.
c. Technology is understood and is not dynamic.
d. There are no ambiguous requirements.
e. Ample resources with required expertise are available to support the
product.
f. The project is short.

Page 6 of 13
 Advantages:

a. Simple and easy to understand and use

b. Easy to manage due to the rigidity of the model. Each phase has
specific deliverables and a review process.
c. Phases are processed and completed one at a time.
d. Works well for smaller projects where requirements are very well
understood.
e. Clearly defined stages.
f. Well understood milestones.
g. Easy to arrange tasks.
h. Process and results are well documented.

Disadvantages:
a. No working software is produced until late during the life cycle.
b. High amounts of risk and uncertainty.
c. Not a good model for complex and object-oriented projects.
d. Poor model for long and ongoing projects.
e. Not suitable for the projects where requirements are at a moderate to
high risk of changing. So, risk and uncertainty is high with this process
model.
f. It is difficult to measure progress within stages.
g. Cannot accommodate changing requirements.
h. Adjusting scope during the life cycle can end a project.

Incremental model: The incremental model involves dividing a complex project into smaller
modules known as increments. Each increment represents a partial system with added
functionality, allowing for the project's gradual development. The key feature of this model is
its iterative process, where increments are developed, tested, and integrated one after another
into the evolving system. This iterative approach facilitates frequent testing, quick feedback,
and early defect detection. By breaking the project into increments, teams can prioritize
features and address changes efficiently.

Page 7 of 13
 situations where the use of incremental model is most appropriate are:

1. When the requirements are superior.

2. A project has a lengthy development schedule.
3. When Software team are not very well skilled or trained.
4. When the customer demands a quick release of the product.
5. You can develop prioritized requirements first.

Advantages:
1. Errors are easy to be recognized.
2. Easier to test and debug
3. More flexible.
4. Simple to manage risk because it handled during its iteration.
5. The Client gets important functionality early.

Disadvantages:

1. Need for good planning

2. Total Cost is high.
3. Well defined module interfaces are needed.

Evolutionary process model: The evolutionary models are iterative. They are characterized
in a manner that enables you to develop increasingly more complete versions of the software.
Software, like all complex systems, evolves over a period. Business and product requirements
often change as development proceeds, making a straight-line path to a product unrealistic.
There are 2 common evolutionary models:

1. Prototyping: Prototyping is defined as the process of developing a working

replication of a product or system that must be engineered. This model is used
when the customers do not know the exact project requirements beforehand. A
prototype of the product is first developed, tested, and refined as per customer
feedback repeatedly till a final acceptable prototype is achieved which forms
the basis for developing the final product.

Page 8 of 13
situations where the use of incremental model is most appropriate are:

a. The Prototyping Model should be used when the requirements of the

product are not clearly understood or are unstable.
b. The prototyping model can also be used if requirements are changing
quickly.
c. This model can be successfully used for developing user interfaces,
high-technology software-intensive systems, and systems with
complex algorithms and interfaces.
d. The prototyping Model is also a very good choice to demonstrate the
technical feasibility of the product.

Advantages:

a. The customers get to see the partial product early in the life cycle.
b. New requirements can be easily accommodated as there is scope for
refinement.
c. Missing functionalities can be easily figured out.
d. Errors can be detected much earlier

Disadvantages:

a. Costly concerning time as well as money.

b. There may be too much variation in requirements each time the
prototype is evaluated by the customer.
c. Poor Documentation due to continuously changing customer
requirements.
d. It is very difficult for developers to accommodate all the changes
demanded by the customer.
e. There is uncertainty in determining the number of iterations needed to
finish the final prototype.

2. Spiral: Originally proposed by Barry Boehm [Boe88], the spiral model is an

evolutionary software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the waterfall model.
It provides the potential for rapid development of increasingly more complete
versions of the software.

Page 9 of 13
 Situations where the spiral model is most appropriate are:

i. When deliverance is required to be frequent.

ii. When the project is large
iii. When requirements are unclear and complex
iv. When changes may require at any time
v. Large and high budget projects

Advantages:

1. High amount of risk analysis

2. Useful for large and mission-critical projects.

Disadvantages:

1. Can be a costly model to use.

2. Risk analysis needed highly particular expertise
3. Doesn't work well for smaller projects.

Specialised process model: Specialized process models take on many of the characteristics of
one or more of the traditional models presented in the preceding sections. However, these
models tend to be applied when a specialized or narrowly defined software engineering
approach is chosen.

1. Component based development

2. Formal methods model

Component based development model: Component based development is a software system

development methodology where the system is developed using reusable software components.
Component based development aims at improved efficiency, performance and quality of the
system by recycling components. This model uses various characteristics of spiral model. In
CBD model, multiple classes can be used. These classes are basically the prepackaged
components. The model works in following manner:
 Step-1: First identify all the required candidate components, i.e., classes with the help of
application data and algorithms.

 Step-2: If these candidate components are used in previous software projects, then they must
be present in the library.

 Step-3: Such preexisting components can be excited from the library and used for further
development.

 Step-4: But if the required component is not present in the library, then build or create the
component as per requirement.

 Step-5: Place this newly created component in the library. This makes one iteration of the
system.

 Step-6: Repeat all the above steps for creating ‘n’ iterations, where n denotes the number of
iterations required to develop the complete application.

Page 10 of 13
Formal methods model: The formal methods model encompasses a set of activities that leads
to formal mathematical specification of computer software. Formal methods enable you to
specify, develop, and verify a computer-based system by applying a rigorous, mathematical
notation. A variation on this approach, called cleanroom software engineering. When formal
methods are used during design, they serve as a basis for program verification and therefore
enable you to discover and correct errors that might otherwise go undetected. Concerns about
its applicability in a business environment are:

a. The development of formal models is currently quite time consuming and

expensive.
b. Because few software developers have the necessary background to apply
formal methods, extensive training is required.
c. It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.

Agile Development

Agile software engineering combines a philosophy and a set of development guidelines. The
philosophy encourages customer satisfaction and early incremental delivery of software. The
development guide lines stress delivery over analysis and design and active and continuous
communication between developers and customers.

Agility: Agility in software development refers to a development team's capacity to

quickly respond to evolving requirements and consistently deliver top-notch products within
defined timelines.
Agile process: Any agile software process is characterized in a manner that addresses
several key assumptions about most software projects:

1. It is difficult to predict in advance which software requirements will per

sist and which will change. It is equally difficult to predict how customer
priorities will change as the project proceeds.
2. For many types of software, design and construction are interleaved. That
is, both activities should be performed in tandem so that design models are
proven as they are created. It is difficult to predict how much design is
necessary before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from a
planning point of view) as we might like.

Page 11 of 13
Agility principles: There are 12 principles that must be considered to achieve the
concept of agility towards the software or its product.

Agile software development process:

Page 12 of 13
Extreme Programming (XP): it’s one of the most important software development
frameworks of Agile models. It is used to improve software quality and responsiveness to
customer requirements. Extreme Programming uses an object-oriented approach as its
preferred development paradigm and encompasses a set of rules and practices that occur
within the context of four framework activities: planning, design, coding, and testing.

1. Planning: The first stage of Extreme Programming is planning. During

this phase, clients define their needs in concise descriptions known as user
stories. The team calculates the effort required for each story and
schedules releases according to priority and effort.
2. Design: The team creates only the essential design needed for current user
stories, using a common analogy or story to help everyone understand the
overall system architecture and keep the design straightforward and clear.
3. Coding: Extreme Programming (XP) promotes pair programming i.e. wo
developers work together at one workstation, enhancing code quality and
knowledge sharing. They write tests before coding to ensure functionality
from the start (TDD), and frequently integrate their code into a shared
repository with automated tests to catch issues early.
4. Testing: Extreme Programming (XP) gives more importance to testing that
consist of both unit tests and acceptance test. Unit tests, which are
automated, check if specific features work correctly. Acceptance tests,
conducted by customers, ensure that the overall system meets initial
requirements. This continuous testing ensures the software’s quality and
alignment with customer needs.

Page 13 of 13