SPM

Chapter 1: Software & Software Engineering

1. The Nature of Software

Software serves a dual purpose — it is both a product and a vehicle for delivering a product.

As a Product: It provides computing potential across networks, enabling functionalities ranging from basic
data processing to complex multimedia communication. Examples include web browsers or mobile apps.

As a Vehicle for Delivery: It supports control and communication between computer systems — such as
operating systems and network management tools.

Key Components of Software

Software is made up of:

1. Instructions – Programs that define features, functions, and performance.

2. Data Structures – Enable effective information manipulation.

3. Documentation – Explains the operation and usage of programs.

Software is engineered, not manufactured, and though the industry is shifting toward reusable components,
most software remains custom-built.

2. Wear vs. Deterioration

Unlike hardware, software does not wear out — it deteriorates over time due to continuous change.

Idealized Failure Curve: Initially high failure rate due to defects, which decreases as errors are corrected.

Actual Curve: Frequent changes introduce new errors, causing periodic spikes in failure rate. Over time, this
leads to deterioration.

Unlike hardware, software cannot be “replaced” — it must be maintained and updated carefully.

3. Software Application Domains

Software exists across various domains:

1. System Software: Supports other software (e.g., OS, compilers).

2. Application Software: Solves business needs in real-time.

3. Engineering/Scientific Software: Performs mathematical computations.

4. Embedded Software: Controls hardware functions (e.g., in vehicles).

5. Product-Line Software: Reusable, general-purpose products like spreadsheets.

6. Web/Mobile Applications: Browser- and mobile-based apps.

7. AI Software: Solves complex problems using intelligent algorithms.

4. Emerging Software Categories

Modern advancements have led to new software trends such as:

Open world and ubiquitous computing

Netsourcing (Web as a computation engine)

Open-source development

Data mining and grid computing

SPM 1
 Cognitive machines and nanotechnology software

5. Legacy Software
Legacy software refers to old, continuously modified systems that remain vital to business operations.

Challenges:
High maintenance costs

Risky to evolve

Difficult to replace

Reasons for Change:

Adaptation to new technologies

Implementation of new business needs

Integration with modern systems

Re-architecting for network viability

6. The Changing Nature of Software

a. Web Applications (WebApps)
Unique characteristics include:

Network intensiveness

High concurrency

Unpredictable load

Performance and availability demands

Security risks and aesthetic requirements

Continuous evolution and immediacy

b. Mobile Applications
Mobile apps run on mobile platforms (Android, iOS, etc.), integrating:

Local device features (e.g., GPS, storage)

Connectivity to web resources

Intuitive user interfaces

(The line between mobile apps and web apps is gradually disappearing.)

c. Cloud Computing
A shared ecosystem that provides:

Front-End: Devices and application interfaces

Back-End: Servers, infrastructure, and data storage

Supports models like public, private, and hybrid clouds

d. Product-Line Software
A family of related systems developed using shared components, architecture, and design patterns, serving
specific markets.

SPM 2
 7. Software Engineering Overview
Developing software requires:

Understanding the problem

Careful design and planning

Emphasis on quality

Maintenance and adaptability

IEEE Definition:

“Software engineering is the application of systematic, disciplined, and quantifiable approaches to the
development, operation, and maintenance of software.”

8. A Layered Technology
Software engineering operates as a layered framework:

1. Quality Focus: Ensures continuous improvement and reliability.

2. Process Layer: Provides the structure for effective software delivery.

3. Methods: Define technical “how-to” steps such as analysis, design, coding, and testing.

4. Tools: Offer automated or semi-automated support for methods and processes.

9. The Software Process

A process is a collection of activities, actions, and tasks to produce a work product.

Hierarchy:
Activity: Broad goal (e.g., communication with stakeholders)

Action: Produces a major work product (e.g., architectural design)

Task: Focused step with a specific outcome (e.g., unit testing)

10. Generic Process Framework Activities

1. Communication: Collaborate with customers and gather requirements.

2. Planning: Create a detailed project plan with resources, schedule, and risks.

3. Modeling: Build models to understand and design the solution.

4. Construction: Develop and test the software.

5. Deployment: Deliver, evaluate, and gather feedback from users.

