csci 187 midterm one general material from slides

Software Engineering

An engineering discipline focused on specifying, designing, developing, analyzing, and maintaining a software system.

Software Engineering Tasks

Requirements engineering; specification writing and documentation; architecture and design; testing and debugging; deploying, operating, evaluating, refactoring, and evolving; planning, teamwork, and communication; and programming.

Why is Software Engineering important?

Software is everywhere (our lives depend on it) and it is the path to a successful product by decomposing complex problems, organizing processes, improving reliability and productivity, and delivering solutions that support the customer.

Why is Software Engineering challenging?

It requires programming at scale across two dimensions: Size (organizing huge code bases and ensuring many people can collaborate) and Time (building and maintaining software over years or decades).

Role of a Programmer in the Age of AI

Programmers need to articulate what "correct" means to the AI and still work together as one large team to handle the challenge of scale.

Strengths of Coding with AI

Remembers syntax and templates, generates large amounts of code quickly, and helps with debugging and making sense of error messages.

Weaknesses of Coding with AI

Weaker at architecture and system design, violates usability conventions, lacks thoughtfulness of nuanced user needs, and makes its own decisions without guidance.

Four Stages of the Software Development Life Cycle (SDLC)

1. Requirements (What should we build, and for whom?), 2. Design (How should we build it?), 3. Implementation (Build it), 4. Testing (Did we build it right?).

Waterfall Model

A linear, one-way software development lifecycle where each stage (Requirements -> Design -> Implementation -> Testing) is completed sequentially without revisiting previous stages.

Iterative Lifecycle Model

A lifecycle model focused on revising and improving across stages (with bidirectional arrows between Requirements, Design, Implementation, and Testing) rather than a "one and done" approach.

Premise of Agile

The world is too uncertain, so software development must be flexible and responsive to changes.

4 Core Values of the Agile Manifesto

1. Individuals and interactions over processes and tools; 2. Working software over comprehensive documentation; 3. Customer collaboration over contract negotiation; 4. Responding to change over following a plan.

12 Agile Manifesto Principles (Summary)

Satisfy customer via early/continuous delivery; welcome changing requirements even late; deliver working software frequently; business people and devs work together daily; build around motivated individuals and trust them; face-to-face conversation is best; working software is the primary measure of progress; maintain a sustainable constant pace; continuous attention to technical excellence/good design; simplicity (maximizing work not done); self-organizing teams create best architectures/designs; regularly reflect and adjust behavior.

Pros of Agile

Smaller steps make testing easier, good for feature-driven development, great for handling changing requirements, tight-knit team communication, greater productivity/fewer defects, close customer communication, and designed for incremental releases.

Cons of Agile

Less/no documentation, requires sustained customer involvement, difficult when maintaining a large piece of software, contracts/regulations might require formal specifications, harder with distributed teams, and team turnover leads to lost expertise due to lack of documentation.

Characteristics of Best Performing Teams

A shared elevating vision or goal, a commitment to the team, mutual trust, effective communication, and a high level of enjoyment.

Requirements vs. Specifications

Requirements specify WHAT to build from a customer perspective (goals of the system, what not how). Specifications specify HOW/WHAT to build from a developer perspective.

4-Step Requirements Process

1. Interviews (Talk to real users) -> 2. Personas (Who are we building for?) -> 3. Scenarios (What are they trying to do?) -> 4. User Requirements (What the system must do).

Ways to Engage with Customers

Be a user yourself (avoiding bias), talk with users informally (hallway chats), talk with users formally (interviews, surveys, field studies), build low-fidelity prototypes, and launch and get feedback early ("launch and iterate").

Why Client Interviews are Important

To learn domain expertise, understand different user experiences, avoid missing important goals for users who are not like you, validate whether what you think works actually works, and determine if there is a real problem to solve.

Subject Selection for Interviews

Identify the target demographic, ensure all interviewees belong to it, include different roles/situations (e.g., TA, Teacher, Student), and balance across gender, race, age, and geography.

Do's of Designing Interview Questions

Design questions to get them talking and invite conversation, ask for specific stories (e.g., "Walk me through...", "Tell me about a time..."), and focus on the problem.

Don'ts of Designing Interview Questions

