Topic 1: What is Software Engineering?

🧠 Definition of Software Engineering

 Software Engineering is the application of scientific principles to the design

and creation of software.
 It uses a systematic approach to:
o Collect and analyze business requirements.
o Design, build, and test software applications that meet those
requirements.

Historical Context & Evolution

 Late 1950s: Computing began; software engineering was undefined.

 1960s: Recognized as a formal engineering discipline.
 Trends shifted from ad hoc (informal) programming to standardized, scientific
methods.

⚠️The Software Crisis (Mid-1960s to Mid-1980s)

 Software often:
o Ran over budget.
o Was delayed.
o Contained unmanageable, buggy code.
 Software solutions became obsolete before completion due to fast tech
advancements.
 Small system methods failed to scale to large projects.

✅ Resolution of the Crisis

 Adoption of engineering principles helped resolve many issues.

 Standardized development methodologies improved scalability and structure.
 CASE (Computer-Aided Software Engineering) tools emerged:
o Categories:
1. Business analysis & modeling
2. Development tools (e.g., debugging)
3. Verification & validation
4. Configuration management
5. Metrics & measurement
 6. Project management

Software Engineer vs. Software Developer

Aspect Software Engineer Software Developer

Scope Broader Narrower
Focus Systematic, big-picture approach Specific functionalities
Tasks Design, build, maintain entire systems Write code for individual features
Common in Large-scale projects Specific tasks within a project

Responsibilities of a Software Engineer

 Design, build, and maintain software systems.

 Write and test code.
 Consult with:
o Clients
o Third-party software vendors
o Security specialists
o Other team members

🔄 Influence on Modern Development

 Modern software development follows the Software Development Lifecycle

(SDLC).
o SDLC guides the steps for creating high-quality software.
o Further details on SDLC and software quality traits will follow in later
videos.

📝 Key Takeaways

 Software engineering = systematic, scientific approach to software

design/development.
 Engineers build systems; developers implement parts of those systems.
 Engineering principles and CASE tools helped resolve historical inefficiencies.
 Topic 2: Insider’s Viewpoint: What is Software Engineering?

🧠 General Definitions of Software Engineering

 Engineering + Programming: Software engineering is the use of programming

languages combined with engineering principles to build digital products.
 These products may include:
o Web apps, mobile apps, desktop apps
o Operating systems and networking systems
 It's considered critical to modern society, enabling essential technological functionality.

Scope and Roles in Software Engineering

 Software engineering is a broad discipline, including multiple specialized roles such as:
o Frontend engineer
o Backend engineer
o Security engineer
o Mobile engineer
o Test engineer
o Full-stack engineer
o DevOps
o Cloud engineer
o Data engineer
o Machine learning engineer

🔄 Full Lifecycle Process

 Software engineering is more than coding—it includes:

o Designing, envisioning, implementing, supporting, and maintaining software.
o Begins before any code is written, at the idea stage.
o Involves a creative process that spans the entire lifecycle from concept to
maintenance and evolution.

Software Engineer vs. Developer: Different Perspectives

There is no universal agreement on the distinction, and it varies by region, company, and
background. The following viewpoints were shared:
📌 Broader View (Engineer > Developer)

 Engineering is seen as a broader term encompassing:

o Full system design
o Architecture
o Deployment
o Maintenance
 Development is viewed as:
o Writing and implementing code modules.
o More focused on specific tasks within the lifecycle.

📌 Semantic/Title-Based View

 Some consider the difference semantic or gatekeeping-based:

o Job titles may not reflect actual responsibilities.
o Individuals with non-traditional backgrounds (e.g., no CS degree) often find titles
used interchangeably.
o Roles like "full-stack developer" and "software engineer" often overlap heavily in
practice.

📌 Contextual View (Region/Industry Specific)

 In Canada:
o "Software Engineer" implies a licensed professional with training in ethics and
held to standards similar to civil or mechanical engineers.
o "Developer" or "Programmer" may not require this background.
 Immigration and legal documents also treat these titles differently.

