Study guide: Introduction to Software Engineering

📋 Course Outline

1. Software engineering definition
2. Software failures and engineering practices
3. Modeling, problem solving, and knowledge
4. Projects, participants, and roles
5. Systems, models, and work products
6. Notations, methods, and methodologies
7. Development activities and testing

📖 1. Software engineering definition

🔑 Key Concepts & Definitions

• Systematic procedures: Systematic procedures are structured ways of working used to guide large software efforts toward predictable outcomes.
• Engineering applied to software: Engineering applied to software is using disciplined engineering approaches to development, operation, and maintenance.

📝 Essential Points

• IEEE frames software engineering as a systematic, disciplined, quantifiable approach to software development, operation, and maintenance.
• ISO/IEC/IEEE 24765:2017 defines software engineering as engineering applied to software activities.

💡 Memory Hook

Software engineering = engineering for software, done systematically and measurably.

📖 2. Software failures and engineering practices

🔑 Key Concepts & Definitions

• Poor software architecture: Poor software architecture is a structural weakness that can remove redundancy and trigger widespread failure impacts.
• Safety-critical testing: Safety-critical testing is verification intended to prevent failures in software whose errors can cause harm.

📝 Essential Points

• In 2020, a Tokyo Stock Exchange failure halted all trading for a day, the first time in 71 years.
• A 2016 Galaxy Note 7 battery-management flaw caused overheating and fires, leading to a $5 billion loss and a recall of millions.
• Unnecessary avionics complexity on a C-17 drove a $500 million over-budget outcome.

💡 Memory Hook

Architecture + testing + complexity: all can turn small issues into billion-scale losses.

📖 3. Modeling, problem solving, and knowledge

🔑 Key Concepts & Definitions

• Model: A model is an abstract representation used to reason about a system without handling every real-world detail.
• Engineering method: An engineering method is a repeatable way to solve a specific problem by defining problem-solving steps.
• Knowledge acquisition: Knowledge acquisition is the process of collecting data, organizing information, and formalizing it into knowledge.
• Rationale: Rationale is information capturing the context and reasons behind decisions about the system or its application domain.

📝 Essential Points

• Models support understanding and visualization for systems that are too large, too small, too complicated, or too expensive to experience directly.
• In simplest form, engineering method steps are: formulate, analyze, search, decide, and specify the solution.
• Software engineering is not algorithmic because it relies on experimentation, pattern reuse, and incremental evolution toward client-acceptable solutions.
• Knowledge acquisition is nonlinear because new information can invalidate earlier understanding even if it was documented in code or documents.
• Rationale often is larger than solution models because multiple alternatives may be considered and many decisions remain implicit from experience and intuition.

💡 Memory Hook

Model simplifies, method steps guide, knowledge shifts, rationale explains why changes matter.

📖 4. Projects, participants, and roles

🔑 Key Concepts & Definitions

• Project: A project is the overall effort used to develop a software system, organized into activities and tasks.
• Participant: A participant is any person involved in the project who contributes to system development and use.
• Role: A role is a set of responsibilities assigned to a participant and associated with a set of tasks.

📝 Essential Points

• A role is assigned to a participant, and the same participant can fill multiple roles.
• The client orders and pays for the system, while developers construct it.
• The project manager plans and budgets the project and coordinates the developers and the client.
• End users are supported by the system as part of project participation.

💡 Memory Hook

People split by responsibilities: participants fill roles; roles drive tasks.

📖 5. Systems, models, and work products

🔑 Key Concepts & Definitions

• System: A system is a collection of interconnected parts that work together as a whole.
• Work product: A work product is an artifact produced during development that may be internal or delivered to the client.
• Artifact: An artifact is a produced outcome of work used as a system, model, or document.

📝 Essential Points

• Modeling manages complexity by deliberately ignoring irrelevant details.
• A ticket-train system example is given where a TicketDistributor for a train is treated as a system.
• A work product can be a system, a model, or a document, depending on what is produced by a task.
• Work products are either internal for project consumption or deliverables that must be delivered to the client.

💡 Memory Hook

System = connected parts; artifacts = produced outcomes; models = abstractions you use to tame complexity.

📖 6. Notations, methods, and methodologies

🔑 Key Concepts & Definitions

• Notation: A notation is a graphical or textual rule set used to represent a model.
• Method: A method is a repeatable technique that specifies steps for solving a particular kind of problem.
• Methodology: A methodology is a collection of methods plus guidance on how and when each method should be used.

📝 Essential Points

• UML is a notation for representing object-oriented models.
• Methods include examples such as sorting algorithms for ordering and rationale management for justifying change.
• Configuration management is presented as a method for tracking change.
• Methodologies decompose the development process into activities and specify when each method is used.

💡 Memory Hook

Notation draws, method acts step-by-step, methodology selects the right tools and timing.

📖 7. Development activities and testing

🔑 Key Concepts & Definitions

• Requirements elicitation: Requirements elicitation is the activity where client and developers define what the system will do using actors and use cases.
• Object design: Object design defines solution-domain objects and interfaces to bridge the analysis model with the selected platform goals.
• Testing: Testing is executing the system (or parts) on sample datasets to find faults before delivery.

📝 Essential Points

• Development activities include requirements elicitation, analysis, system design, object design, implementation, and testing.
• Actors are external entities interacting with the system, and use cases are sequences describing all possible actions between an actor and the system for given functionality.
• Analysis transforms use cases into a complete object model annotated with attributes, operations, and associations.
• System design decomposes the system into smaller subsystems and produces a deployment diagram.
• Implementation translates the solution-domain model into source code by implementing object attributes and methods and integrating objects into one system.
• Testing categories are unit (compare with object design model), integration (compare with system design model), and system (typical and exception cases vs requirements).

💡 Memory Hook

Elicit → analyze → design → object-design → implement → test: each step produces the model your next step needs.

⚠️ Common Pitfalls & Confusions

1. Confusing a model with the real system leads to either over-detailing the model or misunderstanding what it is meant to approximate.
2. Treating software engineering as purely algorithmic ignores the need for experimentation and incremental evolution toward client acceptance.
3. Mixing up requirements elicitation outputs (actors and use cases) with analysis outputs (object model with attributes, operations, and associations).
4. Swapping testing phases can cause the wrong comparison target, since unit tests use the object design model while system tests use the requirements model.
5. Believing that rationale equals solution models ignores that rationale is often larger and can be implicit from experience and intuition.

✅ Exam Checklist

1. Define software engineering in terms of a systematic, disciplined, quantifiable approach across development, operation, and maintenance.
2. List the failure themes shown (architecture redundancy issues, insufficient safety-critical testing, and unnecessary complexity) and associate each with its described consequence.
3. State what a model is and explain what modeling helps ignore in order to manage complexity.
4. Describe the simplest engineering method steps in correct order.
5. Explain why knowledge acquisition is nonlinear and how new information can invalidate previous understanding.
6. Define rationale and explain why rationale tends to contain more information than solution models.
7. Describe the project structure: project → activities → tasks, and what tasks consume and produce.
8. Define participants and distinguish roles as responsibility sets assigned to participants, noting that one participant can fill multiple roles.
9. Define a system and explain how modeling connects to systems through abstraction.
10. Classify work products into internal work products versus deliverables and state what they can be (system, model, or document).
11. Distinguish notation, method, and methodology using their provided definitions and named examples (UML, method examples, and methodology decomposition into activities).
12. Order the development activities and state the purpose/result links between requirements elicitation, analysis, system design, object design, implementation, and testing.
13. For testing, state the three test types and what each compares against (object design model, system design model, or requirements model) and the parallel planning schedule.