Avoid asking leading questions, asking users for solutions/features, asking hypothetical questions, or trying to solve problems during the interview.

Techniques for Conducting Interviews

Make it a conversation (not an interrogation), summarize understanding to check alignment, be the learner (not the expert), be sympathetic/non-judgmental, ask follow-ups, watch body language and inconsistencies, go beyond the product (staying within the design problem), and understand priorities (must-haves vs. nice-to-haves).

Roles in a Two-Interviewer Setup

Primary interviewer asks planned/follow-up questions, stays engaged with the user, and takes some notes. Secondary interviewer takes detailed notes, ensures topic coverage using a topic list, and asks questions if the primary misses something.

What You Should Discover from an Interview

Who the user is (demographic background), their goals, their current workflow, current tools they use, and their current challenges and frustrations.

Behavioral Variables

Important differences in how a user could approach or interact with a task (e.g., adjusting a rubric while grading vs. locking it beforehand). Note: Demographics/roles (like Professor vs. TA) are NOT behavioral variables.

Personas

A descriptive, task-focused "biography" of a fictional user we are primarily designing for, based on field data/interviews. Covers goals, needs, current solutions/frustrations, demographics, tech experience, job description, and activities.

Why We Use Personas (The Elastic User Problem)

Because you cannot please everyone. Without focused personas, you end up designing for an "elastic user" who could be anyone and want anything, resulting in a flawed product.

Scenarios

Concrete, informal descriptions of a particular persona interacting with a system in a work-driven manner along a specific path. Written from the user's point of view (no omniscience), capturing multiple goals without implementation details or UI design decisions (like buttons/dialogs).

Problem Scenario vs. Context Scenario

A Problem Scenario describes the persona working today with existing tools and friction (drawn from interviews). A Context Scenario describes the persona using your envisioned system, written from goals and behavioral variables before any UI is designed.

User Requirements

Statements of what the system should do from the user's perspective without saying how it will do it (synonymous with user needs, NOT features). Written as "Users should be able to...".

Properties of Good User Requirements

Thorough (captures all user goals), describes the "what" not the "how", is action and user-driven ("User should be able to..."), and focuses on one thing only (does not combine multiple requirements).

How and Why to Group User Requirements

Group requirements that share a core goal/task into 3-6 verb-based categories (emphasizing accomplished action) with roughly equal amounts. Grouping organizes requirements, reveals gaps, and defines key features.

Functional Specifications

Define expected inputs, outputs, and behavioral responses of the system, focusing on user capabilities, interactions, and testable boundaries (e.g., "User cannot assign a grade less than 0").

Non-Functional Specifications

Define behavioral qualities of the system such as speed, reliability, security, accessibility, and usability (e.g., "Articles download in 3 seconds or less", "Student data complies with FERPA").

4 Qualities of Good Specifications

1. Testable (verifiable via coded or user test), 2. Clear and Specific (unambiguous; avoids vague words like "fast" or "easy"), 3. One thing only (not combined), 4. Consistent (no contradictions).

Digital Affordances and Conventions

Visual clues and standard design patterns that indicate how an element can be interacted with (e.g., hover color changes, arrows for dropdowns, logos linking home, circles/radio buttons for single selection, squares/checkboxes for multiple selection).

Data Visualization Conventions

Pie charts must sum to 100%, Y-axis should always start at 0, all data on a chart should share the same axes, avoid chart junk, avoid 3D and rainbow color scales, and match visual encodings to the data.

6 Frameworks for UX Design

1. Layout and Structure, 2. Visual Hierarchy, 3. Input & Controls, 4. System Feedback & State, 5. Visual Style, 6. Information.

Layout and Structure (UX Framework)

Uses headers, sidebars, tabs, grids, padding, and grouping to achieve Scannability (users immediately understand how the page is organized and where to go).

Visual Hierarchy (UX Framework)