🧭 Practical Takeaways

 In practice and job descriptions:

o Software engineer and developer roles are often used interchangeably.
o However, software engineers may be more involved in:
 System-level thinking
 Data handling and architecture
 Long-term design and planning
o Developers may be more focused on:
 Feature development
 App-building tasks
 The engineering mindset typically spans a longer time horizon with multiple
responsibilities, while development may be more narrowly scoped to implementation
tasks.
 Topic 3: Intro to SDLC

🧠 What Is the SDLC?

 Software Development Life Cycle (SDLC) is a systematic process for developing

high-quality software within a predictable timeframe and budget.
 Main goal: Ensure the software meets the client’s business requirements.

🔁 Nature of the SDLC

 The SDLC consists of phases, each with its own process and deliverables.
 It includes planning, design, and development steps.
 Can be implemented using iterative approaches (i.e., repeating cycles).
 Benefits:
o Reduces risks and costs.
o Supports the delivery of deployable and efficient software.

History of the SDLC

 Originated in the mid-1960s due to:

o Increasing complexity of software.
o Growing need for structured development in large corporations.
o Demand for managing complex business systems and computational resources.
 Initially used the Waterfall model:
o A linear approach where software moves through sequential stages.
 Later adapted into iterative models to handle:
o Changing customer needs
o Shifting requirements

☑️Note: Different SDLC models like Waterfall and others will be covered in a later lesson.

✅ Key Advantages of the SDLC

1. Provides a Clear Process

o Replaces ad hoc development.
o Helps teams follow a repeatable and reliable process.
o Increases efficiency and reduces risk.
2. Discrete, Well-Defined Phases
o Every team member knows:
  What they should work on.
 When their part of the process is active.
o Enhances clarity and workflow management.
3. Facilitates Communication
o Enables better communication between:
 Customers
 Stakeholders
 Development teams
o Stakeholders can see where they fit in the process.
4. Improves Cross-Team Coordination
o Teams from different domains know:
 When their tasks start and end.
 When to handoff work to other teams.
5. Supports Iteration
o At the end of a cycle, the process can loop back.
o Allows for adding new requirements when needed.
6. Encourages Early Problem Solving
o Identifies and solves problems in early stages like design.
o Reduces costly errors during the coding phase.
7. Clearly Defined Roles
o Every team member has a specific responsibility.
o Prevents conflict and overlapping duties.

📝 Final Takeaways

 SDLC = A structured framework for software development.

 Originally created due to the growing complexity of software systems.
 Offers major benefits:
o Roadmap to reduce risk and boost efficiency.
o Better team and stakeholder communication.
o Clear responsibilities and support for iteration.
o Early-stage problem-solving.
 Topic 4: Phases of SDLC
📘 Summary: Phases of the Software Development Life Cycle (SDLC)

🔢 The Six Core Phases of the SDLC

1. Planning
2. Design
3. Development
4. Testing
5. Deployment
6. Maintenance

Each phase is discrete—tasks in one phase do not overlap with the next.

Originally modeled as a linear Waterfall approach, but modern adaptations allow for iteration
to handle shifting requirements.

1️⃣ Planning Phase

 Purpose: Define requirements and scope.

 Also known as: Requirements, Strategy, or Analysis phase (varies by organization).
 Key Activities:
o Gather, analyze, and prioritize requirements.
o Consider:
 End users
 Purpose of the software
 Input/output data
 Legal/regulatory compliance
 Risks and QA needs
 Budget, time, and resource allocation
o Identify project team and assign roles.
o Estimate costs (labor and materials) vs. time.
 Prototyping may be used:
o To clarify vague requirements.
o As a small-scale version to test design ideas.
o Can also occur in other phases as needed.
 Output:
o A clearly approved Software Requirements Specification (SRS) document,
understood by both stakeholders and developers.
2️⃣ Design Phase

 Purpose: Convert requirements (SRS) into software architecture.

 Involves multiple team members for collaborative design.
 Stakeholders review and provide feedback.
 Prototypes can be built for demonstration.
 Output:
o A Design Document that outlines the system's architecture and guides
development.

3️⃣ Development Phase (a.k.a. Building or Implementation Phase)

 Purpose: Begin coding the software solution.

 Developers use the design document to assign and carry out tasks.
 Use of:
o Programming tools
o Languages and frameworks
o Organization-specific coding standards and software stacks

4️⃣ Testing Phase

 Purpose: Ensure the software is functional, stable, and secure.

 May involve a dedicated testing team.
 Testing types (manual, automated, or hybrid):
o Unit Testing
o Integration Testing
o System Testing
o Acceptance Testing
(Details covered in a later video)
 Bugs are:
o Reported
o Tracked
o Fixed and retested

5️⃣ Deployment Phase

 Purpose: Release software into the production environment.

 Can be staged:
o First deployed to User Acceptance Testing (UAT) environment.
 o After client approval, released to production.
 Applies to:
o Websites
o Mobile apps
o Corporate software distribution systems

6️⃣ Maintenance Phase

 Begins after deployment into production.

 Key Activities:
o Fix remaining bugs or UI issues missed during testing.
o Gather feedback from real users and stakeholders.
o Identify unaddressed or new requirements.
o Suggest code enhancements for future releases.
 Possible Restart:
o If major changes are needed, the SDLC restarts with updated requirements.

📝 Final Takeaways

 SDLC phases follow a structured path from planning to maintenance.

 Each phase has a clear output, ensuring control and visibility.
 Allows for iteration and continuous improvement.
 Minimizes errors, improves quality, and aligns software with business goals.
 Toipc 5: Building Quality Software
This video explains six essential software engineering processes that help ensure the creation of
high-quality software:

✅ 1. Requirements Gathering

 Purpose: Define what the software must do and how it should behave.
 Documented in the Software Requirements Specification (SRS).
 May include use cases to describe user flows and business needs.
 Four major types of software requirements:
o Functional Requirements – Describe features and behavior.
o External/UI Requirements – Define interfaces and user interactions.
o System Features – Include performance, capacity, etc.
o Non-functional Requirements – Address security, scalability, reliability, etc.

These categories will be discussed further in a future video.

2. Design

 Purpose: Convert requirements into a design structure ready for coding.

 Output: Software architecture and design documents.
 Activities include:
o Breaking requirements into components with clear:
 Behaviors
 Boundaries
 Interactions
o Specifying:
 System functions, performance, platform details
 Business rules and application logic
 APIs (how components interact or connect to databases)
 UI design and Database schemas

💻 3. Coding for Quality

 Code quality attributes:

o Maintainability
o Readability
o Testability
o Security
 Good quality code:
 o Is bug-free, efficient, and well-documented
o Uses consistent formatting and naming conventions
 Best Practices:
o Follow standard coding patterns, styles, and conventions
o Use linters to catch syntax/style issues
o Include comments to explain logic for future developers

🧪 4. Testing

 Purpose: Ensure software meets requirements and is free from defects.

 Validates:
o Reliability
o Security
o Performance
o Efficiency
 Testing can be:
o Manual, Automated, or Hybrid
 Levels of Testing:
o Unit Testing: Tests individual components (done by developers)
o Integration Testing: Verifies interaction between components
o System Testing: Tests full system behavior
o User Acceptance Testing (UAT): Final testing by real end-users
 Types of Testing:
o Functional Testing
o Non-functional Testing
o Regression Testing

Details on testing types and levels will follow in another video.

🚀 5. Releases

 Release = distribution of a software version

 Types of releases:
o Alpha Release:
 First functional version shared internally with select stakeholders
 May lack features and contain bugs
o Beta Release (Limited Release):
 Shared externally with users outside the dev team
 Used in real conditions to find remaining bugs
o GA (General Availability):
 Final stable version for all users
  Incorporates feedback and fixes from alpha/beta stages

📚 6. Documenting

 Helps users and developers understand and use the software

 Two documentation types:
o System Documentation (for technical users):
 Includes: README files, architecture diagrams, inline code comments,
design specs, verification steps, and maintenance guides
o User Documentation (for non-technical users):
 Includes: User guides, manuals, help videos, online and in-app help
content

More about documentation will be covered in a later video.

📝 Final Recap

 ✅ Requirements Gathering – Establish what the software must do

 Design – Translate requirements into a buildable structure
 💻 Coding for Quality – Follow clean coding practices for reliability
 🧪 Testing – Verify correctness and stability
 🚀 Releases – Alpha → Beta → General Availability
 📚 Documenting – Aid both technical and non-technical users
 Topic 6: Requirements
This video covers the requirement gathering process and three main documents used to
capture different types of software and system requirements: SRS, URS, and SysRS.

✅ Requirement Gathering Process (6 Steps)

Requirement gathering defines the problem to solve and documents how to solve it. The steps
are:

1. Identify Stakeholders
o Stakeholders = people affected by or involved in the project.
o Examples: decision-makers, end-users, admins, engineering, marketing, sales, and
support.
2. Establish Goals and Objectives
o Goals: Broad, long-term outcomes (e.g. business or customer outcomes).
o Objectives: Specific, measurable steps to achieve the goals.
3. Elicit Requirements
o Gather input using surveys, interviews, and questionnaires.
4. Document Requirements
o Must be clear, understandable, and aligned with goals/objectives.
5. Analyze and Confirm Requirements
o Ensure clarity, consistency, completeness.
o Review and approval from stakeholders.
6. Prioritize Requirements
o Use labels like:
 Must-have
 Highly desired
 Nice to have
o Order them within each category when possible.

📄 Key Documents Produced

1. SRS – Software Requirements Specification

 Most common document.

 Captures:
o What the software must do (functionalities)
o How well it must perform (benchmarks/service levels)
🔹 SRS Components:

 Purpose Statement:
o Intended use, audience, scope.
 Constraints, Assumptions & Dependencies:
o Constraints: Limitations (e.g., standards, hardware)
o Assumptions: OS, devices needed
o Dependencies: Other software or systems
 Types of Requirements:

1. Functional: Software behavior and logic

2. External Interface: Interactions with users, systems, or hardware
3. System Features: Specific functions required by the system
4. Non-Functional: Performance, security, quality, safety

2. URS – User Requirements Specification

 Describes business needs and user expectations.

 Written as:
o User Stories or Use Cases
 Answers:

1. Who is the user?

2. What function is needed?
3. Why does the user need it?
 Validated through User Acceptance Testing (UAT).
 Sometimes merged into the SRS.

3. SysRS – System Requirements Specification

 Often confused with SRS but is broader in scope.

 Includes both software and hardware requirements.

🔹 SysRS Contents:

 System capabilities and interfaces

 User characteristics
 Policy and regulatory requirements
 Personnel, performance, and security requirements
 System acceptance criteria
 Hardware and software expectations
📝 Final Recap

 📌 Requirement gathering involves:

o Identifying stakeholders
o Setting goals and objectives
o Eliciting, documenting, confirming, and prioritizing requirements
 📘 SRS: Functional, external, system, and non-functional requirements
 🧾 URS: User needs expressed as stories or use cases
 SysRS: Complete system-level specs including hardware, policies, and personnel
 Topic 7: Software Development Methodologies
This video explains three major approaches to the Software Development Life Cycle (SDLC):

 Waterfall Model
 V-Shape Model
 Agile Methodology

It also compares their workflows, advantages, and disadvantages.

📌 Purpose of Software Development Methodologies

 Help teams structure the development process

 Clarify team communication
 Define how and when information is shared

1. Waterfall Model

🔄 Structure:

 Sequential model
 Each phase must complete before the next starts
 Customer only sees the product at the testing phase

🔧 Phases:

1. Requirement Analysis
2. Design
3. Implementation
4. Testing
5. Deployment
6. Maintenance

