Slide-set 1:

Plan and document:

Chatgpt notes:
●​ A comprehensive plan is created before any coding begins.
●​ The project manager defines all phases—requirements, design, implementation,
testing, and maintenance.
●​ Detailed documentation is produced for each phase of the development lifecycle.
●​ Progress is measured strictly against the predefined plan.
●​ Any changes to the project (e.g., scope or requirements) must be:
●​ Updated in the documentation.
●​ Possibly reflected in a revised plan.
●​ Emphasizes predictability, control, and traceability in development.
●​ Suitable for projects with well-defined requirements and low tolerance for change
(e.g., defense, aerospace, regulated industries).

Powerpoint notes:
●​ Before coding, project manager makes plan
●​ Write detailed documentation all phases of plan
●​ Progress measured against the plan
●​ Changes to project must be reflected in documentation and possibly to plan

Plan and document processes include Waterfall, Spiral and RUP.

1.​ WaterFall:

Waterfall Approach – Key Concepts:

●​ A linear and sequential software development model.

●​ The project is divided into 5 distinct phases completed one after another.
●​ Each phase must be completed (and approved) before moving to the next.
●​ Emphasizes planning, documentation, and early bug detection.
●​ Designed for projects with clearly defined requirements and minimal expected changes.​

5 Phases of the Waterfall Lifecycle:

 1.​ Requirements Analysis & Specification​

○​ Gather and document what the system should do.

○​ Define all user and system requirements.​

2.​ Architectural Design​

○​ Create system architecture and design specifications.

○​ Define system components and their interactions.​

3.​ Implementation & Integration​

○​ Write code based on the design.

○​ Integrate system components.​

4.​ Verification / Testing​

○​ Test the product against original requirements.

○​ Identify and fix bugs.​

5.​ Operation & Maintenance​

○​ Deploy the product to users.

○​ Handle updates, fixes, and ongoing support.

Why Each Phase Is Completed Before the Next

●​ Catching bugs early in development is cheaper and easier to fix.

●​ Ensures each phase is thoroughly reviewed and documented.
●​ Reduces risk of miscommunication or missing steps.

Strengths of the Waterfall Model

●​ Strong documentation at each phase for traceability and onboarding.

●​ Predictable structure and timeline.
●​ Easier to manage in regulated or low-change environments.
Common Issues and Criticisms

●​ Lack of flexibility for changing requirements once development begins.

●​ Users may say:​
“It’s just what we asked for, but not what we want.”​
→ Highlights the gap between documented specs and real user needs.
●​ Customer feedback comes too late—usually only after the final product is delivered.
●​ Developers often realize a better way to build the product after completing it once.

2.​ Spiral:

Spiral Approach – Key Concepts

●​ A risk-driven, iterative software development model.

●​ Combines Plan-and-Document with prototyping.
●​ Requirements and documentation are created as needed across iterations—not all at
once at the start.
●​ Each cycle (or spiral) produces a refined prototype and updated plans.
●​ Focuses on early risk identification and continuous customer involvement.​

Key Steps in Each Spiral Iteration

1.​ Determine Objectives and Constraints​

○​ Define what needs to be achieved in the current iteration.

○​ Identify project goals, constraints (e.g., budget, technology), and success criteria.​

2.​ Evaluate Alternatives and Identify & Resolve Risks​

○​ Explore different approaches to achieving objectives.

○​ Analyze and address technical, operational, and financial risks.​

3.​ Develop and Verify Prototype​

○​ Build a partial implementation (prototype or component).

○​ Test and verify it against objectives to confirm progress.​
 4.​ Plan the Next Iteration​

○​ Review customer feedback and test results.

○​ Decide on the next set of features, goals, and updates to the plan.​

Strengths of the Spiral Model (The Good)

●​ Involves customers in every iteration, reducing misunderstandings.

●​ Prototypes validate requirements early and allow for adjustments.
●​ Built-in risk management improves project stability.
●​ Better monitoring and tracking as the project progresses.
●​ Estimates for cost and schedule improve with each iteration.

Weaknesses of the Spiral Model (The Bad)

●​ Iterations may take 6–24 months, delaying delivery.

●​ Long timelines give customers time to change requirements.
●​ Heavy documentation required for each iteration.
●​ Complex model with many rules—can be hard for teams to manage.
●​ High process cost, requiring skilled management and planning.
●​ Challenging to meet fixed budgets and deadlines.​

3.​ RUP:

RUP (Rational Unified Process) – Key Concepts

●​ RUP is an iterative and incremental software development framework developed by

Rational Software (now part of IBM).
●​ It provides a structured approach by dividing the development process into phases and
disciplines, and emphasizing best practices.
●​ RUP is customizable—it can be tailored to fit a company’s size, project needs, and goals.
 ●​ The model emphasizes continuous improvement, risk management, and tool support
throughout the lifecycle.​

4 Phases of the RUP Lifecycle (Iterations Can Occur Within Each)

1.​ Inception​

○​ Define the business case.

○​ Set initial schedule, scope, and budget.
○​ Identify major risks and feasibility.​

2.​ Elaboration​

○​ Refine use cases and define major system functionality.

○​ Establish software architecture.
○​ Build key prototypes to resolve risks.​

3.​ Construction​

○​ Code and test the system based on the refined architecture.

○​ Complete most development.
○​ Deliver a first working release.​

4.​ Transition​

○​ Deploy the software to the real-world environment.

○​ Handle user feedback and achieve customer acceptance.
○​ Final bug fixes and documentation.​

Disciplines Tracked Across Phases (RUP Activities)

●​ Business Modeling
●​ Requirements Engineering
●​ Analysis and Design
●​ Implementation
 ●​ Testing
●​ Deployment​

📈 These activities vary in intensity across phases—e.g., more requirements work

in Inception and Elaboration, more coding in Construction, more deployment in
Transition.

Strengths of RUP (The Good)

●​ Business goals tightly linked to development process.

●​ Strong support for incremental development and risk management.
●​ Offers a comprehensive toolset (e.g., from Rational/IBM) to support workflows.
●​ Tools and process encourage gradual, managed improvements over time.
●​ Iterative nature allows for early feedback and adaptation.​

Weaknesses of RUP (The Bad)

●​ Tools are expensive and mostly not open-source.

●​ Open-source alternative: OpenUP (simplified version of RUP).
●​ So many customization options that teams may not use all tools effectively.
●​ Best suited for medium to large-scale projects—overkill for small teams.
●​ Managers decide iteration size, which affects manageability and agility.

Plan-and-Document Project Manager:

●​ Plan-and-Document depends on Project Managers

○​ Write contract to win the project
○​ Recruit development team
○​ Evaluate software engineer’s performance, which sets salary
○​ Estimate costs, maintain schedule, evaluate risks & overcomes them
○​ Document project management plan
○​ Gets credit for success or blamed if projects are late or over budget
The team size is usually groups of 4 to 9 people but it can be hierarchically composed for larger
groups. The more the team members the more time is spent on communication hence less time
for work.

Development Processes:

Development Process is often referred to as Software Development Lifecycle (SDLC)

▪ Plan-and-Document and Agile is generally spit into:

• Waterfall

• Iterative (which includes the Rational Unified Process and Spiral)

• Agile

▪ Agile has become so broad that it is generally clarified into subcategories including:

• Scrum

• XP (formerly Extreme Programming)

• Kanban

• Test-Driven Development, etc.

1.​ Agile:

Agile Approach – Key Concepts

●​ Agile is an iterative and incremental software development methodology.

●​ Emphasizes flexibility, collaboration, customer feedback, and continuous
improvement.
●​ Prioritizes delivering working software frequently, in short iterations, with constant
refinement.
●​ Values individuals and interactions over strict processes, working software over heavy
documentation, and customer collaboration over contract negotiation.​
Core Principles from the Agile Manifesto

●​ Individuals and interactions over processes and tools.

●​ Working software over comprehensive documentation.
●​ Customer collaboration over contract negotiation.
●​ Responding to change over following a plan.​

"That is, while there is value in the items on the right, we value the items on the left
more."

Agile Lifecycle – Key Characteristics

●​ Continuous improvement: Agile embraces change as a natural part of the development