11. Umbrella Activities

These are ongoing activities applied across all phases:

Project tracking and control

Risk management

Software quality assurance

Technical reviews

Measurement and evaluation

Configuration management

SPM 3
 Reusability management

Documentation and reporting

12. Process Adaptation

The software process must be flexible and adaptable to project needs, team size, and stakeholder involvement. It
should balance agility with structure.

13. Software Engineering Practice

Essence of Practice (Polya’s Four Steps):
1. Understand the Problem – Identify stakeholders, unknowns, and subproblems.

2. Plan the Solution – Reuse prior knowledge and define subproblems.

3. Carry Out the Plan – Follow the design, build correctly, and review code.

4. Examine the Result – Test thoroughly and validate against requirements.

14. Hooker’s Seven General Principles

1. The Reason It All Exists: Provide value to users.

2. KISS (Keep It Simple, Stupid): Strive for simplicity through refinement.

3. Maintain the Vision: Keep a clear, unified direction.

4. What You Produce, Others Will Consume: Design for readability and maintenance.

5. Be Open to the Future: Build systems easy to extend and adapt.

6. Plan Ahead for Reuse: Encourage reusability to save time and cost.

7. Think!: Prioritize thoughtful planning over hasty coding.

Chapter 2: Process Models

A Generic Process Model
A process is a collection of work activities, actions, and tasks that are performed to create a specific work
product. To organize these elements, a process framework is used, which defines how the different parts of the
process relate to each other.

The generic process framework for software engineering consists of five main framework activities supported by
several umbrella activities.

Framework Activities:

Each framework activity is made up of a set of software engineering actions.

Software Engineering Actions:

Each action is defined by a task set, which specifies:

The work tasks to be completed.

The work products that will be produced.

The quality assurance points required.

The project milestones that indicate progress.

Process Flow
Process flow defines how activities, actions, and tasks are organized in terms of sequence and time. There are
several types of process flows:

SPM 4
 1. Linear Process Flow: Activities such as communication, planning, modeling, construction, and deployment
are executed one after another in a strict order.

2. Iterative Process Flow: Some activities are repeated before moving to the next one.

3. Evolutionary Process Flow: Activities are executed in a circular manner, and each cycle produces a more
complete version of the software.

4. Parallel Process Flow: Some activities are carried out at the same time as others.

Prescriptive Process Models

A prescriptive process model gives a structured and ordered approach to software development. It prescribes
specific elements and workflows with clear rules for performing activities sequentially and tracking progress.

Common examples include the Waterfall Model, V-Model, Incremental Model, Evolutionary Models (like
Prototyping and Spiral), and Concurrent Model.

1. The Waterfall Model

The Waterfall Model is also known as the classic life cycle model. It follows a strict sequence where work flows
from communication and planning to modeling, construction, and deployment. It is best for projects where
requirements are clearly defined from the start.

Problems with the Waterfall Model:

It does not reflect real project situations since real projects rarely follow a strict sequence.

Customers may not know all requirements in advance and have to wait long before seeing results.

The linear approach can create blocking states where one team waits for another to finish.

It is not flexible enough to handle frequent changes in requirements.

2. The V-Model
The V-Model is a variation of the Waterfall Model that focuses on verification and validation.

Left Side of the V: Problem requirements are refined into detailed design and specifications.

Right Side of the V: After coding, tests such as unit, integration, and system testing are performed to validate
earlier design stages.

3. The Incremental Model

This model combines linear and parallel development approaches to produce software in increments. It is suitable
when basic requirements are known and a quick initial version is needed.

The first increment is a core product with basic functionality. Users evaluate it, and based on feedback, the next
increment is planned with improvements and added features.

For example:

1. Basic file management and editing.

2. Advanced editing and document formatting.

3. Spell checking and grammar correction.

4. Advanced page layout and styling.

4. Evolutionary Models
Evolutionary models are iterative and designed for systems that grow and change over time. They are ideal when:

Requirements are expected to change.

Deadlines are tight and a partial version is needed quickly.

Core requirements are known but details are uncertain.

The two main evolutionary models are Prototyping and the Spiral Model.

SPM 5
 A. Prototyping