✅ Pros:

 Simple and easy to understand

 Clear, well-defined stages
 Easier to estimate budget and timeline due to upfront planning
❌ Cons:

 Inflexible to changes in requirements

 Late visibility for customers
 Difficult to make changes once development has started

2. V-Shape Model

🔄 Structure:

 Also sequential (like Waterfall)

 Follows a V-shaped flow:
o Left side = Verification phases
o Right side = Validation phases
 Emphasizes testing early in the cycle

🪜 V-Model Phases:

 Left (Verification):
1. Planning
2. System Design
3. Architecture Design
4. Module Design
 Bottom:

o Coding
 Right (Validation):

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing

✅ Pros:

 Simple and structured

 Test plans are created early, saving time later
 Clear traceability between requirements and tests

❌ Cons:

 Very rigid and hard to adjust

 Cannot handle changing requirements easily
 Changes late in the process are expensive
3. Agile Methodology

🔄 Structure:

 Iterative and incremental model

 Development happens in short cycles called sprints (1–4 weeks)
 Each sprint ends with a sprint demo and feedback loop
 Final stage is feedback, not maintenance

⚙️Agile Practices:

 Frequent delivery of working code

 Continuous stakeholder feedback
 After several sprints, a Minimum Viable Product (MVP) is released to validate
assumptions

📜 Agile Manifesto: 4 Core Values

1. Individuals & interactions over processes & tools

2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

✅ Pros:

 Flexible to new and changing requirements

 Continuous delivery and feedback
 Encourages stakeholder and customer involvement
 Focus on working code and collaboration

❌ Cons:

 Budgeting and scheduling can be unpredictable

 Scope is not always clearly defined upfront
 Requires experienced, collaborative teams

📊 Comparison of the Three Models

Feature Waterfall V-Shape Agile

Approach Sequential Sequential + Testing Iterative & Cyclical

 Feature Waterfall V-Shape Agile

Flexibility Low Very Low High

Customer Feedback Late Late Continuous

Testing After coding Planned early In every sprint

Change Accommodation Difficult Very difficult Easy

Planning & Budgeting Predictable Predictable Challenging

Popularity Traditional projects Some regulated systems Most modern development

🧾 Final Recap

 Waterfall and V-Shape are traditional, sequential models that are simple but rigid.
 Agile is modern, flexible, and based on short development cycles and continuous
feedback.
 Agile is more adaptable to real-world software needs, though it poses challenges in
planning.
 Topic 8: Software Versions
📌 Learning Objectives

 Understand the purpose of software version numbers

 Identify version formats
 Recognize the importance of compatibility across versions

🔢 What Are Software Versions?

 Version numbers communicate important information about software.

 They help users know what version they're using.
 They help developers track changes, updates, and patches.

📈 Format of Version Numbers

 Version numbers are usually made of 2, 3, or 4 number sets separated by periods (e.g.,
1.0, 2.1.3, 18.04.2).
 Format may vary by developer or software type.

🧩 Typical Meanings in Semantic Versioning

(Semantic versioning is a common standard, though not universally used)

Position Meaning

1st Number Major changes (e.g., new features, breaking changes)

2nd Number Minor changes (e.g., small improvements or enhancements)

3rd Number Patches (e.g., bug fixes)

4th Number Build number or date (e.g., internal tracking info)

🔹 Example: 3.2.5.8 → Major version 3, minor version 2, patch 5, build 8

🧪 Beta Versions

 Versions below 1.0, like 0.9, are often in beta/testing stage.

📅 Date-Based Versioning

 Some software uses release dates in version numbers.

o Example: Ubuntu 18.04.2
 Released: April 2018
 .2 = second point release/update

🔍 Finding Version Info

 Usually found in About or Help sections of the software.

 Example for Google Chrome:
o Click the 3 dots in top-right corner
o Go to Help > About
o Chrome displays the current version

🔄 Software Compatibility

 Compatibility issues often arise between older and newer versions.

 Updating to a newer version may fix such issues.
 Some programs are backwards compatible:
o Older files/programs still work with newer software versions.

✅ Key Takeaways

 Version numbers reflect a program’s update history.

 Semantic versioning typically uses 4-part numbering (major.minor.patch.build).
 Compatibility between versions isn't always guaranteed.
 Always check your software version to troubleshoot or ensure compatibility.
 Topic 9: Software Testing

Video Summary: Software Testing

📌 Learning Objectives

 Define functional, non-functional, and regression testing

 Understand and compare the different levels of software testing

🧪 Purpose of Software Testing

 Ensures the software meets expected requirements

 Verifies that the application is error-free
 Involves creating test cases with:
o Steps
o Inputs
o Data
o Expected outputs
 Test cases are based on finalized requirements and vary by development method (e.g.,
Agile, Waterfall)

🔍 Categories of Testing

1. ✅ Functional Testing

 Focuses on functional requirements

 Uses black-box testing (no knowledge of internal code)
 Tests input-output behavior of the system under test (SUT)
 Can be manual or automated
 Ensures:
o Proper functioning of features
o Usability and accessibility
o Graceful handling of user errors and edge cases

2. 📊 Non-Functional Testing

 Focuses on attributes like:

o Performance
o Scalability
o Security
o Availability
  Verifies the SUT's behavior under different conditions:
o Load/stress handling
o Concurrent user access
o Multi-OS behavior
o Disaster recovery
o Documentation consistency

3. 🔁 Regression Testing (Maintenance Testing)

 Confirms that recent changes (e.g., bug fixes) haven’t broken existing features
 Involves re-running test cases
 Selection is based on:
o Frequent defect areas
o Frequently used features
o Recent changes
o Complex or unstable test cases

🧩 Levels of Software Testing

Each level focuses on testing at different stages of development to reduce time and avoid
redundancy.

1. 🧪 Unit Testing

 Tests individual functions/modules

 Conducted by developers
 Detects construction-level errors
 Improves code quality and development efficiency

2. 🔗 Integration Testing

 Combines unit-tested modules

 Identifies bugs in module interactions
 Uses black-box testing
 Detects issues such as:
o Logic conflicts between modules
o Communication failures
o Poor exception handling
o Unfinished or altered requirements

3. 🧷 System Testing

 Performed on a fully integrated system

  Validates against overall requirements
 Includes both functional and non-functional testing
 Conducted in a staging environment similar to production

4. ✅ Acceptance Testing

 Validates user/business requirements

 Performed by stakeholders or customers
 Confirms the system is ready for production
 Conducted during the maintenance phase

✅ Key Takeaways

 Functional testing checks core features via input-output testing

 Non-functional testing evaluates performance, security, and other attributes
 Regression testing ensures recent updates don’t break existing features
 Testing levels include unit, integration, system, and acceptance—each serving a different
purpose in SDLC
 Topic 10: Software Documentation

✅ Purpose of the Video

After watching this video, you should be able to:

 List documentation formats

 Distinguish product vs. process documentation
 Describe categories and types of documentation
 Explain the purpose of standard operating procedures (SOPs)

📘 What is Software Documentation?

Software documentation is information describing:

 What the software is

 How to use it
It can include:
 Written (e.g., manuals)
 Video (e.g., tutorials)
 Graphical (e.g., flowcharts, diagrams)

It is essential at all stages of the Software Development Life Cycle (SDLC).

👥 Documentation for Different Audiences

 End-users
 Software developers
 QA engineers
 System administrators
 Other stakeholders

📂 Main Categories of Documentation

1. Product Documentation:
o Describes how the product works
o Focuses on software functionality
2. Process Documentation:
o Describes how to complete a task
 o Ensures quality and consistent execution of processes

📄 Types of Product Documentation (5 categories)

1. Requirements Documentation
o Created in the planning phase
o Intended for developers, architects, QA
o Includes:
 Software Requirements Specifications (SRS)
 System Requirements Specifications
 User Acceptance Criteria