process.
●​ Iterative development: Developers work on incomplete prototypes and refine them
based on feedback.
●​ Frequent iterations: Each iteration lasts 1 to 3 weeks, delivering working but partial
software after every cycle.
●​ Customer feedback is gathered after each iteration to ensure the product is heading in
the right direction.​

Key Practices in Agile

1.​ User Stories​

○​ Customer requirements are captured as User Stories, which are simple, informal
descriptions of software features from the user’s perspective.
○​ User Stories validate whether customer needs are being met throughout
development.​

2.​ Test-Driven Development (TDD)​

○​ Tests are written before code to prevent mistakes and ensure functionality.
 ○​ Early error detection ensures that the software meets requirements from the
start.​

3.​ Velocity​

○​ Velocity measures how much work the team can handle in each iteration, helping
to gauge progress.
○​ Provides insight into team capacity and helps predict future work.​

4.​ Customer Collaboration​

○​ Continuous interaction with the customer during each iteration ensures the
software is aligned with their expectations and needs.​

Advantages of Agile

●​ Flexibility: Adapt to changes in requirements even late in the project.

●​ Faster delivery: Regular, incremental releases mean faster time-to-market.
●​ Customer satisfaction: Regular feedback ensures the product meets customer needs.
●​ Improved quality: Through Test-Driven Development (TDD) and frequent testing.​

Challenges of Agile

●​ High customer involvement is required at all stages.

●​ Scaling issues: Agile can be harder to implement for larger, more complex projects.
●​ Less documentation, which may make it harder for new team members to understand
the project’s full context without active communication.​

Service-oriented Architecture (SOA):

1.​ Silo:
Silo – Definition

●​ A silo is a separate subsystem within a larger system that operates independently from
other subsystems.
●​ It often leads to separation of data and processes within a system or organization.
●​ Subsystems in a siloed architecture typically don’t easily share data unless explicitly
designed to interact.​

Characteristics of Silos in the Given Context

●​ Internal subsystems can share data directly: While silos imply separation, subsystems
can still interact through shared data or APIs.
●​ Access to user profiles: Each subsystem, like Review or Buying, might manage user
profile data independently but can still reference or access shared information.​

Example Subsystems in a Siloed System

Review Subsystem: Manages reviews and user orders.

Buying Subsystem: Handles purchases and transactions.

Bookstore Service Subsystem: Manages book catalog and purchasing process.

 2.​ SOA:

SOA – Definition

●​ Service-Oriented Architecture (SOA) is an architectural pattern where independent

services communicate with each other through standardized APIs.
●​ Services are self-contained and can be recombined to form new functionalities.
●​ Services are loosely coupled, allowing for flexibility, scalability, and easier maintenance.​

Characteristics of SOA in the Given Context

●​ Independent Subsystems: Services like Review Service, User Profile Service, and
Buying Service operate independently but interact through APIs.
●​ Interoperability: Services can be hosted in different datacenters and still communicate
through APIs, ensuring data sharing across different environments.​

For example:

●​ Review Service accesses the User Service API to retrieve user information for reviews.
 ●​ Buying Service interacts with Credit Card Processing Service to handle payments.​

Example Subsystems in SOA (Bookstore)

●​ Bookstore Service: Manages the catalog of books and purchases.

●​ User Profile Service: Handles user data such as preferences and purchase history.
●​ Review Service: Manages user reviews for books.
●​ Buying Service: Processes payments and handles orders.
●​ Social Network Service: Integrates social media features (e.g., sharing books or
reviews).
●​ Favorite Books Service: A new service created by combining the Bookstore and
Review Services, allowing users to favorite books and add reviews.​

Advantages of SOA

●​ Loose Coupling: Services operate independently, making it easier to update or replace

them without affecting other services.
●​ Flexibility: New services can be recombined to create new functionalities, like the
Favorite Books Service.
●​ Scalability: SOA allows for scaling individual services without impacting the entire
system.
●​ Interoperability: Different services can communicate across systems and datacenters
via standardized APIs.
Difference between them:

Silo vs. SOA (Service-Oriented Architecture)

●​ Silo​

○​ Subsystems or components operate independently and often without easy data

sharing.
○​ Data and processes are often isolated and not easily integrated unless explicitly
designed.
○​ Limited interaction between subsystems unless there is some shared data or
integration layer.​

●​ SOA (Service-Oriented Architecture)​

○​ Subsystems (often called services) are independent but communicate through

standardized interfaces (APIs).​
 ○​ Each service is a self-contained unit that performs a specific task, but can share
data and interact with other services through service contracts.
○​ Designed to be flexible and scalable, allowing services to be easily replaced or
modified without affecting the whole system.​

Key Differences:

●​ Integration: In a silo, subsystems operate independently and can be isolated. In SOA,

even though subsystems are independent, they are designed to communicate through
APIs or service contracts.​

●​ Data Sharing: Siloed systems might not share data easily without additional integration.
In SOA, sharing data between services is a core feature, enabled by standardized
communication protocols.

Software as a Service (SaaS):

SaaS (Software as a Service) – Definition

●​ Software as a Service (SaaS) is a server-centric application model where software is

hosted on a central server and provided to users through a web interface (thin client).
●​ SaaS allows users to access software remotely over the internet without needing to
install it on their devices or worry about hardware, operating systems, or compatibility.
●​ Data is stored centrally on servers, providing easy access and allowing multiple users or
teams to collaborate on the same data.
●​ SaaS is used for a variety of applications, including search, email, commerce, social
networks, productivity (e.g., Google Docs, Office 365), and finance (e.g., TurboTax
Online).​

SaaS vs. Native Applications

Native Applications (Traditional Software)

●​ Client-specific binaries are installed on individual devices.

●​ Frequent upgrades are required to ensure compatibility with hardware, operating
systems, and libraries.
●​ Native applications often have to be tested for compatibility with multiple versions of
hardware and software, making maintenance challenging.​

SaaS Benefits Over Native Applications

●​ No installation worries: Users don't have to worry about hardware capability, operating
system, or device compatibility. SaaS works on any device with internet access.
●​ Data storage: Data is safely and persistently stored on centralized servers, reducing the
risk of data loss.
●​ Simplified collaboration: Groups can easily interact with the same data, which is
stored centrally, without worrying about local versions.
●​ Centralized updates: Developers only need to maintain one copy of the software in a
single environment. This eliminates compatibility issues and simplifies upgrades.
○​ Beta testing can be done on a small percentage of users, allowing developers to
test new features without disrupting the whole user base.
○​ Users no longer need to request upgrades or worry about compatibility with new
versions.​

Why SaaS is Better/Easier Than Native Applications

●​ No compatibility issues: With SaaS, developers don't have to worry about ensuring the
software works across multiple hardware, OS, or library versions.​

●​ Centralized data: It’s easier to manage and maintain one copy of the software and data
in a central location, ensuring consistency for all users.
●​ Simplified upgrades: With SaaS, software is updated in the cloud, so users don’t need to
install new versions or worry about manual updates.​

SaaS vs. Smartphone Native Apps

Smartphone Native Apps

●​ Pros:
○​ Can utilize hardware features not available in web apps (e.g., camera, sensors).
○​ Performance can be superior in some cases (though many native apps are simply
containers for web-based applications).
○​ The app appears directly on the user's home screen, providing easy access.​

●​ Cons:
○​ Harder to maintain: Native apps need to be updated frequently, and upgrades
become the user's responsibility.
○​ Compatibility issues: Native apps require updates for each OS version and
device, making maintenance complex.

SaaS for Mobile Devices

●​ Easier to maintain: With SaaS, users don’t need to worry about updates or installation.
The latest version is always accessible from the web.
●​ No compatibility issues: As SaaS is web-based, there’s no need for separate versions for
different operating systems or devices.

Ideal hardware infrastructure for SaaS?

SaaS's 3 demands on infrastructure

1. Communication

◦ Allow customers to interact with service

2. Scalability

◦ Fluctuations in demand

3. Dependability

◦ Service & communication available 24x7

Services on Clusters
Clusters: Commodity computers connected by commodity Ethernet switches

More scalable than conventional servers

Much cheaper than conventional servers

◦ 20X for equivalent vs. largest servers

Dependability via extensive redundancy

Few operators for 1000s servers

◦ Careful selection of identical HW/SW

◦ Virtual Machine Monitors simplify operation

