SEPTEMBER 29, 2024

SOFTWARE ENGINEERING
ENG: OSAMA ALATHWARI
LECTURE 1

ENG: OSAMA ALATHWARI

ALROWAD UNIVERSITY
Information Technology
 SOFTWARE ENGINEERING ENG: OSAMA ALATHWARI

Software Engineering Lecture 1: Fundamentals and Principles

1. Definition of Software Engineering

Software engineering is the systematic application of engineering approaches to the
development of software. It encompasses a set of methods, tools, and practices aimed at
creating high-quality software systems that are reliable, efficient, and maintainable.

2. Distinction between Programming and Software

Engineering
While programming is a crucial part of software engineering, the two are not synonymous:

• Programming focuses on writing code to implement specific functionalities.

• Software Engineering involves the entire process of software development,
including:
o Requirements analysis
o System design
o Implementation (programming)
o Testing and quality assurance
o Deployment and maintenance
o Project management and team coordination

Real-life example: Consider the development of a social media platform like Facebook. A
programmer might be tasked with coding a specific feature, like the "like" button. A software
engineer, however, would be involved in designing the overall architecture of the platform,
ensuring scalability to millions of users, implementing security measures, and coordinating
different teams working on various aspects of the system.

3. What Was Before Software Engineering

Before the emergence of software engineering as a discipline:

• Early computer programs were written directly in machine code or assembly

language.
• Development was often ad-hoc and lacked systematic approaches.
• Projects frequently ran over budget, missed deadlines, or failed to meet requirements.

Real-life example: The OS/360 project by IBM in the 1960s was one of the largest software
projects of its time. It faced significant delays and cost overruns, largely due to the lack of
established software development practices. This project and others like it contributed to
what became known as the "software crisis," which led to the birth of software engineering as
a discipline.

4. The Importance of Software Engineering and Why We

Should Use It
1
 SOFTWARE ENGINEERING ENG: OSAMA ALATHWARI

Software engineering is crucial because it:

• Improves software quality and reliability

• Enhances maintainability and scalability
• Reduces development costs and time
• Manages complexity in large-scale systems
• Facilitates team collaboration and communication

Real-life example: The success of NASA's Mars Rover missions can be attributed in large
part to rigorous software engineering practices. The software controlling these rovers must be
extremely reliable, as even a small bug could lead to mission failure. NASA's use of formal
methods, extensive testing, and careful requirements management exemplifies the importance
of software engineering in critical systems.

5. Software Development Life Cycle (SDLC)

The SDLC is a framework that describes the phases involved in software development:

5.1 Requirements Gathering and Analysis

• Definition: Identifying and documenting the needs of stakeholders.

• Activities: Interviews, surveys, workshops, document analysis.
• Techniques: Use case modeling, prototyping, requirements prioritization.
• Outcome: Requirements specification document, user stories.

Analysis and requirements gathering are crucial steps in the software development process.
They help ensure that the final product meets the needs of the users and stakeholders. Here's a
breakdown of the process:

a) Stakeholder identification: Identify all parties involved in or affected by the project.

b) Requirements elicitation: Gather requirements through various methods such as:

• Interviews
• Surveys
• Workshops
• User observation
• Existing system analysis

c) Requirements analysis: Analyze the gathered information to identify:

• Functional requirements (what the system should do)

• Non-functional requirements (how the system should perform)
• Constraints (limitations on design or implementation)

d) Requirements specification: Document the requirements in a clear, concise, and testable

manner.

2
 SOFTWARE ENGINEERING ENG: OSAMA ALATHWARI

e) Requirements validation: Review and validate requirements with stakeholders to ensure

accuracy and completeness.

5.2 Design

• Definition: Creating a blueprint for the software system.

• Activities: Architectural design, database design, interface design.
• Techniques: UML diagrams, design patterns, mockups.
• Outcome: Design documents, system architecture diagrams.

UML (Unified Modeling Language) diagrams are used to visualize, specify, construct, and
document software systems. Here are some common UML diagrams and their purposes:

a) Use Case Diagram:

• Purpose: Shows the interactions between users (actors) and the system
• Used for: Identifying system functionalities and user roles