2. Design Documentation
o Written by software architects/developers
o Describes how software will be built
o Includes both conceptual and technical design documents
3. Technical Documentation
o Code comments
o Working papers and notes from engineers
o Helps developers understand code behavior
4. Quality Assurance (QA) Documentation
o For testing team’s strategy and progress
o Includes:
 Test plans, data, scenarios, cases, strategies
 Traceability Matrices (mapping tests to requirements)
5. User Documentation
o For end-users
o Explains how to operate, install, or troubleshoot software
o Examples:
 FAQs, Installation Guides, Tutorials, User Manuals

🧾 Standard Operating Procedures (SOPs)

 Detailed step-by-step written instructions

 Organization-specific guidance for completing complex but common tasks
 Go deeper than process overviews
 Examples:
o How to commit/merge code within an organization
 Can be in:
o Flowcharts
o Hierarchical outlines
o Step-by-step format
🔁 Maintaining Documentation

 Must be kept up to date, especially for:

o UI changes in cloud-based applications
 Updating usually occurs during maintenance phase of SDLC
 Documentation should be reviewed regularly for accuracy

📌 Key Takeaways

 Documentation formats: Written, Video, Graphical

 Process documentation: Describes how to complete a task
 Product documentation: Describes how the product works
 Product documentation includes:
o Requirements
o Design
o Technical
o QA
o User
 SOPs: Specific detailed procedures followed within an organization
 Topic 11: Roles in Software Engineering Projects

✅ Learning Objectives

After watching this video, you should be able to:

 List common roles in a software engineering project

 Describe each role
 Explain the responsibilities of each role

👥 Common Roles in a Software Engineering Project

Note: Names and responsibilities may differ based on development methodologies (Agile vs.
Waterfall) or company-specific naming.

1. Project Manager / Scrum Master

 Project Manager (Waterfall):

o Plans, schedules, and budgets
o Allocates personnel and resources
o Executes the software plan
o Ensures smooth team communication
 Scrum Master (Agile):
o Facilitates team success and communication
o Focuses on people and collaboration
o Removes obstacles and promotes Agile values

2. Stakeholder

 Represents:
o Customers, end-users, decision-makers, sysadmins
 Responsibilities:
o Define project requirements
o Provide feedback and clarification
o Participate in beta and acceptance testing

3. System / Software / Solution Architect

 Designs and communicates system architecture

  Defines internal structure and technical aspects
 Provides technical guidance throughout the SDLC

4. UX (User Experience) Designer

 Focuses on user-centered design

 Balances usability with functionality
 Defines software behavior from the end-user’s perspective
 Designs interface flow and interaction

5. Software Developer

 Implements code based on:

o Design documents
o Requirements specifications
o UX designs
 Builds functional and technical components

6. Tester / QA Engineer

 Ensures product quality and requirement compliance

 Writes and executes test cases
 Identifies and reports bugs or deficiencies
 Provides feedback to developers

7. Site Reliability Engineer (SRE) / Ops Engineer

 Bridges development and IT operations

 Tracks incidents and leads post-incident reviews
 Automates systems and processes
 Troubleshoots and ensures operational reliability

8. Product Manager / Product Owner

 Defines the product vision and roadmap

 Understands client and user needs
 Guides development to deliver stakeholder value
9. Technical Writer / Information Developer

 Creates user-friendly documentation for non-technical audiences

 Supports end-users and feedback loops
 Writes manuals, FAQs, white papers, and press releases

📌 Key Takeaways

 Software projects involve diverse roles, each with specific responsibilities

 Roles include: project manager, stakeholder, architect, UX designer, developer, tester,
SRE, product manager, and technical writer
 Effective collaboration among roles ensures successful software development
 Topic 12: Insider’s Viewpoint: Job Roles in Sotware
Engineering Team

✅ Learning Objectives

After watching this video, you should be able to:

 Understand how real-world engineering teams operate

 Identify common roles and responsibilities
 See how these roles collaborate in modern software development

👥 Key Roles Discussed & Their Responsibilities