Cloud Computing:

Cloud Computing – Definition

●​ Cloud computing is the delivery of computing services (storage, processing, networking,

software) over the internet (the "cloud").
●​ Provides on-demand access to technology resources without needing physical
infrastructure.
●​ Users access resources on a pay-as-you-go basis, offering scalability, flexibility, and
cost efficiency.​

Key Characteristics of Cloud Computing

●​ Services on Clusters:​

○​ Cloud relies on clusters of commodity computers connected by commodity

Ethernet switches.
○​ Scalable and more cost-effective than traditional servers (e.g., 20x cheaper than
conventional servers).
○​ Provides redundancy for dependability and minimizes risks of failure.
○​ Managed by a small number of operators for thousands of servers.​
 ●​ Warehouse-Scale Computers:​

○​ Warehouse-scale computers grow from 1000 servers to 100,000 servers based

on demand for SaaS applications.
○​ Economies of scale dramatically reduce costs (3x to 8x savings) for purchasing,
housing, and operating large datacenters.
○​ Traditional datacenters used only 10-20% of their capacity.​

●​ Utility and Public Cloud Computing:​

○​ Cloud computing is often referred to as Utility Computing, providing services at

low cost (pennies per hour).
○​ Offers the illusion of infinite scalability: users can scale resources as needed
without significant cost increases.
○​ Pay for the usage: for example, 1000 computers for 1 hour costs the same as 1
computer for 1000 hours.​

●​ Leading Cloud Providers:​

○​ Major examples of cloud service providers include:​

■​ Amazon Web Services (AWS)​

■​ Google App Engine​

■​ Microsoft Azure​

○​ Amazon runs its e-commerce business on AWS, demonstrating the capabilities of

cloud infrastructure.​

Benefits of Cloud Computing

●​ Scalability: Offers infinite scalability, with users able to adjust resources as needed.
●​ Cost Efficiency: Provides cost-effective solutions by using commodity hardware and
clustering, reducing costs significantly (up to 20x cheaper than traditional setups).
●​ Redundancy & Reliability: Built-in redundancy ensures high reliability with minimal
risk of downtime or failure.
 ●​ On-Demand Access: Users can access resources on an on-demand basis without
worrying about hardware investments.

Legacy software vs beautiful software:

Legacy Software

●​ Legacy Software refers to older software that still meets customer needs but is often
difficult to evolve or maintain due to its design inelegance or the use of outdated
technology.​

●​ Common characteristics:​

○​ Hard to evolve: Difficult to add new functionality or make improvements due to

poor design choices or outdated systems.
○​ Maintenance costs: 60% of software maintenance costs are spent on adding new
features to legacy systems, while 17% goes toward fixing bugs.
○​ Vital, but often ignored in many software engineering courses, making it less
discussed.​
 ○​ Examples: Many large enterprises still rely on legacy systems for critical
operations, even if those systems are no longer efficient or easy to update.​

Beautiful Software

●​ Beautiful Software is elegantly designed, meets customers' needs, and is easy to

evolve and maintain.​

●​ Common characteristics:​

○​ Tested and validated: Beautiful software is verified (tested for functionality) and
validated (in production and meeting real-world needs).
○​ Evolvable: Easy to modify, improve, and extend over time, allowing for
continuous improvement without the need for major rewrites.
○​ Designed with clean code principles, following best practices for software
design, structure, and readability.​

Sam’s Rule of Beautiful & Legacy Software

●​ Verified (Tested) + Validated (Production) = Beautiful x 2: For software to be

considered beautiful, it must be both well-tested and validated in real-world production
environments.
●​ Rewriting Legacy Software: Successfully rewriting legacy code and applications is
always more difficult than anticipated. The challenge lies in the complexity of
preserving existing functionality while integrating new improvements.​

Alternatives to Rewriting Legacy Software

●​ Service-Oriented Architecture (SOA) and Component-Based Architectures can be

used to gradually refactor legacy code.​

○​ Focus on decoupling the user interface (UI) and business logic from legacy
systems.
 ○​ Gradually replace or modernize the business logic and other parts of the code as
needed without completely rewriting the entire system.​

Summary of Key Differences

Aspect Legacy Software Beautiful Software

Design Inelegant, outdated Elegant, modern

Ease of Evolution Difficult to evolve and maintain Easy to modify and extend

Maintenance High (60% for new features, 17% Low (efficiency and scalability)
Cost for bugs)

Focus Meets customer needs, but hard to Meets customer needs and is
update flexible

Development Maintenance and patching Continuous improvement and

Focus innovation

Rewrite Extremely difficult and costly New features can be added with
Difficulty minimal risk
Software Quality Assurance: Testing

Software Quality Assurance (QA)

●​ Software Quality Assurance (QA) refers to the processes, standards, and activities that
ensure the quality of the software product and its development lifecycle.​

○​ Goal: Improve the quality of the product and ensure that it meets customer needs
and requirements.
○​ Key Focus Areas:​

■​ Verification: Ensuring the software is built correctly, based on the

specifications.
■​ Validation: Ensuring the software is the right product, meeting the
customer's real needs and expectations.​

●​ Software Quality:​

○​ Defined as the fitness for use, meaning the product must meet business needs, be
easy to use, get correct results, and remain stable without crashing.
○​ Software Quality Assurance aims to:​

■​ Ensure products meet customer needs (easy to use, reliable, and correct).
■​ Make it easy for developers to debug, maintain, and enhance the software.​

●​ Key Aspects of Software QA:​

○​ Ensures adherence to processes and standards to produce high-quality products.

○​ Focuses on both product quality (meeting customer needs) and process quality
(improving development practices).​

Testing in Software Quality

●​ Testing is a critical part of the software development lifecycle, ensuring that the software
functions as expected and meets the specified requirements. Since exhaustive testing is
 often impractical, testing is performed at different stages to optimize coverage.​

Types of Testing:

1.​ Unit Testing:​

○​ Focuses on testing individual procedures or functions, typically implemented by a

single developer.
○​ Ensures that each part of the code works as expected in isolation.​

2.​ Module Testing:​

○​ Tests a feature across multiple procedures or classes, typically handled by the

development team.
○​ Ensures integration between related components of the software.​

3.​ Integration Testing:​

○​ Focuses on testing the interaction of multiple features, often across different

environments and development teams.
○​ Ensures that various parts of the system work together as expected.​

4.​ System Testing:​

○​ Involves testing the full system in an environment that simulates production.

○​ Ensures that the entire system functions as expected when all components are
integrated.​

5.​ Acceptance Testing:​

○​ Validates the full system against business requirements.

○​ Ensures the software meets customer needs and is ready for deployment.​

Other Important Types of Testing

●​ Automated Testing:​

○​ Uses scripting tools to automate the process of testing software functionality.

 ○​ Increases efficiency and repeatability, especially for regression testing.​

●​ Performance Testing:​

○​ Tests how the software performs under high volume or resource-constrained

environments.
○​ Ensures that the software can handle the expected load and scale effectively.​

Summary of Key Concepts

Aspect Software Quality Assurance Testing

(QA)

Objective Ensure high-quality software and Validate the functionality and reliability
improve processes of the software

Focus Product meets customer needs; Conduct tests at various stages (unit,
easy to debug and enhance integration, system, etc.)

Verification Did we build the thing right Ensures correct implementation and
(based on specifications)? behavior of individual components

Validation Did we build the right thing Ensures the software meets real-world
(based on customer needs)? business and user needs

Types of N/A Unit, Module, Integration, System,

Testing Acceptance, Automated, Performance
Productivity: Conciseness, Synthesis, Reuse and Tools

Productivity

●​ Productivity in software development refers to how efficiently software is created and

delivered while maintaining quality.​

○​ Over the decades, Moore's Law has driven hardware advancements, increasing
performance by doubling processor speeds and memory capacities approximately
every 18 months.
○​ As hardware improved, software designs grew larger and more complex,
necessitating innovations to boost software productivity.
○​ Techniques to improve software productivity include:​

1.​ Conciseness to improve clarity and reduce complexity.​

2.​ Synthesis, which generates code automatically to save time.​

3.​ Reuse of existing code to avoid redundant development.​

4.​ Tools and automation to speed up repetitive tasks.​

Conciseness

