Chapter 1: Software and Software Engineering

1.1 The Nature of Software

●​ Definition of Software:
○​ Software is a collection of instructions (called programs), data, and
documents that makes a computer perform specific tasks.
○​ It’s not something you can touch like a keyboard; it’s the “brain” that tells
the computer what to do.
○​ Analogy: Think of software as a recipe (instructions) and ingredients (data)
that a chef (computer) uses to make a dish (task).
○​ Example: The Instagram app is software—it has code to show photos, data
like your profile, and a help guide.
●​ Types of Software (Application Domains):
○​ Software comes in different types, each serving a specific purpose:
1.​ System Software: Runs the computer itself.
■​ Example: Windows 10 helps your laptop start and run other
apps.
2.​ Application Software: Helps users do tasks.
■​ Example: Microsoft Word for writing documents.
3.​ Engineering/Scientific Software: Used for technical calculations.
■​ Example: Software for designing bridges or simulating
weather.
4.​ Embedded Software: Built into devices to control them.
■​ Example: The software in a microwave that sets cooking time.
5.​ Product-Line Software: For business operations.
■​ Example: A system to track sales in a store.
6.​ Web Applications: Run on browsers.
■​ Example: Netflix’s website for streaming movies.
7.​ Artificial Intelligence Software: Makes smart decisions.
■​ Example: Siri answering your questions.
○​ Analogy: Think of these as different types of vehicles—cars (application
software) for daily use, trucks (system software) for heavy work, or drones
(AI software) for smart tasks.
●​ Definition of Legacy Software:
○​ Legacy software is old software that a company still uses but is hard to
update or fix.
○​ Why It’s a Problem: It uses outdated technology, may lack manuals, and is
expensive to maintain.
 ○​ Example: A bank using a 1990s system to process loans—it works but
struggles with modern apps.
○​ Analogy: Like an old car that still runs but is hard to find parts for.

1.2 Defining the Discipline

●​ Definition of Software Engineering:

○​ Software engineering is the process of designing, building, testing, and
maintaining software in a planned, organized way to ensure it works well
and meets user needs.
○​ It’s like building a house—you need a blueprint, tools, and a team, not just
random hammering.
○​ Example: Creating a school app to track grades involves planning features,
coding, testing, and updating it.
●​ Layers of Software Engineering:
○​ Software engineering has four layers, like a cake:
1.​ Quality Focus: The base—ensuring the software is reliable and
bug-free.
■​ Example: Checking that a game app doesn’t crash.
2.​ Process: The steps to follow, like a recipe.
■​ Example: Deciding to plan, code, and test in order.
3.​ Methods: Techniques for each step.
■​ Example: Using a specific way to test the app, like checking
each button.
4.​ Tools: Software or apps to help the team.
■​ Example: Using Visual Studio to write code.
○​ Analogy: Building a house needs a goal (quality), a plan (process),
techniques (methods like hammering), and tools (hammers).

1.3 The Software Process

●​ Definition of a Software Process:

○​ A software process is a set of steps to create software, like following a map
to reach a destination.
○​ It ensures the software is built correctly and on time.
○​ Example: To make a calculator app, you plan, design, code, test, and release
it.
●​ Process Framework (The Main Steps)**:
○​ Every software project follows these five steps:
■​ Communication: Talk to users to understand what they want.
 ■​ Example: Meeting a teacher to learn they need an app to
track student attendance.
■​ Planning: Make a plan for tasks, timeline, and resources.
■​ Example: Deciding to finish the app in 3 months with 5
developers.
■​ Modeling: Draw designs, like sketching how the app will look or work.
■​ Example: Creating a diagram showing the app’s attendance
screen.
■​ Construction: Write the code and test it to find errors.
■​ Example: Coding the app and testing if the attendance
feature works.
■​ Deployment: Give the software to users and fix any issues.
■​ Example: Installing the app in the school and updating it if
teachers find bugs.
○​ Analogy: Like baking a cake—talk to the customer (what flavor?), plan (buy
ingredients), design (mix batter), bake (cook), and serve (deliver).
●​ Definition of Umbrella Activities:
○​ Umbrella activities are extra tasks done throughout the project to keep it on
track and ensure quality.
○​ They’re like checking your work while cooking to avoid mistakes.
○​ Examples:
■​ Software Project Tracking and Control: Check if the project is on
schedule.
■​ Example: Seeing if the app is halfway done after 1.5 months.
■​ Risk Management: Plan for problems, like a developer getting sick.
■​ Example: Having a backup coder ready.
■​ Software Quality Assurance (SQA): Make sure the software is good.
■​ Example: Testing the app to ensure no crashes.
■​ Software Configuration Management (SCM): Track changes to
code.
■​ Example: Saving different versions of the app’s code.
■​ Documentation: Write guides for users and developers.
■​ Example: Creating a manual for teachers to use the app.
●​ Definition of Process Adaptation:
○​ Process adaptation means changing the process to fit the project’s needs.
○​ Example: For a hospital app, add extra testing to ensure it’s safe for
patients.
○​ Analogy: Adjusting a recipe for a bigger party by doubling the ingredients.