1. Product Manager / Product Owner

 Works with sales, marketing, and stakeholders to define what needs to be built
 Aligns business goals with development priorities
 Often acts like a scrum master in Agile
 Leads standups, checks on blockers, helps resolve issues
 Provides clarity, timelines, and expectations

2. Project or Program Manager

 Supports the engineering team by:

o Setting up timelines
o Unblocking issues
o Keeping communication flowing
o Coordinating updates with stakeholders
 Helps “tie everything together” in complex projects

3. Software Engineers

 Core contributors responsible for:

o Writing code
o Translating business logic into computer logic
o Following UX designs and system architecture
 Vary in focus:
o Some specialize in architecture
o Others in coding, DevOps, infrastructure, or QA
4. Tech Lead / Senior Engineer

 Reviews code from team members

 Ensures architectural alignment
 Mentors junior developers

5. QA Engineers / Testers

 Receive completed features from developers

 Write and execute detailed test plans
 Report bugs and regressions
 Validate fixes and perform re-tests
 May specialize in test automation and CI/CD pipeline testing

6. UX Designers / UX Engineers

 Use tools like Figma to create:

o Interface specs
o Interactive mockups
o Wireframes
 Work closely with engineers to:
o Ensure design fidelity
o Iterate on user interfaces
 May collaborate with UX researchers for user feedback and usability studies

7. Site Reliability Engineers (SREs) / System Admins

 Handle:
o Deployment
o Monitoring
o Infrastructure reliability
 Collaborate with engineers to ensure smooth production releases
 Manage automation and incident resolution

🤝 Collaboration & Workflow Insights

  Most effective teams work collaboratively, not in silos
 Standups, group chats, and brainstorming sessions help cross-functional alignment
 Engineers don’t work alone—they constantly interact with other roles
 Close feedback loops improve code quality, user satisfaction, and delivery speed

📌 Key Takeaways

 Real software development is a team effort involving multiple specialized roles

 Common roles include product managers, tech leads, UX designers, developers, QA, and
SREs
 Communication and collaboration are essential for successful delivery
 Agile practices, such as regular check-ins and iterative development, support this
collaboration
 Summary & Highlights

Congratulations! You have completed this module. At this point, you know:

 Software engineering is the application of scientific principles to the design and creation
of software.
 Responsibilities of a software engineer include designing, building, and maintaining
software systems.
 Using the SDLC can improve efficiency and reduce risks by:
 letting team members know what they should be working on and when
 facilitating communication between the customer, other stakeholders, and the
development team
 letting stakeholders know where they fit into that process and
 letting cross-domain teams know when they have completed their tasks so development
can move to the next phase.
 Common software engineering processes are requirements gathering, design, coding,
testing, releasing, and documenting.
 The requirement gathering process entails identifying stakeholders, establishing goals
and objectives, eliciting requirements from the stakeholders, documenting the
requirements, analyzing, prioritizing, and confirming the requirements.
 An SRS is a document that captures the functionalities that the software should perform
and also establishes benchmarks or service levels for its performance.
 A URS is a subset of the SRS that details user specification requirements.
 The SysRS contains the same information as an SRS, but can also additionally include
system capabilities, interfaces, and user characteristics, policy requirements, regulation
requirements, personnel requirements, performance requirements, security
requirements, and system acceptance criteria.
 Waterfall, V-shape model, and agile are all different methodologies for implementing the
software development life cycle.
 Functional testing is concerned with inputs and corresponding outputs of the system
under test, non-functional testing tests for attributes such as performance, security,
scalability, and availability. Whereas regression testing confirms that a recent change to
the application, such as a bug fix, does not adversely affect already existing
functionality.
 Types of documentation include requirements, design, technical, quality assurance, and
user.
 There are many different roles involved in a software engineering project. Some of them
include project manager or scrum master, stakeholder, system or software architect, UX
designer, software developer, tester or QA engineer, site reliability or Ops engineer,
product manager or owner, and technical writer or information developer.