Prototyping helps when customers know general goals but not detailed requirements, or when developers are
unsure about technical feasibility.

Steps in Prototyping:

1. Communication – stakeholders discuss objectives.

2. Quick planning and design focusing on user-visible features.

3. Construction of the prototype.

4. Deployment and feedback – prototype is evaluated and refined.

Prototypes can be throwaway (used only for requirement gathering) or evolutionary (gradually improved into the
final system).

Problems with Prototyping:

Stakeholders may demand release of an incomplete prototype.

Developers may use temporary, inefficient solutions that end up in the final product.

B. The Spiral Model

The Spiral Model combines features of the Waterfall and Prototyping models. It is mainly used for large projects.

It follows a cyclic approach where each loop represents one iteration through planning, modeling, construction,
and deployment, reducing risks progressively. Milestones called anchor points help ensure commitment from
stakeholders.

Each spiral phase adjusts plans and cost estimates, and the number of cycles depends on project needs. Early
loops may focus on concept development, followed by product development and later enhancement phases.

5. Concurrent Models
The concurrent model allows different activities to run in parallel. For example, while modeling is under
development, communication may be awaiting changes.

Each activity can exist in states such as inactive, under development, awaiting changes, under review, or done.
State transitions occur based on project events, providing a real-time view of project status.

Final Word on Evolutionary Processes

Modern software development faces rapid change and short delivery times. Evolutionary processes help meet
these needs but also have challenges:

Planning is difficult because the number of iterations is uncertain.

If iterations happen too quickly, the project can become chaotic; too slowly, productivity drops.

Excess focus on flexibility may affect overall software quality.

Specialized Process Models

Specialized models apply to specific types of software engineering projects.

1. Component-Based Development
This model builds software using pre-existing components with defined functionality and interfaces. It borrows
from the Spiral Model and encourages software reuse, reducing cost and time.

Steps:

1. Research and evaluate existing components.

2. Consider integration and compatibility.

3. Design an architecture that supports these components.

SPM 6
 4. Integrate components into the system.

5. Test the final integrated system thoroughly.

2. The Formal Methods Model

This model uses mathematical techniques to specify and verify systems. It helps find ambiguities and errors early
and is especially useful for safety-critical systems.
Disadvantages:

Time-consuming and expensive to develop.

Requires developers with strong mathematical backgrounds.

Difficult for non-technical stakeholders to understand.

The Unified Process (UP)

The Unified Process is a use-case driven, architecture-centric, iterative, and incremental software process. It
combines the strengths of traditional models while supporting agile methods.

Phases of the Unified Process:

1. Inception: Identify business needs, create initial use cases, propose an architecture, and make a project plan.

2. Elaboration: Refine architecture and use cases, and develop a working baseline of the system.

3. Construction: Build the software components, implement features, perform integration, and testing.

4. Transition: Deliver the software to users for beta testing, gather feedback, and prepare user documentation.

5. Production: Deploy the final product, provide support, monitor performance, and handle updates or bug fixes.

Personal and Team Process Models

1. Personal Software Process (PSP)

The PSP focuses on individual improvement and quality tracking. It encourages developers to measure their work,
find errors early, and improve efficiency.

Activities of PSP:

1. Planning – define requirements, estimates, and schedule.

2. High-Level Design – design system components.

3. High-Level Design Review – check for design errors.

4. Development – refine design, code, review, compile, and test.

5. Postmortem – evaluate metrics and identify areas for improvement.

PSP is beneficial but not widely used due to the need for specialized training.

2. Team Software Process (TSP)

The TSP helps create self-directed teams that plan and manage their own work while maintaining high quality.
Objectives of TSP:

Build teams that take ownership of their work.

Help managers guide and motivate their teams.

Improve software process maturity and efficiency.

TSP Activities:
Include project launch, design, implementation, integration, testing, and postmortem. The team follows defined
scripts, forms, and standards to ensure consistency and performance.

SPM 7
 Chapter 3: Agile Development
Agile methods were developed to overcome the weaknesses of traditional software engineering approaches.
They are designed for dynamic business environments where market conditions change rapidly, user
requirements evolve, and new competition emerges frequently.