●​ Conciseness in software refers to the ability to express functionality more simply,

reducing unnecessary complexity and improving readability.​

○​ Syntax: Writing code in shorter, more readable forms.​

■​ Example: assert_greater_than_or_equal_to(a, 7) vs.

a.should be ≥ 7
■​ Example: Time.now - 2*60*60 vs. 2.hours.ago​
 ○​ Higher-level abstractions:​

■​ Using high-level programming languages instead of low-level ones like

assembly language.
■​ Features like automatic memory management (e.g., Java vs. C).
■​ Reflection and metaprogramming in dynamic languages to reduce
boilerplate code and improve flexibility.​

Synthesis: Code that Writes Code

●​ Synthesis refers to tools or techniques that automatically generate code based on

certain inputs, reducing manual coding effort.​

○​ Common tools:​

■​ Templating engines and code generators (e.g., Ruby on Rails

scaffolding) generate repetitive code structures.​

○​ Research Stage: Programming by example, where systems learn from

user-provided examples to generate the necessary code.​

■​ Example: Excel 2013 Flash Fill, which learns patterns from user input to
automatically fill in the data.​

Reuse

●​ Reuse focuses on leveraging existing code to minimize the need for developing new
solutions, improving efficiency and maintainability.​

○​ Types of Reuse:​

1.​ Procedures and functions: Reuse simple functions or methods that

perform common tasks.​
 2.​ Standardized libraries: Reuse pre-built libraries to handle single tasks
(e.g., logging, authentication).​

3.​ Object-Oriented Programming (OOP): Reuse objects or classes to

manage and reuse collections of tasks.​

4.​ Design patterns: Reuse general strategies for solving problems, even if
the implementation varies.​

Don’t Repeat Yourself (DRY)

●​ DRY (Don’t Repeat Yourself) is a principle aimed at reducing redundancy in code.​

○​ The key idea is that every piece of knowledge in a system should have one,
unambiguous, authoritative representation.
○​ Refactoring code to extract commonalities helps in avoiding repetitive code,
making it easier to maintain and extend.​

Tools and Automation

●​ Tools and Automation in software development help replace repetitive manual tasks
with automated systems that improve efficiency and accuracy.​

○​ Examples:​

■​ Automated testing tools (e.g., Cucumber, RSpec) to quickly validate

code behavior.
■​ Build tools (e.g., Make, Maven) to automate compiling, testing, and
deployment.
■​ Scriptable infrastructure: Cloud computing allows for automated
hardware configuration, making it easier to scale systems.
 ○​ The key is ensuring that the learning curve of new tools is worth the
productivity gain they provide.​

Agile and Higher Productivity

●​ Agile methodology emphasizes iterative development and continuous customer

feedback, resulting in faster delivery and higher productivity.​

○​ How Agile leads to higher productivity:​

■​ Continuous feedback ensures fewer wasted efforts on features customers

don’t want.
■​ Faster defect detection (validation and verification defects) reduces
rework and keeps the project on track.
■​ Lightweight process: Agile's simpler, less bureaucratic structure reduces
time spent in meetings.
■​ Test-driven development (TDD) results in more thorough tests, finding
bugs faster and reducing costly fixes later in the process.
■​ Higher-level tools in Agile practices allow developers to focus on solving
problems, rather than managing low-level technical details.

Fallacies and Pitfalls

Fallacy: The Agile lifecycle is best for software development

◦ Good match for some software, especially SaaS

◦ But not for NASA, code subject to regulations

Per topic, will practice Agile way to learn but will also see Plan and Document perspective

◦ Note: you will see new lifecycles in response to new opportunities in your career, so expect to
learn new

ones
Waterfall vs Iterative vs Agile

Agile is more difficult when a software development project requires:

◦ Large teams

◦ Fixed bid proposals and/or outsourcing

◦ Significant regulation (i.e. HIPPA, Sarbanes-Oxley, etc.)

However, with software development lifecycle improvements like Scaled Agile (SAFe) it is
often still viable/beneficial to choose Agile over Iterative or Waterfall.

SaaS less hassle for developers and users

Service Oriented Architecture makes it easy to reuse current code to create new apps

Scale led to savings/CPU => reduced cost of Cloud Computing => Utility Computing

Testing to assure software quality, which means good for customer and developer

Developer Productivity: Conciseness, Synthesis, Reuse, and Tools

Agile

●​ Agile is a software development methodology that promotes iterative development,

continuous customer feedback, and adaptability to change.​

●​ Based on the Agile Manifesto (2001), it 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​

Scrum

●​ Scrum is the most common framework used to implement Agile.

●​ It organizes work into small, manageable iterations called Sprints, typically lasting 1–3
weeks.
●​ Scrum includes several rituals (practices) that help teams stay aligned and improve
continuously:​

○​ Sprints: Fixed-length iterations during which work is completed.

○​ Backlogs:​

■​ Product Backlog: A prioritized list of features or user stories.​

■​ Sprint Backlog: A subset of the product backlog chosen for a sprint.​

○​ User Stories: Short descriptions of a feature from the end-user perspective.

○​ Sprint Planning: A meeting where the team decides which stories to tackle in the
sprint.​

○​ Daily Standups: Short daily meetings to share progress, blockers, and plans.
○​ Continuous Improvement: Ongoing effort to enhance team processes and
outcomes.
○​ Retrospectives: Meetings at the end of each sprint to reflect and identify
improvements.​
Scaled Agile Framework (SAFe)

●​ SAFe (Scaled Agile Framework) is a methodology designed to scale Scrum and Agile
practices across large organizations and complex projects.
●​ It provides structure to coordinate multiple Agile teams, align goals, and ensure
continuous delivery across the organization.

XP & Agile:

Extreme Programming (often referred to as simply “XP”) has become a common term that
describes Agile engineering practices including:

▪ Test-driven development (TDD)

▪ Continuous integration (CI)

▪ Coding standards

▪ Pair programming
 Slide set 2:

The Web as a Client-Server System

●​ The Web is based on a client-server architecture, which is a fundamental architectural

design pattern.
●​ It is request/reply oriented:​

○​ A client (e.g., a web browser) sends a request.

○​ A server (e.g., a website) receives the request and sends back a response.​

Roles of Client and Server

●​ Client:​

○​ Typically a web browser.

○​ Initiates communication by asking questions or requesting services on behalf of
the user.​

●​ Server:​

○​ Hosts and manages resources like web pages or APIs.

○​ Waits for requests and responds to multiple clients efficiently.​

Supporting Systems

●​ Domain Name System (DNS):​

○​ A special kind of server that maps human-readable names (like

example.com) to IP addresses.
○​ Essential for allowing clients to locate servers on the Internet.​
 Comparison: Client-Server vs. Peer-to-Peer

●​ Client-Server:​

○​ Centralized: servers provide services, clients consume them.

○​ Scalable and controlled but can have single points of failure.​

●​ Peer-to-Peer (P2P):​

○​ Each participant acts as both a client and a server.

○​ More decentralized and robust, but harder to control and secure.​

Design Patterns

●​ Client-Server is an example of a design pattern:​

○​ A reusable solution to a common architectural problem.

○​ Promotes specialization, scalability, and maintainability.​
 Nuts and Bolts of Web Communication: TCP/IP and HTTP

IP (Internet Protocol)

●​ An IP address identifies a physical device on a network.

●​ Format: Four octets, e.g., 128.32.244.172.
●​ Special address 127.0.0.1:
○​ Represents "localhost" — the current computer.
○​ Used for testing and internal communications, even without internet access.
●​ IP provides a best-effort, no-guarantee delivery of packets.​

TCP (Transmission Control Protocol)

●​ Built on top of IP to ensure reliable communication:

○​ Detects dropped packets, out-of-order delivery, errors, and network slowness.
○​ Automatically retransmits or rearranges data.
●​ Uses TCP ports to support multiple concurrent applications (e.g., browser + email on
same machine).​

HTTP (Hypertext Transfer Protocol)

●​ An ASCII-based request/reply protocol for exchanging data over the Web.

●​ Follows a stateless communication model:​

○​ Each request is independent of others.

○​ Efficient, scalable, and simple.
○​ But makes multi-step processes harder (e.g., shopping carts, logins).​

HTTP Request includes:

●​ Request method: GET, POST, etc.