1.4 Software Engineering Practice

 ●​ Definition of Software Engineering Practice:
○​ The practical steps and rules to build software correctly.
○​ It’s about solving problems smartly, not just coding randomly.
●​ Core Principles (Essence of Practice):
○​ Four key ideas to follow:
■​ Understand the Problem: Know what the user needs before starting.
■​ Example: Ask a store owner what features they want in a
sales app.
■​ Plan a Solution: Make a clear plan before coding.
■​ Example: Decide to build the login screen first, then the sales
tracker.
■​ Carry Out the Plan: Follow the plan and code carefully.
■​ Example: Write the login code and test it.
■​ Examine the Result: Test everything to ensure it works.
■​ Example: Check if the sales tracker shows correct numbers.
○​ Analogy: Like building a toy model—read the instructions, plan the steps,
assemble, and check if it looks right.
●​ General Principles:
○​ Simple rules to make software better:
■​ Deliver what users need.
■​ Keep designs simple.
■​ Test often to catch errors.
■​ Be ready for changes.
○​ Example: For a music app, keep the play button easy to use and test it
before release.

1.5 How It All Starts

●​ Definition of Project Initiation:

○​ A software project starts when someone has a problem or need that
software can solve.
○​ Example: A library wants an app to track books, so the project begins.
●​ Steps to Start:
○​ Identify the problem (e.g., manual book tracking is slow).
○​ Talk to users to list needs (e.g., search books, check availability).
○​ Plan the project (e.g., 6 months, 3 developers).
○​ Analogy: Like planning a road trip—decide where to go, what you need, and
how long it’ll take.
Chapter 2: Process Models
2.1 A Generic Process Model

●​ Definition of a Process Model:

○​ A process model is a plan or guide that shows how to build software step by
step.
○​ It’s like a map for a journey, showing the path to follow.
●​ Definition of Generic Process Model:
○​ A basic, flexible plan that works for any software project, with five steps:
1.​ Communication: Understand what the user wants.
■​ Example: Talk to a restaurant owner about a food ordering
app.
2.​ Planning: List tasks, timeline, and team needs.
■​ Example: Plan to build the app in 4 months with 4 coders.
3.​ Modeling: Draw how the software will work (like a blueprint).
■​ Example: Sketch the app’s menu and order screens.
4.​ Construction: Write code and test it.
■​ Example: Code the order feature and test if it works.
5.​ Deployment: Give the software to users and fix issues.
■​ Example: Launch the app and update it if users report bugs.
○​ Analogy: Like building a Lego set—talk to the kid (what model?), plan
pieces, design the structure, build it, and show it off.

2.2 Defining a Framework Activity

●​ Definition of Framework Activity:

○​ A framework activity is one of the main steps in a process model (like
Communication or Construction).
○​ Each step has smaller tasks to complete it.
○​ Example: For “Modeling,” tasks include drawing a diagram of how users
order food in the app.
○​ Analogy: Each activity is like a chapter in a book, with smaller sections
inside.

2.3 Identifying a Task Set

●​ Definition of Task Set:

○​ A task set is a list of specific jobs to do for a framework activity.
○​ Example: For “Construction,” tasks are:
■​ Write code for the order button.
 ■​ Test the button to ensure it works.
■​ Fix any errors found.
○​ Why It Matters: Keeps the team organized, like a to-do list.
○​ Analogy: Like a shopping list for cooking—you need specific items (tasks) to
make the dish (activity).

2.4 Process Assessment and Improvement

●​ Definition of Process Assessment:

○​ Checking how well the process is working to find problems.
○​ Example: If the app is delayed, check if planning was bad.
●​ Definition of Process Improvement:
○​ Making the process better to avoid problems and save time.
○​ Uses standards like CMMI (a guide to improve processes).
○​ Example: Add a tool to test the app automatically, saving time.
○​ Analogy: Like checking why your cake tastes bad (assessment) and using a
better recipe next time (improvement).

2.5 Prescriptive Process Models

●​ Definition of Prescriptive Process Model:

1.​ A specific, detailed plan for building software, unlike the flexible generic
model.
2.​ Each model has strict steps to follow.
●​ Types of Prescriptive Models:
1.​ Waterfall Model:
■​ Definition: A step-by-step model where each phase (step) is
completed before the next begins, like a waterfall flowing down.
■​ Phases:
■​ Requirements Analysis: List what the software must do.
■​ System Design: Plan how it will work.
■​ Implementation: Write code.
■​ Testing: Check for errors.
■​ Deployment: Give it to users.
■​ Maintenance: Fix issues later.
■​ When to Use: For projects with clear, unchanging needs.
■​ Pros: Easy to follow, clear steps.
■​ Cons: Can’t change requirements mid-way.
■​ Example: Building a payroll system for a company with fixed rules.
■​ Analogy: Like following a strict recipe—you can’t add ingredients
after baking starts.
2.​ Prototyping Model:
■​ Definition: Build a rough version (prototype) of the software to show
users and get feedback before making the final version.
■​ Steps:
■​ Talk to users about needs.
■​ Build a prototype (e.g., a basic app screen).
■​ Show it to users and get feedback.
■​ Improve the prototype or build the final software.
■​ When to Use: When users aren’t sure what they want.
■​ Pros: Helps understand user needs.
■​ Cons: May skip proper planning or documentation.
■​ Example: Creating a prototype of a game’s menu to see if players
like it.
■​ Analogy: Like sketching a dress design to check if the client likes it
before sewing.
3.​ Evolutionary Process Model:
■​ Definition: Build software in small parts, releasing each part to users
and improving it based on feedback.
■​ Types:
■​ Incremental: Add new features in each version.
■​ Spiral: Focus on risks in each cycle.
■​ Steps:
■​ Build a small part (e.g., basic app).
■​ Release it and get feedback.
■​ Add more features and repeat.
■​ When to Use: For projects where needs change often.
■​ Pros: Users get software early, easy to change.
■​ Cons: Can get messy if too many changes are added.
■​ Example: A music app starts with a play feature, then adds playlists
later.
■​ Analogy: Like building a house room by room, letting the owner use it
while adding more.
4.​ Unified Process Model:
■​ Definition: A model that builds software in cycles (iterations), with
four main phases.
■​ Phases:
■​ Inception: Plan the project, define goals, and check if it’s
possible.
■​ Elaboration: Design the system and fix major problems.
■​ Construction: Write most of the code.
■​ Transition: Deliver the software and fix issues.
 ■​ Key Feature: Uses use cases (stories of how users will use the
software) to define needs.
■​ When to Use: For complex projects needing structure and flexibility.
■​ Pros: Balances planning and adaptability.
■​ Cons: Can be complicated for small projects.
■​ Example: Building a banking app with use cases like “user withdraws
money.”
■​ Analogy: Like writing a book—plan the plot, draft chapters, write the
full story, and publish.
5.​ V-Model (From Quiz Context, Related to Pressman’s Prescriptive Models)**:
■​ Definition: An extension of the Waterfall Model where each
development phase has a matching testing phase, forming a “V”
shape.
■​ Phases:
■​ Requirements Analysis ↔ Acceptance Testing (check if it
meets user needs).
■​ System Design ↔ System Testing (check if the system works
together).
■​ Detailed Design ↔ Unit Testing (check individual parts).
■​ Implementation (coding).
■​ When to Use: For projects needing strong testing, like safety
systems.
■​ Pros: Testing is planned early, ensures quality.
■​ Cons: Hard to change requirements.
■​ Example: A hospital system where every feature is tested before
release.
■​ Analogy: Like building a bridge—plan and test each part (beams,
supports) before opening it.
6.​ Spiral Model (From Quiz Context, Pressman Section 2.5.3)**:
■​ Definition: A model that builds software in cycles, focusing on
identifying and fixing risks each time.
■​ Phases per Cycle:
■​ Objectives Definition: Set goals and needs.
■​ Risk Analysis: Find and fix potential problems.
■​ Engineering: Build and test a version.
■​ Evaluation: Check results and plan the next cycle.
■​ When to Use: For risky or complex projects, like space systems.
■​ Pros: Handles risks well.
■​ Cons: Can be expensive and slow.
■​ Example: A drone system where each cycle tests a new feature, like
navigation.
 ■​ Analogy: Like climbing a mountain—plan each step, check for
dangers, move up, and repeat.

2.6 Product and Process

●​ Definition of Product:
○​ The final software delivered to users, like an app or system.
○​ Example: A completed food delivery app.
●​ Definition of Process:
○​ The steps used to build the software, like Waterfall or Prototyping.
○​ Example: Using the Prototyping Model to build the app.
●​ Why They Matter:
○​ A good process makes a better product (fewer bugs, faster delivery).
○​ Example: Using the Evolutionary Model ensures a video app gets new
features users want.