Manifesto for Agile Software Development

The Agile Manifesto was created to promote better ways of developing software through practical experience and
collaboration. It marked a major shift in the mindset of software development, emphasizing flexibility and
adaptability.
The manifesto’s authors, including Kent Beck and others, proposed four core values that form the foundation of
Agile methodology.

Core Values
Agile development emphasizes:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

While the items on the right have value, Agile gives greater importance to the items on the left.

The Importance of Change

Change is the central theme of software development. An Agile team is built to respond effectively to changes in
requirements, team composition, or technology. Agile methods integrate change-handling mechanisms into every
part of the process, recognizing that flexibility is the heart and soul of software engineering.

Agility and the Cost of Change

Traditional View:
In conventional software development, the cost of making changes increases drastically as the project
progresses.

Early Stage: Changes are inexpensive during requirements gathering and can be easily accommodated.

Late Stage: Late-stage changes (such as during testing) are costly and time-consuming.

Agile View:

Agile aims to flatten this “cost of change” curve. It ensures that adaptations can be made at any stage of
development without major financial or time setbacks.

An Agile Process
Agile processes are based on certain key assumptions about software projects:

Key Assumptions
It is difficult to predict in advance which requirements will remain stable.

Customer priorities may shift as the project progresses.

Design and construction often overlap.

Analysis, design, construction, and testing are not always predictable activities.

Characteristics

SPM 8
 Based on these assumptions, Agile processes emphasize adaptability and quick response to change:

Customer Feedback: Agile teams rely on continuous customer input, ideally based on working prototypes or
usable increments.

Incremental Delivery: Software is released in small, functional parts, enabling frequent evaluation and timely
adjustments.

The 12 Principles of Agility

The Agile Alliance defined twelve guiding principles for Agile development. Some of the key principles include:

1. The highest priority is customer satisfaction through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development, to give the customer a competitive advantage.

3. Deliver working software frequently (every few weeks or months).

4. Business stakeholders and developers must work together daily.

5. Build projects around motivated individuals and trust them to deliver quality results.

Agile Process Models

Several process models implement Agile principles in different ways. The most widely used ones are discussed
below.

1. Extreme Programming (XP)

XP is one of the most popular Agile development methods. It organizes requirements as “stories”, which
describe features from the user’s perspective.

Story Costing: Each story is estimated in terms of development time. Large stories (taking more than three
weeks) are split into smaller ones.

Release Planning: Developers and customers collaborate to group stories for upcoming releases.

Prioritization: Teams may choose to implement stories based on highest value, highest risk, or simply in
sequence.

2. Scrum
Scrum focuses on iterative progress, flexibility, and collaboration. It is particularly effective for projects with tight
deadlines and evolving requirements.

Framework Activities: Includes requirements, analysis, design, evolution, and delivery.

Backlog: A prioritized list of project features that deliver business value. Items can be added anytime.

Sprints: Fixed time periods (usually 2–4 weeks) during which specific backlog items are completed. No new
changes are introduced during a sprint.

Demos: At the end of each sprint, a working software increment is demonstrated to the customer for
feedback.

3. Dynamic Systems Development Method (DSDM)

DSDM is an iterative and incremental Agile framework.

Concurrent Iterations: Functional modeling (requirements) and design/build iterations happen

simultaneously.

Implementation: Each increment is released into the operational environment for review.

Continuous Development: Feedback from users may lead to further iterations until completion.

4. Agile Modeling (AM)

SPM 9
 Agile Modeling focuses on creating lightweight and practical models rather than exhaustive documentation.

Travel Light: Keep only models that provide ongoing value.

Content Over Representation: Focus on what the model conveys rather than how it looks.

Know Your Models and Tools: Understand their strengths and limitations.

Adapt Locally: Tailor the modeling approach to fit the specific needs of the team.

5. Agile Unified Process (AUP)

AUP is a streamlined version of the Rational Unified Process (RUP) built around Agile concepts.

Deployment: Focuses on incremental delivery and feedback from users.

Configuration and Project Management: Deals with managing changes, risks, and tracking progress.

Environment Management: Ensures the team has proper tools, standards, and infrastructure support.

SPM 10