●​ URI (Uniform Resource Identifier)
●​ HTTP version
●​ Headers: additional metadata (e.g., cookies, user agent)​

HTTP Response includes:

●​ HTTP version and status code

●​ Headers
●​ Body (e.g., HTML, JSON)​

HTTP Status Codes:

●​ 2xx: Success (200 OK)

●​ 3xx: Redirection (301 Moved Permanently)
●​ 4xx: Client error (404 Not Found)
●​ 5xx: Server error (500 Internal Server Error)​

Cookies

●​ HTTP is stateless, so cookies were introduced to preserve per-user state across requests.
●​ Cookies store small amounts of data on the client and are sent with every request.
●​ Handled automatically by frameworks like Rails using tamper-evident techniques.​

Uses of Cookies:

●​ Customization (e.g., "My Yahoo")

●​ Click/flow tracking
●​ Authentication (e.g., logged-in sessions)​

Early solutions before cookies (flawed):

●​ Identify users by IP address: failed on shared/public computers.

●​ Use URI query strings: broke caching and scalability.
 10,000 Feet: HTML and CSS

Hypertext Markup Language (HTML)

●​ HTML is the standard language used to structure content on the Web.

●​ A document is a hierarchy of elements, organized like a tree.

Types of HTML Elements:

●​ Inline content: headings, tables, lists, paragraphs, etc.

●​ Embedded content: images, videos, JavaScript, etc.
●​ Forms: allow user input via text fields, radio buttons, checkboxes, dropdowns, etc.

Element Syntax:

●​ Elements are enclosed by opening and closing tags:

○​ With content: <p>Hello world</p>
○​ With attributes: <img src="http://...">
●​ Common attributes:
○​ id: uniquely identifies an element within a page.
○​ class: allows grouping elements with shared styles.

Cascading Style Sheets (CSS)

●​ CSS is used to separate content from presentation, enabling cleaner HTML and
centralized styling.​

How CSS is Included:

Typically linked in the <head> of an HTML document:​
<link rel="stylesheet" href="http://..."/>

CSS Selectors:
 ●​ Used to apply styles to specific HTML elements.​
Examples:​

○​ By tag name: h1
○​ By class: .pageFrame
○​ By id: #pageHead
○​ Combined: div.pageFrame, img#welcome
○​ Descendant: div .custName (any .custName inside a div)​

Rules:

●​ IDs must be unique per page.

●​ Classes can be shared by multiple elements.
●​ Attributes have browser-defined defaults unless overridden by CSS.

Best Practices:

●​ Avoid putting visual styling directly into HTML.

●​ Let CSS handle all presentation, keeping HTML semantic and maintainable.

5,000 Feet : 3-Tier Architecture and Horizontal Scaling:

We will be focusing on the JavaScript / Express / Node.js combination with the possible addition
of Bootstrap and TypeScript. The cloud hosting service used is Microsoft Azure.

Web 1.0 SaaS (Software as a Service) – Sites That Are Really Programs

SaaS websites are web applications that run server-side programs in response to user
requests, rather than just serving static content.

Key Challenges of SaaS and How They're Addressed

To turn a website into a functional program, a SaaS app must:

●​ Map URI to program/function​

– Determine which backend code to run based on the request's URL.
●​ Pass arguments​
– Use HTTP methods (GET, POST) to send input from the browser to the server.
●​ Invoke the correct program​
– The web server executes application logic through backend frameworks.
●​ Handle persistent storage​
– Use databases (like SQLite, MySQL, PostgreSQL) to store user data.
●​ Handle cookies​
– Enable user sessions, tracking, and personalization through browser-stored cookies.
●​ Handle errors​
– Catch and manage application and request errors to maintain good UX and debugging.
●​ Package output for the user​
– Send dynamically generated HTML/CSS/JS back to the browser.​

Frameworks Simplify SaaS Development

●​ Frameworks like Ruby on Rails automate and abstract common SaaS tasks using:​

○​ Rack (middleware)
○​ Adapters for databases (e.g., SQLite, MySQL)
○​ Webrick/Thin servers for local or light deployment
○​ Apache with mod_rails for production​

Deployment Environments

1.​ Developer Environment​

○​ Local server (Webrick or Thin)

○​ SQLite or MySQL for data
○​ Uses Rails and Rack for routing and processing​

2.​ Medium-Scale Deployment​

 ○​ Apache or Thin server with mod_rails
○​ MySQL with file caching​

3.​ Large-Scale Deployment (e.g., Heroku)​

○​ Multiple app servers ("Dynos")

○​ PostgreSQL
○​ Distributed HTTP servers and static caches​

Data Scaling Strategies

●​ Sharding:​

○​ Data is split across different servers based on criteria (e.g., users A–J, K–R).
○​ Pros: Highly scalable.
○​ Cons: Complex for operations involving multiple shards.​

●​ Replication:​

○​ All data is copied to multiple servers.

○​ Pros: Faster queries across multiple tables.
○​ Cons: Write operations are slower and risk temporary inconsistency.​
Summary

●​ SaaS turns websites into interactive programs.​

●​ Relies on client-server model, HTTP, HTML/CSS, and cookies for session handling.​

●​ Frameworks (like Rails) and deployment strategies abstract the complexity.​

●​ Scalability is managed via sharding or replication, depending on use case.

Browser requests web resource (URI) using HTTP

◦ HTTP is a simple request-reply protocol that relies on TCP/IP

◦ In SaaS, most URI's cause a program to be run, rather than a static file to be fetched

HTML is used to encode content, CSS to style it visually

Cookies allow server to track client

◦ Browser automatically passes cookie to server on each request

 ◦ Server may change cookie on each response

◦ Typical usage: cookie includes a handle to server-side information

◦ That's why some sites don't work if cookies are completely disabled

Frameworks make all these abstractions convenient for programmers to use, without sweating

the details

1,000 Feet: Model-View-Controller

MVC (Model–View–Controller) Design Pattern

●​ A software architecture pattern that separates concerns in web applications.

●​ Aims to separate data management (Model) from UI presentation (View) using a
Controller.
●​ Promotes clarity, maintainability, and scalability.​

Core Components

●​ Model​

○​ Manages data and business logic.

○​ Reads from and writes to a database.
○​ Represents application entities (e.g., Movie, Review, User).​

●​ View​

○​ Handles visual representation and UI.​

 ○​ Displays data passed from the controller.
○​ Contains no business logic—only layout and formatting.​

●​ Controller​

○​ Handles user input and browser requests.

○​ Updates models or retrieves data from models.
○​ Chooses which view to render in response to an action.​

MVC in SaaS and Rails

●​ Rails follows the MVC pattern strictly.

●​ Each app resource has:​

○​ A model (e.g., movie.rb)

○​ A controller (e.g., movies_controller.rb)
○​ Views (e.g., views/movies/show.html.erb)​

Example: Movie Reviews App

●​ Movie → Model
●​ MoviesController → Controller
●​ movies/show.html.erb → View
●​ Structure is repeated for each entity: Moviegoers, Reviews, etc.​
Alternatives to MVC

●​ Page Controller (e.g., Sinatra)​

○​ Each page has its own controller logic.​

○​ Simple, but can become unstructured.​

●​ Front Controller (e.g., J2EE/Servlet)​

○​ One central controller handles all incoming requests.

○​ Centralized routing and logic control.​

●​ Template View (e.g., PHP)​

○​ Logic and presentation mixed in templates.​

Fast to develop but hard to maintain.
500 Feet: Active Records for Models

Active Record (Rails Models)

●​ Represents models (like Movie) as Ruby objects that map to database tables.​

●​ Each model corresponds to one table in the database.​

●​ Each row = one object, and each column = one attribute (e.g., name, rating).​

●​ Every record has a unique ID (primary key).​

CRUD Operations

●​ Models can Create, Read, Update, and Delete themselves.

In-Memory vs. In-Storage

 ●​ In-memory object: Ruby object like #<Movie:0x1295580>.​

●​ In-storage object: Row in database table.​

●​ Active Record converts (serializes/deserializes) between them.​

Rails Models store data in relational databases RDBMS and Schema

●​ Each type of model gets its own database table

◦ All rows in table have identical structure

◦ one row in table == one instance of model's class