b) Class Diagram:

• Purpose: Represents the static structure of the system, showing classes, attributes,
methods, and relationships
• Used for: Designing the object-oriented structure of the system

c) Sequence Diagram:

• Purpose: Illustrates the sequence of messages and interactions between objects over
time
• Used for: Modeling the dynamic behavior of the system for specific scenarios

d) Activity Diagram:

• Purpose: Represents the flow of activities or actions within a system

• Used for: Modeling business processes or complex algorithms

e) State Machine Diagram:

• Purpose: Shows the different states an object can be in and the transitions between
those states
• Used for: Modeling the lifecycle of objects with distinct states

f) Component Diagram:

• Purpose: Depicts the organization and dependencies among software components

• Used for: Modeling the high-level structure of the system and its modules

g) Architecture Diagram:

3
 SOFTWARE ENGINEERING ENG: OSAMA ALATHWARI

• Purpose: Provides a high-level view of the entire system, showing its major
components, their relationships, and how they interact.
• Used for: Communicating the overall structure of the system to both technical and
non-technical stakeholders.

5.3 Implementation

• Definition: Writing code based on the design specifications.

• Activities: Coding, unit testing, code review.
• Techniques: Programming languages, integrated development environments (IDEs),
version control systems.
• Outcome: Working software modules, documented code.

5.4 Testing

• Definition: Verifying that the software meets requirements and functions correctly.
• Activities: Unit testing, integration testing, system testing, acceptance testing.
• Techniques: Test case design, automated testing, performance testing.
• Outcome: Test plans, test cases, bug reports, test results.

5.5 Deployment

• Definition: Releasing the software to the production environment.

• Activities: Installation, configuration, data migration, user training.
• Techniques: Deployment automation, continuous integration/continuous deployment
(CI/CD).
• Outcome: Deployed software system, user manuals, release notes.

5.6 Maintenance

• Definition: Supporting and improving the software after deployment.

• Activities: Bug fixing, updates, enhancements, performance optimization.
• Techniques: Version management, patch management, monitoring tools.
• Outcome: Updated software versions, patch releases, performance reports.

6. Software Process Models and Their Main Differences

6.1 Waterfall Model

• Sequential, linear approach

• Each phase must be completed before the next begins
• Suitable for projects with well-defined, stable requirements

6.2 Iterative and Incremental Model

• Development is broken into smaller cycles (iterations)

4
 SOFTWARE ENGINEERING ENG: OSAMA ALATHWARI

• Product grows incrementally with each iteration

• Allows for more flexibility and feedback incorporation

6.3 Agile Methodologies

• Emphasizes flexibility, collaboration, and rapid delivery

• Iterative approach with short development cycles (sprints)
• Focuses on working software over comprehensive documentation

Main differences:

• Waterfall is rigid and sequential, while Iterative and Agile are more flexible.
• Agile emphasizes customer collaboration and adapting to change more than the other
models.
• Waterfall produces a complete product at the end, while Iterative and Agile produce
working software in increments.

Real-life example: Spotify uses an Agile-inspired model called "Spotify Model" which
emphasizes autonomous, cross-functional teams (called "squads") working on different parts
of the product. This allows them to rapidly develop and deploy new features, adapting
quickly to user feedback and market changes.

7. Challenges in Software Engineering

• Complexity management
• Scalability
• Reliability and security
• Changing requirements
• Team coordination and communication

Real-life example: The development of healthcare.gov, the website for the U.S. health
insurance marketplace, faced many of these challenges. Its initial launch in 2013 was plagued
with issues related to scalability (unable to handle the high volume of users), reliability
(frequent crashes and errors), and changing requirements (evolving healthcare policies). This
demonstrates the critical importance of addressing these challenges in large-scale software
projects.

8. Software Quality Attributes

• Functionality: The ability to perform required functions
• Reliability: Consistent performance under specified conditions
• Usability: Ease of use and learnability
• Efficiency: Performance relative to resources used
• Maintainability: Ease of modification and updates
• Portability: Ability to transfer to different environments

Real-life example: The success of the Linux operating system can be attributed to its strong
adherence to these quality attributes. It's known for its functionality (wide range of supported

