Midterm
1. Overview of Software Engineering
Software: Computer programs and associated documentation[1].
Software Engineering: The application of a systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software[1].
Software Documentation: Deliverables including requirements, design models, program comments, configuration files, and user manuals[1].
Importance of Software Engineering: Societies rely heavily on reliable software produced economically and quickly; using engineering methods is cheaper in the long run than personal programming approaches[1].
Software Engineering Layers:
Quality Focus: The bedrock that supports all software engineering practices[1].
Process: The glue that holds technology layers together and enables timely software development[1].
Methods: Technical "how-to’s" for building software[1].
Tools: Automated or semi-automated support for processes and methods[1].
Fundamental Activities of a Software Process:
Software Specification: Defining the functionality and operational constraints of the software[1].
Software Development: Producing software that meets the specification through design and implementation[1].
Software Validation: Verifying that the software does what the customer wants[1].
Software Evolution: Modifying software to meet changing customer needs over time[1].
Application Types:
Stand-alone Applications: Run locally on a computer without requiring a network connection[2].
Interactive Transaction-Based Applications: Remote applications accessed by users over a network (e.g., e-commerce)[2].
Embedded Control Systems: Software that manages and controls hardware devices[2].
Batch Processing Systems: Business systems designed to process data in large batches[2].
Entertainment Systems: Personal use systems designed primarily to entertain[2].
Systems for Modeling and Simulation: Computational models of physical processes containing interacting objects[2].
Data Collection Systems: Sensor-driven systems that collect environmental data for processing[2].
Systems of Systems: Complex software systems composed of multiple individual software systems[2].
2. Software Process Models
Software Process: A structured set of activities required to develop a software system[3].
Software Process Model: An abstract, high-level representation of a software process from a specific perspective[3].
Plan-Driven Software Process: A process where all activities are planned in advance and progress is measured against this pre-established plan[4].
Agile Process: A process where planning is incremental, making it easy to adapt to changing customer requirements[4].
Waterfall Model: A plan-driven, sequential model with separate and distinct phases of specification and development[5].
Benefits: Helps coordinate work in large systems engineering projects across multiple sites[5].
Drawbacks: Rigid partitioning makes it difficult to respond to changing customer requirements[5].
Incremental Development: Interleaved specification, development, and validation that delivers software as a series of increments[6].
Benefits: Reduced cost of changing requirements, easier customer feedback, and faster delivery of useful software[6].
Drawbacks: Lack of process visibility for managers; system structure degrades over time without regular refactoring[6].
3. Agile Software Development
Agile Software Development: Iterative methodology focused on code delivery, frequent releases, customer collaboration, and minimal documentation[7].
Agile Principles:
Customer Involvement: Customers actively prioritize requirements and evaluate system iterations[8].
Incremental Delivery: Software is delivered in small increments based on customer priorities[8].
People Not Process: Exploiting team skills without imposing prescriptive processes[8].
Embrace Change: Designing systems to easily accommodate evolving requirements[8].
Maintain Simplicity: Actively working to eliminate complexity from the software and process[8].
Extreme Programming (XP): An extreme iterative approach featuring small releases, automated testing, and strong technical practices[9].
User Story: Customer requirements expressed as scenarios on cards, which are broken down into implementation tasks[10].
Refactoring: Continually improving internal code structure without changing its external behavior[10].
Test-Driven Development (TDD): Writing automated unit tests before writing the production code to clarify requirements[10].
Pair Programming: Two developers working together at one screen, sharing knowledge and providing real-time code review[10].
Scrum: An agile framework focused on managing iterative development using sprints, backlogs, and daily check-ins[10][11].
Sprint: A fixed-length development iteration (typically 2–4 weeks)[11][12].
Product Backlog: A prioritized list of required features, stories, and tasks to be completed[13].
Potentially Shippable Product Increment: A fully tested, finished software increment produced at the end of a sprint[13].
ScrumMaster: A facilitator who enforces the Scrum process and protects the development team from external distractions[13].
Product Owner: The individual responsible for identifying features, maintaining the product backlog, and driving business value[13].
Development Team: A self-organizing group of software developers (7 people or fewer) responsible for building the software[14].
4. Requirements Engineering (RE)
Requirements Engineering (RE): The process of establishing the services required of a system and the constraints under which it operates[15].
Requirement: A statement defining what a system must do or a constraint under which it must function[15].
User Requirements: High-level natural language statements and diagrams specifying system services and constraints for customers[16].
System Requirements: Detailed structured documentation defining precise system functions, services, and operational constraints for developers[16].
Functional Requirements: Statements describing specific services, inputs, behaviors, or what the system must not do[16].
Non-Functional Requirements: Constraints on system services or qualities (such as timing, performance, standards, and security)[16].
Requirements Elicitation: Interacting with stakeholders to discover system needs and constraints[17][18].
Requirements Specification: Formally documenting user and system requirements into a official requirements document[17][19].
Requirements Validation: Checking requirements to ensure they are valid, consistent, complete, realistic, and verifiable[17][20].
Requirements Management: Tracking and managing changing requirements throughout the software development lifecycle[17][21].
Stakeholders: Any person or organization affected by the system or having a legitimate interest in its outcome[22].
5. Software Design
Software Design: The process of converting requirements into an organized software structure, divided into architectural and detailed design[23].
Architectural Design: Identifying the principal system components, their relationships, and how they are distributed[23].
Detailed Design: Decomposing main components to describe them at a finer level of detail[23].
Coupling: The measure of dependencies between two software subsystems[23].
Loose Coupling: Subsystems are independent; changes in one have minimal impact on the other[23].
Strong Coupling: Subsystems are highly dependent; changes in one likely impact the other[23].
Cohesion: The measure of dependencies among classes or objects within a single subsystem[23].
High Cohesion: Subsystem contains closely related objects performing similar tasks[23].
Low Cohesion: Subsystem contains unrelated objects[23].
Design Inputs: Platform information, requirements specification, and data description[24].
Design Outputs: System architecture, database specification, interface specification, and component specification[24].
Interface Design: Defining unambiguous specifications for communication between system components[24].
Component Design: Designing the precise internal operation and functionality of individual components[24].
Database Design: Structuring and representing system data structures within a database[24].