◦ Each column stores value of an attribute of the model

◦ Each row has unique value for primary key (by convention, in Rails this is an
integer and is called id)

●​ The schema is the structure of all tables and columns in the database.​

●​ Rails uses schema.rb to track it.​

Alternative: Data Mapper (e.g., in Google App Engine)

●​ Keeps storage mapping logic separate from model.

●​ Associates separate mappers with each model
●​ keep mapping independent of particular data store used => works with more types of
databases​

●​ More flexible with different databases, but:​

○​ Can't take full advantage of relational database features like joins.

500 Feet: Controllers, Routers and RESTfulness

Controllers, Routers, and RESTfulness in Rails

REST (Representational State Transfer)

●​ REST is an architectural style for designing networked applications.

●​ Focuses on resources (not pages or actions) and how they are manipulated using HTTP
methods.
●​ Core Principles:​

○​ Self-contained URIs: URIs identify resources, e.g., /movies/3 for a movie

with ID 3.
○​ Stateless: Each HTTP request contains all necessary information for processing.
○​ Hyperlinks: Responses may include links to discover related resources.​

Example: /movies/3 is a URI that identifies a movie resource, and the HTTP method
determines what action is taken (e.g., GET for retrieving, POST for creating).

Controllers in MVC

●​ Controllers handle user requests, interact with models, and render views.
●​ Each controller action corresponds to a user interaction.​

○​ Action: A Ruby method in the controller that processes the user's request.​

Routers in Rails

●​ Router maps incoming HTTP requests to controller actions.

●​ Defines the relationship between HTTP methods, URIs, and the controller action.
●​ Route syntax in config/routes.rb connects routes to controller actions.​
​
🛠 RESTful Routes
HTTP URI Pattern Controller Action Purpose
Method

GET /movies/ MoviesController# Show details of movie with

3 show ID=3

POST /movies MoviesController# Create a new movie

create

PUT/PATCH /movies/ MoviesController# Update movie with ID=5

5 update

DELETE /movies/ MoviesController# Delete movie with ID=5

5 destroy

Summary of Key Concepts

●​ RESTful Design: Focuses on resources and operations (GET, POST, PUT, DELETE)
using URIs.​

●​ Controllers: Handle incoming requests and manage data interaction.​

●​ Routers: Define mappings between HTTP methods, URIs, and controller actions.​

●​ Rails automatically generates RESTful routes for resources with the resources
method in routes.rb.​

500 Feet: Template Views and Haml

HAML is a markup language used to cleanly and efficiently write HTML code. It serves as a
replacement for traditional HTML syntax.​

HAML simplifies the writing of HTML templates by reducing the amount of boilerplate code
and using indentation instead of closing tags.
Summary: Architecture and Rails

Model-view-controller is a well-known architectural pattern for structuring apps

Rails codifies SaaS app structure as MVC

Views are Haml w/embedded Ruby code, transformed to HTML when sent to browser

Models are stored in tables of a relational database, accessed using ActiveRecord

Controllers tie views and models together via routes and code in controller methods
 Slide set 6:

6.1 Introduction

●​ JavaScript is a core web technology used alongside HTML and CSS to create dynamic,
interactive client-side web applications.
●​ Client-Side Scripting: Runs on the user's browser, enabling dynamic behavior like form
validation, animations, interactive UI, etc.
●​ Interactivity: JavaScript is responsible for making web pages interactive, enabling things
like dropdowns, buttons, and pop-ups.​

6.2 Client-Side JavaScript for Ruby Programmers

●​ Ruby developers can easily transition to JavaScript since both are high-level, interpreted
languages.
●​ Syntax Differences: JavaScript has some syntactic differences compared to Ruby, such
as using var, let, or const for variable declaration, and curly braces {} for blocks
and functions instead of do/end in Ruby.
●​ Dynamic Typing: Like Ruby, JavaScript is dynamically typed, which means variables do
not require explicit type declaration.​

6.3 Functions and Constructors

●​ Functions: JavaScript functions are blocks of code designed to perform a specific task
when called.​

Example:​
​
javascript​
CopyEdit​
function greet(name) {
return "Hello, " + name;
}
greet("Alice"); // Output: Hello, Alice

○​
●​ Constructors: Functions that are used to create objects in JavaScript.​

○​ Objects created using constructors are instances of the constructor's function.​

Example:​
​
javascript​
CopyEdit​
function Person(name, age) {
this.name = name;
this.age = age;
}
let person1 = new Person("John", 25);

○​

6.4 The Document Object Model (DOM) and jQuery

●​ DOM: The DOM represents the HTML structure of a page as a tree of objects, where
each node is an element or attribute in the HTML document.
●​ DOM Manipulation: JavaScript can interact with and manipulate the DOM to
dynamically change the content and structure of a page.​

Example:​
​
javascript​
CopyEdit​
document.getElementById("myElement").innerHTML = "New content!";

○​
 ●​ jQuery: A JavaScript library that simplifies DOM manipulation, AJAX requests, and
event handling.​

○​ Provides easy-to-use methods for common tasks like selecting elements,

adding/removing classes, and handling animations.​

Example:​
​
javascript​
CopyEdit​
$("#myElement").hide();

○​

6.5 Events and Callbacks

●​ Events: Events represent user interactions like clicks, key presses, or mouse movements
that JavaScript can listen for and respond to.​

Example:​
​
javascript​
CopyEdit​
document.getElementById("myButton").onclick = function() {
alert("Button clicked!");
}

○​
●​ Callbacks: Functions passed as arguments to other functions that are executed once a
task is complete.​

○​ Often used in asynchronous programming (e.g., AJAX requests).​

Example:​
​
javascript​
CopyEdit​
function fetchData(callback) {
setTimeout(() => {
console.log("Data fetched");
callback();
}, 1000);
}
fetchData(function() {
console.log("Callback executed!");
});

○​

6.6 AJAX (Asynchronous JavaScript And XML)

●​ AJAX enables web pages to fetch data from a server asynchronously, without reloading
the entire page.
●​ Typically used to create dynamic web applications like single-page apps.​

Example:​
​
javascript​
CopyEdit​
const xhr = new XMLHttpRequest();
xhr.open("GET", "data.json", true);
xhr.onload = function() {
if (xhr.status === 200) {
console.log(xhr.responseText);
}
};
xhr.send();

○​
6.7 Testing JavaScript and AJAX

●​ Testing JavaScript: JavaScript code should be tested to ensure it behaves as expected.​

○​ Tools like Jest, Mocha, or Jasmine are commonly used for unit testing
JavaScript code.
●​
●​ Testing AJAX: Test AJAX requests by mocking server responses using tools like Jest or
Sinon to ensure that AJAX calls are made and handled correctly.​

6.8 Single-Page Apps and JSON APIs

●​ Single-Page Applications (SPA): SPAs load a single HTML page and dynamically
update content as the user interacts with the app, using AJAX to request data.
●​ JSON APIs: SPAs typically communicate with the server via JSON APIs, fetching data
asynchronously and updating the page without full reloads.​

Example of a fetch request for JSON:​

​
javascript​
CopyEdit​
fetch('https://api.example.com/data')
.then(response => response.json())
.then(data => console.log(data));

○​

6.9 Fallacies and Pitfalls

●​ JavaScript Pitfalls:​

○​ Global Variables: Too many global variables can lead to naming conflicts and
unexpected behavior.
○​ Asynchronous Issues: Managing asynchronous code with callbacks or promises
can be challenging.
 ○​ Type Coercion: JavaScript can automatically convert types, which may lead to
unexpected results (e.g., "5" - 2 results in 3).​

●​ Best Practices:​

○​ Use let and const instead of var to limit scope and avoid unintended global
variables.
○​ Handle asynchronous operations carefully using Promises or async/await.​

6.10 Concluding Remarks

●​ JavaScript is a powerful and essential language for developing dynamic client-side web
applications.
●​ Mastery of concepts like the DOM, AJAX, events, and callback functions is crucial for
building interactive web pages.
●​ Best practices like modularization, asynchronous handling, and testing are important for
writing clean, maintainable JavaScript code.
 Slide set 7: Behavioral driven design and user stories

Definition: Behavior-Driven Development (BDD)

Behavior-Driven Development (BDD) is an Agile software development process that builds on