Chapter 3: Agility and Process

3.1 What Is Agility?

●​ Definition of Agility:
○​ Agility is the ability to quickly adapt to changes in what users want or new
technology, while delivering software fast.
○​ It’s about being flexible, not stuck to a rigid plan.
○​ Example: A news app adds a “live updates” feature after users ask for it.
○​ Analogy: Like a chef tweaking a dish based on customer tastes during
cooking.

3.2 Agility and the Cost of Change

●​ Definition of Cost of Change:

○​ The cost (time and money) to fix or change software.
○​ In rigid models (like Waterfall), changes late in the project are expensive
because you redo a lot.
○​ Agile models make changes cheaper by working in small steps and testing
often.
○​ Example: Fixing a bug in a game app is easier if caught in a 2-week cycle,
not after 6 months.
○​ Analogy: Fixing a typo in a draft is easier than reprinting a published book.
3.3 What Is an Agile Process?

●​ Definition of Agile Process:

○​ An agile process is a flexible way to build software by working in short
cycles, delivering small parts often, and listening to users.
○​ It values people, working software, and adaptability over strict plans or
heavy paperwork.
●​ Key Ideas:
○​ Work closely with users.
○​ Release usable software every few weeks.
○​ Be ready to change plans.
○​ Test all the time to catch errors.
●​ Definition of Agility Principles:
○​ Rules for agile work, from the Agile Manifesto:
■​ Deliver working software often (every 2–4 weeks).
■​ Welcome changes, even late in the project.
■​ Talk to users daily.
■​ Trust the team to do good work.
○​ Example: A team builds a fitness app, releasing a workout tracker first, then
adding a diet planner after user feedback.
○​ Analogy: Like painting a house—do one room, show it to the owner, adjust
colors, and move to the next.
●​ Politics of Agile Development:
○​ Definition: Challenges when switching to agile, like resistance from teams or
bosses who like old methods.
○​ Example: A company used to Waterfall may not like Agile’s less detailed
plans.
○​ Analogy: Like convincing someone to try a new phone when they love their
old one.

3.4 Scrum

●​ Definition of Scrum:
○​ Scrum is a popular agile method that builds software in short cycles called
sprints (usually 2–4 weeks), delivering a working piece each time.
○​ It’s about teamwork, quick delivery, and fixing problems fast.
○​ Example: A team uses Scrum to build a travel app, delivering a flight
booking feature in one sprint.
○​ Analogy: Like running a relay race—each sprint is a lap, passing the baton
(software) to the next.
●​ Scrum Teams and Artifacts:
 ○​ Definition of Roles:
■​ Product Owner: Decides what features to build and their order.
■​ Example: Chooses to add flight booking before hotel booking.
■​ Scrum Master: Helps the team follow Scrum and solves problems.
■​ Example: Fixes a delay by getting a new computer for a
coder.
■​ Development Team: Builds the software (coders, testers, designers).
■​ Example: Codes and tests the booking feature.
○​ Definition of Artifacts:
■​ Product Backlog: A list of all features or tasks the software needs,
prioritized by the Product Owner.
■​ Example: A list with “flight booking,” “hotel booking,” and
“maps.”
■​ Sprint Backlog: The tasks chosen for the current sprint.
■​ Example: “Code flight booking” and “test search feature” for
a 2-week sprint.
■​ Increment: The working software delivered at the end of a sprint.
■​ Example: A flight booking feature users can try.
○​ Analogy: Like planning a party—make a wish list (Product Backlog), pick
tasks for today (Sprint Backlog), and finish the decorations (Increment).
●​ Scrum Events:
○​ Sprint Planning Meeting:
■​ Definition: A meeting to decide what to build in the next sprint and
how.
■​ Example: Plan to build the flight booking feature in 2 weeks.
■​ Duration: 4–8 hours for a month-long sprint.
○​ Daily Scrum Meeting:
■​ Definition: A quick 15-minute meeting every day to discuss what’s
done, what’s next, and any problems.
■​ Example: A coder says they finished the search button but needs
help with testing.
○​ Sprint Review Meeting:
■​ Definition: A meeting to show the finished work to users and get
feedback.
■​ Example: Show the flight booking feature and hear if users want
changes.
○​ Sprint Retrospective:
■​ Definition: A meeting to discuss what went well and what to improve
in the next sprint.
■​ Example: The team realizes testing took too long and plans to use a
new tool.
○​ Analogy: Like a school project—plan the topic, check progress daily, show
the draft to the teacher, and discuss how to do better next time.