CPE363 – Software Design: Detailed Study Material

========================================================================
========

WEEK 1–2: INTRODUCTION TO SOFTWARE ENGINEERING AND PROFESSIONAL

RESPONSIBILITY
--------------------------------------------------------------------------------

1. INTRODUCTION TO SOFTWARE ENGINEERING

DEFINITION:
Software Engineering is an engineering discipline concerned with **all aspects of software
production**—from specification and design to validation and maintenance. It emphasizes
systematic, disciplined, and cost-effective development methods.

IMPORTANCE:
- The economy of every developed nation depends heavily on software.
- Most modern systems are **software-controlled** (transportation, communication, healthcare,
etc.).
- Software costs represent a large fraction of national GNP.
- Software Engineering ensures **cost-effective**, **reliable**, and **maintainable** systems.

SOFTWARE COSTS:
- Software often costs **more than hardware**.
- **Maintenance costs** can exceed initial **development costs**.
- Long-life systems spend most of their budget on updates and evolution.

--------------------------------------------------------------------------------

2. KEY CONCEPTS AND DISTINCTIONS

WHAT IS SOFTWARE?
- Programs + associated documentation (requirements, design models, user manuals).
- Two main types:
1. **Generic Products:** Sold to a wide market (e.g., Word, Excel).
2. **Bespoke Products:** Custom-built for one client’s specification.
- New systems may be built, configured, or reused from existing software.

WHAT IS SOFTWARE ENGINEERING?

- The application of **engineering principles** to the entire software lifecycle.
- Involves **theories, methods, and tools** for professional development.
- Aims for **systematic**, **organized**, and **reliable** software creation.
SOFTWARE ENGINEERING vs. COMPUTER SCIENCE:
- **Computer Science:** Focuses on theoretical foundations.
- **Software Engineering:** Focuses on practical development and delivery of usable products.

SOFTWARE ENGINEERING vs. SYSTEM ENGINEERING:

- **Software Engineering:** Develops the software component.
- **System Engineering:** Involves the entire system (hardware, software, process).

--------------------------------------------------------------------------------

3. SOFTWARE PROCESS AND MODELS (OVERVIEW)

SOFTWARE PROCESS:
A structured set of activities for developing or evolving software.

FOUR FUNDAMENTAL ACTIVITIES:

1. **Specification:** What the system should do and its constraints.
2. **Development:** Building and implementing the system.
3. **Validation:** Ensuring the system meets user needs.
4. **Evolution:** Updating the system as requirements change.

SOFTWARE PROCESS MODELS:

Simplified representations of processes viewed from different perspectives.

COMMON MODELS:
- **Waterfall Model:** Sequential stages — suitable for stable requirements.
- **Iterative Development:** Builds system through repeated cycles; allows early feedback.
- **Component-Based Software Engineering:** Reuses existing components to reduce cost and
development time.

--------------------------------------------------------------------------------

4. COST DISTRIBUTION AND METHODS

COST STRUCTURE:
- ~60% development, ~40% testing.
- Evolution costs for long-term systems may exceed initial development.

SOFTWARE ENGINEERING METHODS:

Structured techniques including:
- **Model Descriptions:** Graphical representations.
- **Rules:** Constraints on system models.
- **Recommendations:** Best design practices.
- **Process Guidance:** Activities and steps to follow.

COMPUTER-AIDED SOFTWARE ENGINEERING (CASE):

Automated tools supporting software development.
- **Upper-CASE:** Supports early stages (requirements, design).
- **Lower-CASE:** Supports later stages (coding, testing).

--------------------------------------------------------------------------------

5. ATTRIBUTES OF GOOD SOFTWARE

Good software must have the following qualities:

1. **Maintainability:** Easy to evolve and update.
2. **Dependability:** Reliable, safe, and secure.
3. **Efficiency:** Uses resources effectively.
4. **Acceptability:** Understandable, usable, and compatible with other systems.

--------------------------------------------------------------------------------

6. CHALLENGES IN SOFTWARE ENGINEERING

1. **Heterogeneity:** Handling diverse platforms and environments.

2. **Delivery:** Producing software faster without sacrificing quality.
3. **Trust:** Building systems users can depend on safely.

--------------------------------------------------------------------------------

7. PROFESSIONAL AND ETHICAL RESPONSIBILITY

ETHICAL RESPONSIBILITY:
Software engineers must act with integrity, honesty, and professionalism beyond technical
ability.

ISSUES OF PROFESSIONAL RESPONSIBILITY:

- **Confidentiality:** Protect client and employer information.
- **Competence:** Only accept work within your ability.
- **Intellectual Property Rights:** Respect patents and copyrights.
- **Computer Misuse:** Avoid unethical or illegal actions (e.g., hacking, viruses).