Test-Driven Development (TDD), aiming to improve communication between developers,
testers, and non-technical stakeholders. It uses natural language descriptions of system
behavior to drive development, making it easier for all participants to understand and agree on
how the application should function.

Key Characteristics of BDD

●​ Derived from TDD:​

BDD uses TDD principles but focuses on the behavior of the system from the user's
perspective.​

●​ Collaboration-Focused:​
Encourages active collaboration among developers, QA engineers, and business
stakeholders.​

●​ Natural Language Specifications:​

Uses English-like language (e.g., Gherkin syntax - Given/When/Then) to describe
behavior in a way everyone can understand.​

●​ Executable Specifications:​
These behavior descriptions double as automated tests, ensuring the system behaves as
expected.

Key Concepts to Understand

User Stories

●​ Definition: Short, simple descriptions of a feature told from the perspective of the user.​

●​ Format:​
"As a [type of user], I want [some goal] so that [some
 reason]."​

7.2 Points, Velocity, and Pivotal Tracker

●​ Story Points:​
A unit of measure for expressing the effort required to implement a user story (not
time-based).​

●​ Velocity:​
The number of story points a team can complete in a sprint; used for capacity planning.​

●​ Pivotal Tracker:​
A project management tool used to:​

○​ Plan sprints based on velocity​

○​ Track story progress​

○​ Prioritize tasks using story points​

7.3 SMART User Stories

SMART stands for:

●​ Specific – Clear and precise description of the requirement​

●​ Measurable – Success criteria must be defined​

●​ Achievable – Realistic with current team and resources​

●​ Relevant – Directly tied to business or user value​

●​ Time-boxed – Can be completed within a sprint​

Final Thoughts & Best Practices

1.​ Story Points vs Use Case Points vs Function Points:​

○​ Story Points are Agile-specific and relative.​

○​ Use Case Points and Function Points are more traditional sizing techniques
(used in Waterfall or early project estimation).​

Story Points

●​ Used by Agile teams.​

●​ Measures how hard a task is (effort, complexity, risk).​

●​ Not exact time—just a relative size (like saying “this task is twice as hard as that one”).​

●​ Helps with sprint planning and tracking team speed.​

Use Case Points

●​ Used in traditional software planning.​

●​ Based on use cases (scenarios of how users interact with the system).​

●​ Counts how many actors and actions there are, and how complex they are.​

●​ Gives a more structured estimate than story points.​

Function Points

○​ Focuses on what the system does: inputs, outputs, data it uses.​

○​ Often used in big organizations or contracts.​

 ○​ Measures the size of the software, not effort.​

○​ Good for comparing different systems or tracking costs.

2.​ SMART Stories improve clarity and effectiveness, ensuring that teams understand
what’s being asked and how to deliver it.​

3.​ Be careful measuring productivity across teams:​

○​ Teams estimate differently.​

○​ Comparing story points between teams is often inaccurate and misleading.​

4.​ User Experience (UX) is crucial:​

○​ Often overlooked in technical implementations.​

○​ Should be considered early in the design and planning process to maximize user
satisfaction.
 Slide set 8:

Test-Driven Development (TDD) Overview

Definition:

Test-Driven Development (TDD) is a software development approach where you write tests
before writing the code that fulfills those tests. The cycle follows three key phases:

1.​ Red: Write a failing test for a new feature or functionality.​

2.​ Green: Implement just enough code to pass the test.​

3.​ Refactor: Improve the design of the code without changing its functionality while
ensuring it still passes the test.​

TDD helps ensure that the software works as expected, and provides a foundation for easy
refactoring and ongoing development.

8.1 Verification and Validation

●​ Verification: Ensures the software was built according to the specifications and is
functioning as expected.
●​ Validation: Ensures that the software meets the user's or customer's needs.​

The Cost of Fixing a Defect Increases Exponentially:

●​ Early detection of defects is significantly cheaper than fixing defects later in the
development lifecycle. The further a defect goes without being discovered, the more
expensive and time-consuming it becomes to resolve.​

The Righteous Triangle of Software Development

The triangle represents the three key components of successful software development:
 1.​ People & Organizations: Focus on collaboration, roles, and organizational culture.​

2.​ Process & Roles: Clear and efficient processes, methodologies, and role definitions.​

3.​ Technology & Tools: The tools and technologies used to develop and test the software.​

Balance across these three components is critical for achieving high-quality software.

Software Testing

●​ Goal: The objective of testing should not just be "better testing," but rather avoiding
defects in the first place. Once defects occur, it’s important to identify and fix them as
quickly as possible.​

●​ Developers’ Responsibility: Developers must be responsible for ensuring the technical

quality of the product, which means ensuring that testing is integrated into the
development process, not treated as a separate or secondary concern.​
8.2 FIRST, TDD, and Red-Green-Refactor

●​ FIRST Principles: These principles guide TDD practices to ensure that tests are
effective:​

1.​ Fast: Tests should be fast to run, allowing for quick feedback.​

2.​ Isolated: Tests should be independent of each other, allowing for pinpointing
defects.​

3.​ Repeatable: Tests should produce consistent results when run repeatedly.​

4.​ Self-Validating: Tests should provide clear pass/fail results.​

5.​ Timely: Tests should be written as the code is being developed.​

●​ Red-Green-Refactor Cycle:​