Uses font weight, size contrast, whitespace, and focal points to achieve Prioritization (the user's eye naturally goes to the primary action first).

Input & Controls (UX Framework)

Uses buttons, input fields, checkboxes, sliders, dropdowns, and toggles to achieve Control (interactive elements are obvious, easy to target, and behave predictably).

System Feedback & State (UX Framework)

Uses hover/active states, loading spinners, progress bars, and success/error toasts to achieve Responsiveness (instantly telling the user what just happened or what is loading).

Visual Style (UX Framework)

Uses color palettes, typography, icon sets, borders, and shadow depth to achieve Readability & Brand (legible text, consistent aesthetics, and clear visual identity).

Information (UX Framework)

Uses button labels, helper text, inline guidance, and empty-state text to achieve Clarity (concise, intuitive, and jargon-free language).

Prototyping & Crazy 8s (8 Sketches in 8 Minutes)

Prototyping creates a low-fidelity mock-up to foster a "bias towards action" and iterate early. "8 Sketches in 8 Minutes" is a rapid ideation technique focusing on quantity over quality by sketching 8 distinct ideas in 8 minutes.

Minimum Viable Product (MVP)

The smallest subset of functionality (requirements) that delivers enough value to a user that they are willing to use the product. It must be a complete end-to-end "vertical slice" (e.g., Build -> Grade -> Export) that is fast to launch today and extensible tomorrow.

Steps to Define an MVP

1. Pick a persona, 2. Separate Needs vs. Wants (Needs first, wants later), 3. Release and iterate (Build -> Measure -> Learn, repeat).

Common MVP Pitfalls

1. Building non-functional parts (like just a wheel/chassis or only account creation) instead of an end-to-end vertical slice; 2. Proposing an alternative solution that doesn't test or lead toward the final vision; 3. Including too many "wants" over "needs" (scope too big).

Software Architecture

The high-level blueprints of a software system describing its components (boxes: computations/data management/services) and connectors (arrows: communication protocols/calls between components).

Abstraction in Software Architecture

Building a high-level representation of reality by ignoring insignificant details, focusing on the most important properties, and considering modularity (separation of concerns) and interconnections.

UML Class Diagrams

Graph-based box-and-arrow diagrams where nodes represent classes (core objects) and arrows point from Child -> Parent to show dependency (who depends on whom).

Inheritance vs. Composition in UML

Inheritance means something is a "type of" another thing (e.g., Bedroom is a type of Room; triangle head at parent). Composition means something is "contained in" another thing (e.g., Mailbox is contained in a House; diamond head at whole). Both point toward the "bigger" parent/whole.

Model-View-Controller (MVC)

An architectural pattern dividing a system into three components: Model (back-end data management and business logic), View (front-end UI presentation), and Controller (middleman handling control flow and mediating between View and Model).

The Golden Rule of MVC

The Model must be independently designed and should NEVER know about, depend on, or call the View or Controller. You should be able to swap out the View and Controller without changing the Model.

Communication Flow in MVC

The View never communicates directly with the Model (it only calls the Controller on user action). The Controller mediates between them and calls both the Model and the View.

Layered (n-tier) Architecture

An architecture where each layer has a specific responsibility, only communicates with neighboring layers, and depends on services directly below it. Provides isolation, modularity, and separation of concerns (MVC is a design example of a 3-tier layered architecture: Presentation, Business Logic, Persistence).

Client-Server Architecture

An architecture focused on physical and network distribution where clients contact servers with requests and servers respond with data/files (e.g., HTML, CSS, images), after which the client renders content and executes JavaScript.

Where Business Logic Belongs (and Litmus Test)

Business logic (rules, calculations, and validations like discounts or inventory checks) belongs in the Model so it lives in one place, is reusable, and can be tested without a UI. Litmus test: "If we replaced the website with a mobile app, would this rule still apply? If yes -> Model."

Class-Responsibility-Collaborator (CRC) Diagram

An architectural design tool and precursor to UML class diagrams that identifies candidate classes, their responsibilities (what each class "does" and "knows"), and their collaborators (other classes needed to complete tasks).

6 Steps of the CRC Activity

1. Underline every noun in MVP user requirements (excluding external users, UI words, and IT terms), 2. Create CRC cards (identify classes vs. single-value attributes), 3. Identify responsibilities ("does" and "knows"), 4. Identify collaborators, 5. Draw connections/arrows to collaborators, 6. Act it out (trace through classes to test user requirements).

How to Assign Responsibilities to the Correct Class in CRC

Ask: "Who owns the data this job needs?" and "Does the job need to see more than one instance of an object?" (e.g., calculating a question's score from marked criteria goes in the Question class, because Question holds all the Criterion objects).