--------------------------------------------------------------------------------

8. CODE OF ETHICS (ACM/IEEE)

EIGHT PRINCIPLES:
1. **PUBLIC:** Act in the public interest.
2. **CLIENT AND EMPLOYER:** Serve clients and employers ethically.
3. **PRODUCT:** Ensure professional quality and reliability.
4. **JUDGMENT:** Maintain integrity and independence.
5. **MANAGEMENT:** Promote ethical project management.
6. **PROFESSION:** Uphold and advance the profession’s integrity.
7. **COLLEAGUES:** Be fair, supportive, and respectful.
8. **SELF:** Commit to lifelong learning and ethical practice.

--------------------------------------------------------------------------------

9. ETHICAL DILEMMAS (EXAMPLES)

- Disagreeing with management policies that conflict with ethics.

- Employer releasing unsafe or untested systems.
- Participation in military or nuclear software projects.
- Pressure to violate confidentiality or manipulate results.

========================================================================
========

WEEK 3: SOFTWARE PROCESSES AND MODELS

--------------------------------------------------------------------------------

1. SOFTWARE PROCESS CONCEPTS

A **software process** is a structured set of activities required to develop a software system:

- **Specification**
- **Design**
- **Validation**
- **Evolution**

A **software process model** provides an abstract representation of these activities.

--------------------------------------------------------------------------------

2. GENERIC SOFTWARE PROCESS MODELS

**1. Waterfall Model**

- Sequential, distinct phases:
Requirements → Design → Implementation → Testing → Maintenance.
- **Drawback:** Difficult to accommodate change.
- **Best For:** Stable, large-scale systems.

**2. Evolutionary Development**

- Combines specification, development, and validation iteratively.
- **Types:**
- Exploratory Development (works with user feedback).
- Throwaway Prototyping (clarifies uncertain requirements).
- **Issues:** Poor visibility, structure, needs skilled prototypers.

**3. Component-Based Software Engineering**

- Reuses existing components or COTS products.
- Steps: Component analysis → Requirements modification → Design with reuse → Integration.

--------------------------------------------------------------------------------

3. ITERATIVE MODELS AND PROCESS ACTIVITIES

**Incremental Delivery**
- Divides the system into smaller deliverables.
- Early increments provide usable functionality.
- Advantages: Early value, reduced failure risk, user feedback.

**Spiral Development**
- Risk-driven iterative approach with phases for:
1. Objective setting
2. Risk analysis
3. Development & validation
4. Planning

**Extreme Programming (XP)**

- Small increments, pair programming, continuous integration, user involvement.

--------------------------------------------------------------------------------

4. PROCESS ACTIVITIES

**Software Specification:** Defines services and constraints.

- Feasibility study, elicitation, specification, validation.

**Design and Implementation:** Transforms specification into working system.

- Architectural, interface, component, data structure, and algorithm design.

**Validation (V&V):**
- Ensures system meets requirements via reviews and testing.
- Levels: Unit, System, Acceptance testing.

**Evolution:** Modifies software post-deployment to meet new needs.

--------------------------------------------------------------------------------

5. RATIONAL UNIFIED PROCESS (RUP)

PHASES:
1. **Inception:** Define business case.
2. **Elaboration:** Analyze and design architecture.
3. **Construction:** Build and test.
4. **Transition:** Deploy in environment.

GOOD PRACTICES:
- Iterative development
- Requirements management
- Component-based architecture
- Visual modeling
- Quality verification
- Controlled change management

--------------------------------------------------------------------------------

6. COMPUTER-AIDED SOFTWARE ENGINEERING (CASE)

CASE TOOLS:
- **Tools:** Single task (e.g., editor, checker)
- **Workbenches:** Single phase (e.g., design)
- **Environments:** Multiple phases (integrated system)

CLASSIFICATION:
- Functional, Process, and Integration perspectives.

BENEFITS:
- Automation, consistency, faster development.
LIMITS:
- Cannot replace creativity or team coordination.

========================================================================
========
WEEK 4: REQUIREMENTS ENGINEERING
--------------------------------------------------------------------------------

1. INTRODUCTION

**Definition:**
The process of **discovering, analyzing, documenting, and maintaining software
requirements**.

**Purpose:**
Bridge the gap between stakeholder needs and technical implementation.

**Importance:**
- Reduces development costs and time.
- Minimizes project risks.
- Ensures stakeholder satisfaction.
- Clarifies project scope.

--------------------------------------------------------------------------------

2. TYPES OF REQUIREMENTS

**Functional Requirements (What):**