1.​ Red: Write a test that fails (as the feature or functionality isn't implemented yet).​

2.​ Green: Write the minimum code to make the test pass.​

3.​ Refactor: Clean up the code while keeping the test passing.​

8.3 Seams, Doubles, and the Code You Wish You Had

●​ Seams: Points in your code where you can modify or replace functionality, often used for
testing purposes.
●​ Doubles: Test doubles are objects that stand in for real objects during testing (e.g.,
mocks, stubs).​

The goal is to design your code to have "seams" where testing and modification are easy. It helps
in isolating parts of the system to make testing more manageable.
8.4 Expectations, Mocks, Stubs, and Example Setup & Teardown

●​ Expectations: Describes how an object should behave during a test (e.g., method calls).
●​ Mocks: Simulated objects that mimic real objects in tests, often used to verify if certain
methods were called.
●​ Stubs: Pre-programmed responses to method calls, often used to control a particular
scenario during testing.​

Setup & Teardown: Preparing the test environment before each test and cleaning it up afterward
to maintain consistency.

8.5 Fixtures and Factories

●​ Fixtures: Predefined data that is loaded into the test environment before running the
tests. It helps in creating a consistent starting state for tests.
●​ Factories: Functions or methods that generate test data dynamically, often used to create
different variations of test objects.​

8.6 Implicit Requirements and Stubbing the Internet

●​ Implicit Requirements: Assumptions that are made during development but may not be
explicitly documented. These assumptions should be validated through testing.
●​ Stubbing the Internet: Using mock objects or services to simulate interactions with
external systems, like web services or APIs, during tests.​

8.7 Coverage Concepts and Unit vs. Integration Testing

●​ Coverage: Measures how much of the code is tested by the tests. It helps identify
untested parts of the codebase.​

○​ Unit Testing: Focuses on testing individual units of code (functions, methods) in

isolation.
 ○​ Integration Testing: Focuses on testing how various units or components interact
with each other.​

Both testing types are important, as unit tests ensure the functionality of individual pieces, and
integration tests ensure that those pieces work together.

8.8 Other Testing Approaches and Terminology

●​ Static Analysis: Analyzing code for potential issues without executing it.​

●​ End-to-End Testing: Testing the entire application flow, from user input to final output.​

●​ Performance Testing: Testing how well the system performs under load or stress.​

Other terms include mock testing, regression testing, and exploratory testing.

8.9 The Plan-and-Document Perspective

●​ This approach emphasizes detailed upfront planning and documentation of tests, which
can sometimes create a disconnect between developers and the actual needs of the
system.​

In contrast to TDD, this approach tends to create more rigid test plans and can sometimes result
in tests that aren't as relevant or adaptable.

Final Thoughts:

1.​ Web Services and APIs:​

○​ Web services and APIs should be tested for both functionality and reliability.
Mocking and stubbing techniques are commonly used for testing APIs.
2.​ Test Data:​
 ○​ Use consistent test data to ensure your tests are repeatable and reliable.​

3.​ Automated Testing & False Positives:​

○​ Automated tests can be a time-saver, but false positives can still occur. It’s
crucial to make sure the test environment is set up correctly.
4.​ Logging:​

○​ Proper logging during testing helps to capture the necessary information for
debugging failed tests.​

5.​ Internal Testing and Test Cases as Product Documentation:​

○​ Well-written tests serve as a form of documentation for the system's expected

behavior and should be treated as part of the product.
6.​ TDD as a Spectrum:​

○​ TDD is not a rigid methodology, but rather a spectrum. It can evolve depending
on the project and the team, adapting to the development flow as needed.
 Slide set : Software Maintenance and Support

Software maintenance includes:

-​ Software enhancements including planning, estimating and prioritizing

-​ Re-engineering or refactoring
-​ Testing
-​ Redeployment

Software Maintenance: Definition and Key Components

Definition:

Software maintenance is the process of modifying and updating software applications after
delivery to correct faults, improve performance or other attributes, or adapt to a changed
environment. It ensures that software continues to meet user needs and performs efficiently over
time.

Key Components of Software Maintenance

1. Software Enhancements

●​ What it means: Adding new features or improving existing ones based on user feedback,
market demands, or business needs.​

●​ Activities involved:​

○​ Planning: Identify enhancement goals and align them with business objectives.
○​ Estimating: Evaluate the time, resources, and cost required to implement
enhancements.
○​ Prioritizing: Rank tasks based on importance, urgency, and impact.​

2. Re-engineering or Refactoring

●​ Re-engineering: Analyzing and modifying existing software to improve its functionality,

maintainability, or scalability.
○​ May involve changing architecture, rewriting code, or migrating platforms.
●​ Refactoring: Restructuring existing code without changing its external behavior.
 ○​ Aimed at improving readability, reducing complexity, and enhancing code
maintainability.​

3. Testing

●​ Purpose: Ensure that modifications don’t break existing functionality and meet the new
requirements.​

●​ Types of testing used in maintenance:​

○​ Regression Testing: Verifies that existing functionality still works after changes.
○​ Unit and Integration Testing: Confirms that individual components and their
interactions behave as expected.
○​ User Acceptance Testing (UAT): Ensures changes meet user needs before
deployment.​

4. Redeployment

●​ What it involves: Delivering the updated software to the production environment.

●​ Tasks include:​

○​ Packaging and building the application

○​ Rolling out updates with minimal downtime
○​ Ensuring compatibility with the existing environment
○​ Monitoring for post-deployment issues​

Summary

Software maintenance is a continuous process crucial for extending the life of a software
product. It involves:

●​ Enhancing functionality,
●​ Re-engineering for performance and scalability,
●​ Rigorously testing for quality assurance,
●​ Redeploying updates efficiently.​
Each component plays a vital role in maintaining reliable, scalable, and user-friendly
software.

Software Support includes:

-​ Responding to end-user questions and issues

-​ Coordinating responses across applications
-​ Tracking and escalating issues

Software Support – Definition and Key Activities

Definition:

Software support refers to the set of services provided to help end-users effectively use software
and resolve any problems they encounter. It ensures smooth operation and satisfaction by
addressing user questions, fixing issues, and coordinating across systems when necessary.

Key Components of Software Support

1. Responding to End-User Questions and Issues

●​ Provides assistance for users encountering bugs, confusion, or difficulties.

●​ Can include:​

○​ Answering usage questions.

○​ Troubleshooting software errors.
○​ Guiding users through features or processes.​

●​ Often handled via helpdesk, email, live chat, or ticketing systems.​

2. Coordinating Responses Across Applications

●​ Many systems are interconnected; issues may span multiple apps or services.
●​ Support must:​

○​ Work with multiple teams (e.g., frontend/backend).

 ○​ Coordinate fixes that involve several components.
○​ Ensure consistency in communication and resolution.​

3. Tracking and Escalating Issues

●​ Involves monitoring reported problems and ensuring timely resolution.

●​ Tracking: Use tools (like Jira, ServiceNow) to document and manage support tickets.
●​ Escalating:​

○​ When a problem can't be solved at the first level, it's escalated to higher technical
tiers or developers.
○​ Ensures critical or unresolved issues receive appropriate attention.​

Summary

●​ Software support plays a critical role in user satisfaction and system reliability.
●​ Includes:​

○​ Answering and resolving user issues.

○​ Coordinating multi-app responses.
○​ Tracking and escalating to ensure nothing falls through the cracks.​

●​ Effective support improves product trust, reduces downtime, and feeds insights back into
development.

Software Maintenance and Support in Waterfall vs. Agile

1. Waterfall Model

●​ Sequential approach: Development is done in distinct, linear phases (e.g., Requirements

→ Design → Implementation → Testing → Deployment → Maintenance).
●​ Maintenance phase comes after deployment, often as a separate and long-term effort.
(at the end)​
Maintenance

●​ Begins after full system delivery.

●​ Planned and budgeted as a post-project phase.
●​ Includes:​

○​ Enhancements
○​ Bug fixes
○​ Re-engineering
○​ Redeployment​

Support

●​ Separate support teams handle post-deployment issues.

●​ User feedback is slow to incorporate (long release cycles).
●​ Changes usually require going through formal change request processes.​

Video notes:

-​ Occurs only at the end of the project when it is deployed to production

-​ Is managed, staffed, and funded by a separate project, organization and process
-​ Separated into multiple tiers often including customer support (tier-1), escalated support
(tier-2) and application coding support (tier-3)
-​ Significant ongoing enhancement are often managed, staffed and funded separately

RUP is similar to waterfall

2. Agile Model

●​ Iterative and incremental development with frequent delivery (e.g., every 2–4 weeks).
●​ Maintenance and support are integrated into ongoing development cycles.​

Maintenance

●​ Treated as part of continuous improvement.

●​ Performed during sprints—bugs, refactoring, and enhancements can be planned into
upcoming iterations.
 ●​ Easier to adapt to changing needs quickly.​

Support

●​ Involves developers more directly.

●​ Faster response to user issues due to short feedback loops.
●​ Bugs and feature requests often go into the product backlog, prioritized and handled in
upcoming sprints.​

Video notes:

-​ Occurs after the first release

-​ Is initially managed, staffed and funded by the same project, organization and process
-​ Separated into multiple tiers if/when support becomes too large for the team
-​ In full production often includes customer support (tier-1), escalated support (tier-2) and
application coding support (tier-3)
-​ The size of the agile team is scaled to handle support (tier-1), escalated support (tier-2)
and ongoing enhancements are often managed, staffed and funded separately.

🔄 Comparison Table
Feature Waterfall Agile

Approach Linear & phase-based Iterative & continuous

When Maintenance Happens After full deployment Continuously during development

Support Handling By separate teams Often handled directly by dev team

User Feedback Integration Slow, formal Fast, integrated into sprints

Bug Fixes Post-project phase Within iterations

Enhancements Formal change process Added to backlog and reprioritized

Adaptability Low High

 Slide set : Java Testing

The cost grows exponentially when fixing errors in the further testing.

Important testing terms include:

-​ Unit testing: developer testing their own code

-​ Integration testing: development teams testing a full system or systems
-​ System testing: Multiple development teams testing a full system or systems
-​ Performance testing: testing performance at the unit, integration and or system level
-​ Manual testing: A person using the application often running test scenarios
-​ Automated testing: a group of automated tests that run on the application in the unit,
integration,system or performance testing areas.
-​ UI automated testing attempts to exercise the application be reproducing user events
(key n mouse events)
-​ API automated testing occurs at the function/ method API level (Junit for example)

Testing Terms:

-​ Behavioral testing: verifying that the correct functions were called with the correct
parameters
-​ State testing: focuses on the results of those calls

Automated Testing:

Pros:

-​ Repeated tests that are quick to run and can support iterative and agile development
-​ Very effective in validating environments and doing smoke tests to make sure a new build
meets a minimal set of requirements
-​ Supports performance testing very effectively
-​ Finds range defects
-​ Very inexpensive and quick to repeat testing and validate fixes
-​ Various implications include UI,API and unit automation tests

-​ Smoke testing is a type of software testing that verifies whether the basic and critical
functionalities of an application work correctly after a new build or deployment. It is
also known as "build verification testing".
Slide set : Engineering metrics