5
 SOFTWARE ENGINEERING ENG: OSAMA ALATHWARI

operations), reliability (stable performance), efficiency (low resource usage), maintainability

(open-source code allows for easy updates), and portability (runs on various hardware
platforms).

9. Software Engineering Documentation Structure and

Guidelines
Chapter 1: Introduction
1.1 Introduction

• Provide an overview of the project

• Briefly introduce the problem and the proposed solution
• Outline the document structure

1.2 Problem Statement

• Clearly define the problem being addressed

• Explain why the problem is significant
• Describe any existing solutions and their limitations

1.3 Proposed System

• Introduce the high-level concept of the proposed solution

• Highlight key features and innovations
• Explain how it addresses the problem statement

1.4 Project Motivation

• Discuss the reasons for undertaking this project

• Explain the potential impact and benefits

1.5 Project Objectives

• List specific, measurable goals for the project

• Ensure objectives align with the problem statement and proposed system

1.6 Project Scope

• Define what is included in the project

• Clearly state any limitations or exclusions

1.7 Methodology

• Describe the development approach (e.g., Agile, Waterfall)

• Outline the key phases of the project

6
 SOFTWARE ENGINEERING ENG: OSAMA ALATHWARI

1.8 Targeted Customers and Beneficiaries

• Identify the primary users or customers

• Explain how they will benefit from the system

Chapter 2: Literature Review and Background

• Provide context for the project
• Review relevant existing technologies, solutions, or research
• Analyze similar systems or approaches
• Identify gaps in current solutions that your project addresses

Chapter 3: Analysis
3.1 Introduction

• Briefly introduce the analysis phase and its importance

3.2 The Development Model Used

• Describe the chosen development model (e.g., Agile, Scrum)

• Explain why this model was selected for the project

3.3 Requirements Gathering

• Describe the methods used to gather requirements (e.g., interviews, surveys)

• Summarize key findings from the requirements gathering process

3.4 System Requirements

3.4.1 Functional Requirements

• List and describe all functional requirements
• Use clear, concise language for each requirement

3.4.2 Non-functional Requirements

• List and describe all non-functional requirements (e.g., performance, security,
usability)

3.5 Software Requirements

• Specify required software, frameworks, or libraries

• Include versions and any specific configurations needed

3.6 Hardware Requirements

7
 SOFTWARE ENGINEERING ENG: OSAMA ALATHWARI

• Specify required hardware for development and deployment

• Include any specific devices or equipment needed

3.7 System Modeling

• Introduce the models used to represent the system

• Briefly describe each model's purpose

Chapter 4: Design
4.1 Introduction

• Introduce the design phase and its objectives

4.2 User Interface Design

• Present wireframes or mockups of the user interface

• Explain design choices and user experience considerations

4.3 API Documentation

• Document the system's APIs (if applicable)

• Include endpoints, request/response formats, and authentication methods

Chapter 5: Implementation
• Describe the implementation process
• Highlight key challenges and solutions
• Discuss any deviations from the original design and why they were necessary

Chapter 6: Testing
6.1 Introduction

• Introduce the testing phase and its importance in the software development lifecycle

6.2 Testing Strategy

• Outline the overall approach to testing

• Describe different levels of testing (unit, integration, system, acceptance)

6.3 Test Cases

• Provide an overview of test cases

• Include examples of critical test cases

8
 SOFTWARE ENGINEERING ENG: OSAMA ALATHWARI

6.4 Test Results

• Summarize the results of testing

• Highlight any significant issues discovered and how they were resolved

6.5 Test Coverage

• Discuss the extent of test coverage

• Identify any areas that may require additional testing

Chapter 7: Summary
7.1 Project Overview

• Briefly recap the project's goals and objectives

7.2 Key Achievements

• Highlight the main accomplishments of the project

7.3 Challenges and Solutions

• Discuss significant challenges encountered during the project

• Explain how these challenges were addressed

7.4 Future Work

• Identify potential areas for future development or improvement

• Suggest possible extensions or enhancements to the system

Chapter 8: References
8.1 Bibliography

• List all books, articles, and papers referenced in the document

8.2 Online Resources

• Provide URLs for any online resources or tools used