- Define system behavior and operations.
- Examples:
- Login and authentication.
- Shopping cart management.
- Payment processing (e.g., PayPal, credit cards).
- Report generation.
- Notification emails after transactions.

**Non-Functional Requirements (How):**

- Define system qualities and constraints.
- Examples:
- Performance: Load homepage within 2 seconds.
- Security: Encrypt passwords using SHA-256.
- Usability: Usable by first-time users within 5 minutes.
- Reliability: 99.9% uptime.
- Scalability: Handle 10,000 concurrent users.
- Compliance: Philippine Data Privacy Act (RA 10173).

--------------------------------------------------------------------------------
3. REQUIREMENTS ENGINEERING PROCESS

STAGES:
1. **Elicitation:** Gathering user and business needs.
2. **Analysis:** Refining, prioritizing, and resolving conflicts.
3. **Specification:** Documenting requirements clearly.
4. **Validation:** Ensuring requirements meet stakeholder needs.
5. **Management:** Tracking and controlling changes via versioning and traceability.

--------------------------------------------------------------------------------

4. REQUIREMENTS ELICITATION TECHNIQUES

- Interviews
- Surveys and Questionnaires
- Workshops
- Observation
- Document Analysis
- Prototyping
- Brainstorming

--------------------------------------------------------------------------------

5. STAKEHOLDER IDENTIFICATION

**Primary Stakeholders:**
- End users, customers, sponsors, managers, analysts, developers.

**Secondary Stakeholders:**
- Administrators, maintenance teams, regulators, vendors.

**Key Considerations:**
- Conflicts of interest, communication style, authority, and engagement level.

--------------------------------------------------------------------------------

6. REQUIREMENTS DOCUMENTATION

**Software Requirements Specification (SRS):**

- Comprehensive reference for system requirements.
- Includes: Functional + Non-Functional requirements, constraints, assumptions, UI mockups.

**Key Sections:**
- Introduction and Scope
- System Overview
- Specific Requirements
- External Interface Requirements
- Quality Attributes

--------------------------------------------------------------------------------

7. REQUIREMENTS ANALYSIS TECHNIQUES

**Prioritization Methods:**
- **MoSCoW:** Must, Should, Could, Won’t.
- **Kano Model:** Basic, Performance, Delighter.
- **Weighted Scoring:** Score-based feature ranking.
- **Cost-Benefit Analysis:** Balances value vs. cost.

**Conflict Resolution Techniques:**

- **Negotiation:** Compromise between teams.
- **Trade-off Analysis:** Speed vs. feature completeness.
- **Alternative Exploration:** Compare solutions (e.g., QR vs. biometric).
- **Consensus Building:** Agreeing on combined solutions.

--------------------------------------------------------------------------------

8. REQUIREMENTS VALIDATION

**Techniques:**
- Reviews and Inspections
- Prototyping
- Test Case Derivation
- Requirements Tracing
- Acceptance Criteria Definition
- Walkthrough Sessions

--------------------------------------------------------------------------------

9. REQUIREMENTS MANAGEMENT TOOLS

**Documentation Tools:** Confluence, Notion, Google Docs

**Tracking Tools:** JIRA, Trello, Azure DevOps
**Modeling Tools:** UML, Use Case, Flowcharts, Wireframes
**Traceability Tools:** Change tracking and version control systems
--------------------------------------------------------------------------------

10. COMMON REQUIREMENTS CHALLENGES

**Issues:**
- Incomplete or ambiguous requirements
- Scope creep
- Conflicting stakeholder needs
- Poor communication
- Unrealistic expectations

**Solutions:**
- Frequent stakeholder communication
- Iterative refinement
- Change management process
- Requirement prioritization
- Prototype validation
- Consistent documentation standards

--------------------------------------------------------------------------------

11. REQUIREMENTS QUALITY ATTRIBUTES

Good requirements must be:

- Clear and Unambiguous
- Complete
- Consistent
- Testable
- Traceable
- Feasible
- Necessary

--------------------------------------------------------------------------------

12. AGILE REQUIREMENTS ENGINEERING

**Principles:**
- Collaboration over documentation
- Adaptive planning
- Working software as progress measure

**Techniques:**
- User stories and acceptance criteria
- Sprint planning and refinement
- MVP (Minimum Viable Product)
- Continuous feedback and retrospectives

========================================================================
========

SUMMARY
--------------------------------------------------------------------------------
Software Engineering integrates structured processes, professional ethics, and disciplined
requirement analysis to ensure successful system delivery.
Requirements Engineering bridges user needs and system design, emphasizing clarity,
collaboration, and adaptability throughout the software lifecycle.