BCSE301L

Software Engineering
Module 1

Dr. Priyanka N
Software - Definition
• Software is defined as the tool with designated order of
instructions, performing tasks to provide the desired results after
obtaining the requirements of the users.
• It also consists of procedures, rules, software- related documents and
the associated basic data required to run

Software = Computer Programs (Instructions) + Procedures + Rules +

Associated documents + Data
Nature of Software - Characteristics
➢ Intangibility: Software cannot be physically touched or perceived by
our senses. It exists as code and data, residing within the memory
and storage devices of a computer.

➢ Complexity: As software systems grow in size and functionality,

they become increasingly complex. This complexity arises from the
intricate interplay of numerous components and their interactions.
Nature of Software - Characteristics
➢ Conformity: Software must conform to specific hardware and
software platforms. It needs to be compatible with the operating
system, programming languages, and other software components it
interacts with.

➢ Changeability: Software is highly malleable and can be modified or

extended relatively easily. This flexibility allows for continuous
improvement and adaptation to changing requirements.
Nature of Software - Characteristics
➢ Invisibility: The internal workings of software are often hidden from
view. Users interact with the software's output, but the underlying
code and algorithms remain invisible.
Nature of Software – Comparing to Hardware
➢ Software is developed or engineered; it is not manufactured
➢ Software doesn’t wear out. But Undiscovered defects will cause high
failure rates early in the life of a program.
➢ Although the industry is moving toward component-based
construction, most software continues to be custom built.
Nature of Software – Comparing to Hardware
The curve is divided into three distinct phases:
1. Early Failure Period — “Infant Mortality”
• The failure rate is initially high.
• Failures occur due to:
• Manufacturing defects, Poor workmanship, Early design flaws
• Over time, weak components fail and are removed → failure rate
decreases.

2. Useful Life Period — “Normal Operation”

• Failure rate is low and constant.
• Equipment performs reliably during this phase.
• Causes of failures:
• Random and unpredictable issues
• External stresses or accidental damage
• This is the desired operational phase for most products.

3. Wear-Out Period
• As time increases, failure rate rises sharply again.
• Occurs due to:
• Aging
Failure curves for Hardware • Fatigue
• Material degradation
• Components reach their end of life.
Nature of Software – Comparing to Hardware
This diagram shows how making changes or repairs to
a system can unintentionally increase the failure rate.

Key Idea
• The idealized curve (bottom line) represents how we
expect failure rate to decrease smoothly over time.

• The actual curve (top line) shows what often happens

in reality:
• When a change, upgrade, or repair is made → new
issues or side effects appear.
• This causes spikes in failure rate.
• The cycle of repair → new failures → repair
repeats.
Failure curves for software
Nature of Software – Application Domain
System Software

Web Application

Embedded Software

Mobile Software

Engineering/Scientific

Artificial Intelligence

Data Science Applications

Nature of Software - Characteristics
➢ Implications of Software nature
➢ Challenges in Development: The intangible and complex nature of software
makes it challenging to predict and manage development efforts accurately.
➢ Quality Assurance: Ensuring the quality and reliability of software requires
rigorous testing and debugging processes.

➢ Intellectual Property: Software is often protected by copyright laws to

safeguard the rights of its creators.
➢ Maintenance and Evolution: Software requires ongoing maintenance and
updates to address bugs, security vulnerabilities, and evolving user needs.
Software Engineering - Definition

• The application of a systematic, disciplined, quantifiable approach

to the development, operation and maintenance of software; that
is, the application of engineering to software.

• The study of these approach is Software Engineering

Software Engineering
• Software engineering is an engineering discipline that
is concerned with all aspects of software production from the
early stages of system specification through to
maintaining the system after it has gone into use.
➢ Engineering Discipline - apply theories, methods, and tools
➢ All aspects of software production - Technical processes,
Planning, budgeting, Managing, manpower, development of tools,
methods, and theories
Software Engineering – A layered Approach
Software Engineering – A layered Approach
1. A Quality Focus (Foundation Layer)
• Quality is the base of everything in software engineering.
• Ensures the final product meets customer expectations, is reliable, secure,
maintainable, etc.
• All other layers must keep quality in mind.

2. Process
• Defines how the software will be developed.
• Includes activities such as:
• Planning,
• Requirement analysis,
• Design,
• Testing,
• Maintenance
• A well-defined process ensures consistency and improves productivity.
Software Engineering – A layered Approach
3. Methods
• Describe technical steps to build the software.
• Methods include Programming techniques, Design models
(UML, DFDs), Analysis methods, Testing methods
• They tell how tasks should be performed within the
process.

4. Tools (Top Layer)

• Software applications that automate or support methods
and processes.
• Examples: IDEs (VS Code, Eclipse), Version control (Git),
Testing tools (Selenium), Project management tools (Jira)
Software Process
➢ A software process is a sequence of activities, actions and tasks that
leads to the production of a software product.
▪ An activity strives to achieve a broad objective (e.g.,
communication with stakeholders)
▪ An action (e.g., architectural design) encompasses a set of tasks
that produce a major work product (e.g., an architectural design
model).
▪ A task focuses on a small, but well-defined objective (e.g.,
conducting a unit test) that produces a tangible outcome.
Software Process – Fundamental Activities
➢ Software specification: Customers and engineers define the
software that is to be produced and the constraints on its
operation.

➢ Software development: The software is designed and

programmed.

➢ Software validation: The software is checked to ensure that it

is what the customer requires.

➢ Software evolution: The software is modified to reflect

changing customer and market requirements.
Software Process – Framework
➢ A process framework is like a basic blueprint for building software.
➢ It outlines the main steps or activities needed for any software
project, no matter how big or small.
➢These main steps are called framework activities.

➢ In addition to these main steps, there are also umbrella activities

(supporting activities) that apply to the entire software development
process.
➢These umbrella activities help to manage and control the project as a
whole.
Software Process – Framework
• A process framework establishes the
foundation for a complete software
process by identifying a small number
of framework activities that are
applicable to all software projects,
regardless of size or complexity.

• It also includes a set of umbrella

activities that are applicable across
the entire software process.
Software Process – Generic Framework Activities
Some most applicable framework activities are described below.

Communication Planning Modelling Construction Deployment

• Understanding • Create a • Create models • Code • Deliver

Stakeholder Software Project to understand Generation software to the
Requirements Plan software • Testing customer
• Gather • Define requirements • Evaluate
Requirements Technical tasks, and design customer
risks, resources feedback
and work
products
Software Process – Umbrella Activities
Project Assess project progress against the plan
Tracking and
Control: Take corrective actions to maintain the schedule
Risk Identify and assess project risks
Management:

Quality Define and conduct quality assurance activities

Assurance:

Technical Review software work products to find and fix errors

Reviews:
Software Process – Umbrella Activities
Measurement: Define and collect project metrics
Use metrics to improve the process
Configuration Manage changes to the software
Management:

Reusability Identify and reuse software components

Management:

Work Product Create software work products (models, documents,

Production:
etc.)
Software Process – Activities Flow Pattern
The 4Ps Constituting Software Engineering
People
• Project stakeholders

Product
• The software product plus associated documents.

Project
• The activities carried out to produce the product.

Process
• Framework within which the team carries out the activities necessary to
build the product.
The 4Ps Constituting Software Engineering
People Product Project Process

• Business Management • Project documentation • Planning - Plan, • Framework Activities

People -Documents produced monitor, and control • Umbrella Activities
• Project Management during software the software project.
People definition and • Requirements analysis
• Development Team development. - Define what to build.
members • Code - Source and • Design - Describe how
• Customers object. to build the software.
• Vendors • Text documents - • Implementation -
Plans, cases, and Program the software.
• End Users
results. • Testing - Validate that
• Customer documents - software meets the
Documents explaining requirements.
how to use and • Maintenance - Resolve
operate product. problems; adapt
• Productivity software to meet new
measurements - requirements.
Analyse project
productivity.
The Process Models
• Details the Software Development Process

• Provides a Visual representation of Development

• Process Helps Efficient development of software a framework that

outlines the stages, activities, and tasks structured approach
to software development projects are completed on time, within
budget Satisfies the required quality standards.
The Process Models – Waterfall Model
The Process Models – Waterfall Model
➢ Characteristics
➢ Linear and Sequential: Each phase is completed before moving on to the
next one.
➢ Predictive: Requirements are gathered and defined before the project begins.
➢ Phased: The project is divided into distinct phases.
The Process Models – Waterfall Model
➢ Phases of the Waterfall Model
➢ Requirements Gathering: Collect and document requirements from stakeholders.
➢ Analysis: Analyze the requirements to identify the project's scope and constraints.
➢ Design: Create a detailed design of the software, including architecture,
components, and interfaces.

➢ Implementation: Write the code for the software.

➢ Testing: Test the software to identify and fix defects.
➢ Deployment: Deploy the software to production.

➢ Maintenance: Maintain and update the software after deployment.

The Process Models – Waterfall Model
➢ Advantages
➢ Easy to Manage: The linear and sequential approach makes it easy to manage and
understand.
➢Well-defined Phases: Each phase has a clear set of deliverables and expectations.
➢Predictable Timelines: The predictive nature of the model allows for accurate timeline
estimation.

➢ Disadvantages
➢Inflexible: Changes to requirements can be difficult and costly to implement.
➢High Risk: If requirements are not properly understood or defined, the project may fail.
➢Long Development Time: The sequential approach can lead to long development times.
The Process Models – Prototyping Model
The Process Models – Prototyping Model
➢ Characteristics
➢ Iterative: The prototyping process is iterative, with each iteration refining the
prototype.
➢ Flexible: The prototyping model allows for changes in requirements and
design.

➢ Risk Reduction: Prototyping helps to reduce the risk of project failure by

identifying and addressing potential issues early.
The Process Models – Prototyping Model
➢ Phases of the Prototyping Model
➢ Requirements Gathering: Identify the basic requirements of the software
application.
➢ Quick Plan: Create a rough plan for the prototype.
➢ Prototype Development: Build a working prototype of the software
application.
➢ User Feedback: Gather feedback from users on the prototype.
➢ Refine Prototype: Refine the prototype based on user feedback.
➢ Repeat: Repeat the process until the prototype meets the requirements.
The Process Models – Prototyping Model
➢ Advantages
➢Improved Requirements: Prototyping helps to identify and refine requirements.
➢Reduced Risk: Prototyping reduces the risk of project failure.
➢ Increased User Satisfaction: Prototyping ensures that the final product meets user
requirements.

➢ Disadvantages
➢Time-consuming: Prototyping can be time-consuming, especially if multiple iterations are
required.
➢Expensive: Prototyping can be expensive, especially if a large team is involved.
➢ May Not Be Suitable for Large Projects: Prototyping may not be suitable for large projects
with complex requirements.
The Process Models – Incremental Model
The Process Models – Incremental Model
➢ Characteristics
➢ Evolutionary: The incremental model involves multiple evolution, with each
iteration adding new features or functionality.
➢ Incremental: The software application is developed in increments, with each
increment building on the previous one.

➢ Flexible: The incremental model allows for changes in requirements and

design.
The Process Models – Incremental Model
➢ Phases of the Incremental Model
➢ Requirements Gathering: Identify the overall requirements of the software
application.
➢ System Design: Create a high-level design of the software application.
➢ Incremental Development: Develop the software application in increments,
with each increment adding new features or functionality.
➢ Testing: Test each increment to ensure that it meets the requirements.
➢ Integration: Integrate each increment into the overall software application.
➢ Repeat: Repeat the process until the software application is complete.
The Process Models – Incremental Model
➢Advantages
➢ Early Delivery: The incremental model allows for early delivery of a working software application.
➢ Reduced Risk: The incremental model reduces the risk of project failure by breaking the project into smaller,
more manageable increments.
➢ Improved Quality: The incremental model allows for testing and integration of each increment, improving
the overall quality of the software application.

➢Disadvantages
➢ Higher Cost: The incremental model can be more expensive than other models, as it requires multiple
iterations and testing.
➢ Requires Good Planning: The incremental model requires good planning and coordination to ensure that
each increment is properly integrated into the overall software application.
➢ May Not Be Suitable for Large Projects: The incremental model may not be suitable for large projects with
complex requirements.
The Process Models – Spiral Model
The Process Models – Spiral Model
➢ Characteristics
➢ Iterative & Evolutionary: The Spiral Model involves multiple iterations, with
each iteration refining the software application.
➢ Incremental: The software application is developed in increments, with each
increment building on the previous one.

➢ Risk-driven: The Spiral Model emphasizes risk management and mitigation.

➢ Flexible: The Spiral Model allows for changes in requirements and design.
The Process Models – Spiral Model
➢ Phases of the Spiral Model
➢ Planning: Identify the objectives, constraints, and risks of the project.
➢ Risk Analysis: Analyze the risks associated with the project and develop
strategies to mitigate them.
➢ Engineering: Develop the software application, including design,
implementation, and testing.
➢ Evaluation: Evaluate the software application and identify areas for
improvement.
➢ Repeat: Repeat the process until the software application meets the
requirements.
The Process Models – Spiral Model
➢ Advantages
➢ Risk Management: The Spiral Model emphasizes risk management and
mitigation.
➢ Flexibility: The Spiral Model allows for changes in requirements and design.
➢ Improved Quality: The iterative and incremental approach of the Spiral
Model results in improved quality.
➢ Reduced Risk: The Spiral Model reduces the risk of project failure by
identifying and mitigating risks early.
The Process Models – Spiral Model
➢ Disadvantages
➢ Complexity: The Spiral Model can be complex and difficult to
manage.
➢ High Cost: The Spiral Model can be expensive, as it requires
multiple iterations and risk analysis.

➢ Requires Skilled Resources: The Spiral Model requires skilled

resources, including risk management and software development
expertise.
The Process Models – RAD Model
Team n
Team 2
Team 1
The Process Models – RAD Model
➢ Characteristics
➢ Rapid Development: The RA D Model emphasizes rapid development and
delivery of a software application.
➢ Iterative: The RA D Model involves multiple iterations, with each iteration
refining the software application.

➢ Incremental: The software application is developed in increments, with each

increment building on the previous one.
➢ User Involvement: The RA D Model emphasizes user involvement and
feedback throughout the development process.
The Process Models – RAD Model
➢ Phases of the R AD Model
➢ Business Modeling:
➢ Business processes and information flow are analyzed to identify the core business

requirements.
➢ Stakeholders and developers collaborate to create a high-level overview of what the
system will do.
➢ Data Modeling:

➢ Information derived from business modeling is refined into data objects (entities).
➢ Relationships between data objects are defined, establishing a clear data structure.
The Process Models – RAD Model
➢ Phases of the R A D Model
➢Process Modeling:
➢ Data objects and their relationships are used to define the processes (functions) that manipulate data.
➢ These processes are refined iteratively for greater clarity and alignment with user requirements.
➢Application Generation:
➢ Actual coding and development occur.
➢ Tools like C ASE (Computer-Aided Software Engineering) are often used to automate code generation,
speeding up development.
➢Testing & Turnover:
➢ Components are tested independently and integrated into the system.
➢ Bugs are identified and resolved rapidly.
➢ A working product is delivered for review and feedback.
The Process Models – RAD Model
➢ Advantages
➢ Rapid Development: The R AD Model enables rapid development and
delivery of a software application.
➢ Improved User Satisfaction: The R A D Model emphasizes user involvement
and feedback, resulting in improved user satisfaction.

➢ Flexibility: The R A D Model allows for changes in requirements and design.

➢ Reduced Risk: The R AD Model reduces the risk of project failure by
involving users throughout the development process.
The Process Models – RAD Model
➢ Disadvantages
➢ High Cost: The R AD Model can be expensive, as it requires rapid
development and deployment.
➢ Requires Skilled Resources: The R AD Model requires skilled
resources, including developers, designers, and testers.
➢ May Not Be Suitable for Large Projects: The R AD Model may not
be suitable for large projects with complex requirements.
The Process Models – V Model
The Process Models – V Model
➢ Characteristics
➢ Sequential & Parallel Phases: The V-Model consists of sequential phases,
with each phase building on the previous one.
➢ Testing Emphasis: The V-Model places a strong emphasis on testing, with
testing activities integrated throughout the development process.

➢ Verification and Validation: The V-Model includes verification and

validation activities to ensure that the software meets the requirements.
The Process Models – V Model - Phases
➢ Business requirement analysis: This is the first step where product
requirements understood from the customer's side. This phase contains detailed
communication to understand customer's expectations and exact requirements.
➢ System Design: In this stage system engineers analyze and interpret the
business of the proposed system by studying the user requirements document.
➢ Architecture Design: The baseline in selecting the architecture is that it should
understand all which typically consists of the list of modules, brief functionality
of each module, their interface relationships, dependencies, database tables,
architecture diagrams, technology detail, etc. The integration testing model is
carried out in a particular phase.
The Process Models – V Model - Phases
➢ Module Design: In the module design phase, the system breaks
down into small modules. The detailed design of the modules is
specified, which is known as Low-Level Design
➢ Coding Phase: After designing, the coding phase is started. Based on
the requirements, a suitable programming language is decided. There
are some guidelines and standards for coding. Before checking in the
repository, the final build is optimized for better performance, and
the code goes through many code reviews to check the performance.
The Process Models – V Model - Phases
➢ There are the various phases of Validation Phase of V-model:
➢ Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed
during the module design phase. These UTPs are executed to eliminate
errors at code level or unit level. A unit is the smallest entity which can
independently exist, e.g., a program module. Unit testing verifies that the
smallest entity can function correctly when isolated from the rest of the
codes/ units.
➢ Integration Testing: Integration Test Plans are developed during the
Architectural Design Phase. These tests verify that groups created and
tested independently can coexist and communicate among themselves.
The Process Models – V Model - Phases
➢ System Testing: System Tests Plans are developed during System Design
Phase. Unlike Unit and Integration Test Plans, System Tests Plans are
composed by the client’s business team. System Test ensures that
expectations from an application developer are met.
➢ Acceptance Testing: Acceptance testing is related to the business
requirement analysis part. It includes testing the software product in user
atmosphere. Acceptance tests reveal the compatibility problems with the
different systems, which is available within the user atmosphere. It
conjointly discovers the non-functional problems like load and
performance defects within the real user atmosphere.
The Process Models – V Model
➢ Advantage (Pros) of V-Model:
➢ Easy to Understand.
➢ Testing Methods like planning, test designing happens well before coding.
➢ This saves a lot of time. Hence a higher chance of success over the waterfall
model.

➢ Avoids the downward flow of the defects.

➢ Works well for small plans where requirements are easily understood.
The Process Models – V Model
➢ Disadvantage (Cons) of V-Model:
➢ Very rigid and least flexible.
➢ Not a good for a complex project.
➢ Software is developed during the implementation stage, so no early
prototypes of the software are produced.

➢ If any changes happen in the midway, then the test documents along with the
required documents, has to be updated.
The Process Models – Agility
➢ Agility in Software Engineering refers to the ability to adapt and
respond quickly to changes throughout the software development
lifecycle.
➢ It emphasizes flexibility, collaboration, and continuous improvement to
deliver high-quality software efficiently.
The Process Models – Agile Process Model
➢ Key Characteristics of Agile Methods
➢ Iterative Development:
➢ System is developed in small increments.
➢ Each increment is delivered and evaluated by users.
➢ Feedback from users is used to refine future increments.
➢ Minimal Documentation:
➢Focus on code and working software over extensive documentation.
➢Informal communication is preferred over formal meetings and written
documents.
The Process Models – Agile Process Model
➢ Key Characteristics of Agile Methods
➢ Customer Involvement:
➢ Customers are actively involved in the development process.
➢ They provide feedback and prioritize requirements.

➢ Flexible Process:
➢ The process is adaptable to changing requirements and circumstances.
➢ It emphasizes responding to change over following a rigid plan.
The Process Models – Agile Process Model
➢ Key Characteristics of Agile Methods
➢ Continuous Testing:
➢ Testing is integrated into the development process.
➢ Automated testing tools are used to ensure quality and reliability.

➢ Tool Support:
➢ Tools are used to automate various aspects of the development process.
➢ This includes version control, build automation, and testing tools.
The Process Models – Agile Process Model
Features Plan-Driven Model Agile Process Model
Process Model Linear Flow Iterative and Evolutionary
Detailed Requirements
Requirements Evolving and Emerging
Upfront
Documentation Extensive Minimal
Customer Involvement Limited High
Risk Management Proactive Reactive
Predictability and Adaptability and
Focus
Control Flexibility
The Process Models – Principles of Agile Methods
1. Customer Early and continuous delivery of valuable Software
Satisfaction

2. Embrace Welcome changing requirements, even late in development.

Change

3. Frequent Deliver working software frequently, preferably in short

Delivery cycles

4. Foster daily collaboration between businesspeople and

Collaboration developers.
The Process Models – Principles of Agile Methods
5. Empowered Build projects around motivated individuals and trust them
Individuals

6. Face-to-Face Prioritize face-to-face communication for effective

Communicati information exchange.
on:

7. Working Prioritize working software as the primary measure of

Software progress.

8. Sustainable Promote sustainable development, avoiding excessive work

Development hours.
The Process Models – Principles of Agile Methods
9. Technical Continuously focus on technical excellence and good design.
Excellence

10. Simplicity: Embrace simplicity, avoiding unnecessary complexity.

11. Self- Empower self-organizing teams to make decisions.

Organizing
Teams:

12. Regularly reflect on team effectiveness and make adjustments.

Continuous
Reflection
The Process Models –Agile Method
The Process Models –Agile Method – Extreme Programming (XP)
The Process Models –Agile Method – XP Principles
XP Principle /
Description
Practice
Collective All developers share responsibility for the entire code. Anyone
Ownership can modify any part of the system.
Continuous Code is added to the main system frequently, and all tests must
Integration pass after each integration.
Incremental Work is planned in small parts using story cards. Important
Planning features are developed first.
A customer representative stays with the team to give
On-site Customer
requirements and clarify doubts immediately.
Two developers work together at one computer to reduce
Pair Programming
errors and improve code quality.
The Process Models –Agile Method – XP Principles
XP Principle /
Description
Practice
Developers regularly improve and clean the code without
Refactoring
changing what it does, so it stays simple and easy to maintain.
Design only what is needed right now; avoid adding extra
Simple Design
features or complexity.
Deliver small, useful parts of the software frequently instead of
Small Releases
waiting for a big release.
Developers should work at a steady speed without too much
Sustainable Pace
overtime to maintain quality and productivity.
Test-First Tests are written before the actual code to ensure the software
Development works correctly from the start.
The Process Models –Agile Method – Extreme Programming (XP)

➢ Select User Stories for This Release:

➢ The development team, in collaboration with the customer, selects a set of
user stories to be implemented in the current release.
➢ User stories are high-level descriptions of the desired features or
functionalities from the customer's perspective.

➢ Break Down Stories to Tasks:

➢ Each selected user story is broken down into smaller, more manageable tasks.
➢ These tasks are assigned to developers, who estimate the effort required to
complete them.
The Process Models –Agile Method – Extreme Programming (XP)

➢ Plan Release:
➢ Based on the selected user stories and estimated tasks, a release plan is created.
➢ The plan outlines the timeline, milestones, and resource allocation for the release.

➢ Develop, Integrate, and Test Software:

➢ Developers work in pairs (pair programming) to write code, with a focus on test-
driven development (TDD).
➢ Code is integrated into the main codebase frequently, and automated tests are run to
ensure quality.
The Process Models –Agile Method – Extreme Programming (XP)

➢ Release Software:
➢ Once the development and testing phases are complete, the software is released to
the customer.
➢ The customer evaluates the released software and provides feedback for the next
iteration.

➢ Evaluate System:
➢ The development team and the customer evaluate the released software to identify
any issues or areas for improvement.
➢ Feedback from the customer is used to refine future releases.
The Process Models –Agile Method – Extreme Programming (XP)

➢ Workflow Cycle:
➢ Customer Defines User Stories: Customers describe what they need in simple,
understandable terms.
➢ Developers Estimate and Plan: Developers estimate the time and effort
required for each story and plan iterations accordingly.

➢ Build Iterations:
➢Write automated tests (TDD).
➢Pair program and write code to pass tests.
➢Refactor to improve the codebase.
➢Integrate and test frequently.
The Process Models –Agile Method – Extreme Programming (XP)

➢ Deliver and Review:

➢ At the end of each iteration, deliver working software to the customer.
➢ Gather feedback and adapt for the next iteration.
The Process Models –Agile Method – SCRUM

➢ Scrum is an Agile framework for managing and completing

complex software development projects.
➢It focuses on delivering high-value, high-quality software through
collaboration, adaptability, and iterative development.
➢ Scrum divides work into sprints (time-boxed iterations, typically 1–4
weeks), where a specific set of goals or deliverables is
planned, developed, tested, and delivered incrementally.
The Process Models –Agile Method – SCRUM Terminologies
Scrum Term Definition
A small group of people (usually up to 7) who actually
Development Team build the software and prepare required project
documents.
• The working part of the software created at the end of
Potentially Shippable a sprint.
Product Increment • It should be complete and ready to be released if
needed.
A list of all work that needs to be done in the project, like
Product Backlog
features, requirements, improvements, and fixes.
The person who decides what features are needed, sets
Product Owner priorities, and makes sure the product meets business or
customer needs.
The Process Models –Agile Method – SCRUM Terminologies

Scrum Term Definition

Scrum (Daily A short daily meeting where the team discusses what was
Scrum) done, what will be done today, and any problems.
The person who helps the team follow Scrum rules,
Scrum Master removes obstacles, and protects the team from outside
disturbances.
A fixed time period (usually 2–4 weeks) in which the team
Sprint
develops part of the product.
• A measure of how much work a team can complete in
Velocity one sprint.
• It helps in planning future work.
The Process Models –Agile Method – SCRUM Workflow
The Process Models –Agile Method – SCRUM Workflow
1. Review work to be done
• The team looks at all the work that needs to be completed.
• This work is stored in the Product Backlog.

2. Select items
• The team selects important items from the Product Backlog.
• Only the work that can be finished in the next sprint is chosen.

3. Plan sprint
• The team plans how to do the selected work.
• Tasks are created and placed in the Sprint Backlog.

4. Sprint
• The team works on the planned tasks for a fixed time (usually 2–4 weeks).
• Daily Scrum meetings are held to track progress.
The Process Models –Agile Method – SCRUM Workflow

5. Potentially shippable software

• At the end of the sprint, a working part of the software is produced.
• It is ready to be delivered if needed.

6. Review sprint
• The team and stakeholders review what was completed.
• Feedback is collected.

7. Repeat the cycle

• Based on feedback, the Product Backlog is updated.
• The process starts again for the next sprint.
The Process Models –Agile Method – SCRUM Scaling
The Process Models –Reuse Oriented Software Engineering

• Reuse-Oriented Software Engineering is a process

model where existing software components are
reused to build new software instead of developing
everything from scratch.
• It means using already available software parts, such as:
• Libraries
• Frameworks
• APIs
• Existing applications
• Reusable components
The Process Models –Reuse Oriented Software Engineering
The Process Models –Reuse Oriented Software Engineering
Step Descriptions
1. Requirements
Identify what the new software should do.
specification
2. Component Search for existing components that can meet the
analysis requirements.
3. Requirements Adjust requirements to match available reusable
modification components.
4. System design with
Design the system by integrating selected components.
reuse
5. Development &
Combine reused components with new code if needed.
integration
6. System testing Test the complete system to ensure it works correctly.
The Process Models –Reuse Oriented Software Engineering

Advantages
• Saves time and cost
• Improves software quality
• Reduces development effort
• Faster delivery

Disadvantages
• Exact match components may not exist
• Limited flexibility
• Dependency on third-party components
The Process Models –Crystal (Agile)

What is Crystal?
• Crystal is an Agile software development methodology
proposed by Alistair Cockburn.

• It focuses on people, interaction, and communication

rather than heavy processes or tools.

• Crystal is not a single method — it is a family of methods,

chosen based on:
❑Team size
❑System criticality
The Process Models –Crystal (Agile)

Why is it called Crystal?

• Like crystals have different colors and shapes, Crystal
methods vary depending on project needs.

• Examples:
❑ Crystal Clear – Small teams
❑ Crystal Yellow
❑ Crystal Orange
❑ Crystal Red – Larger, more critical systems
The Process Models –Crystal (Agile)
Crystal Color Summary Table
Crystal Team Process
Risk Level Used
Type Size Weight
Small applications, Startup projects,
Clear 2–8 Low Very Light
Classroom / student projects
Medium business applications, Multiple
Yellow 10–20 Medium Light
developers need coordination
Defined roles, More planning, Stronger
Orange 20–50 High Medium testing, Formal reviews

Heavy testing, Strict documentation,

Red 50+ Very High Heavy Strong governance, Formal risk
management
The Process Models –Crystal (Agile)

Key Characteristics of Crystal

• People-centered approach
• Frequent delivery of working software
• Face-to-face communication preferred
• Minimal documentation
• Continuous improvement through reflection
The Process Models –Crystal (Agile)
The Process Models –Crystal (Agile)
Core Principles of Crystal

• Frequent Delivery - Deliver working software regularly.

• Osmotic Communication - Team members learn by
being close and communicating informally.
• Reflective Improvement - Regular meetings to improve
the process.
• Personal Safety - Team members feel safe to share
ideas and issues.
• Focus on Skill & Talent - Emphasizes skilled people
over strict rules.
The Process Models –Crystal (Agile)

Advantages of Crystal

• Lightweight and flexible

• High productivity
• Encourages teamwork and communication
• Easy to adapt to changes
The Process Models –Crystal (Agile)

Disadvantages of Crystal

• Not suitable for very large or distributed teams

• Depends heavily on skilled team members
• Less documentation (may be risky for some projects)
Overview of system engineering

• Systems Engineering is an interdisciplinary

approach used to design, develop, integrate, and
manage complex systems over their entire life
cycle.

• It focuses on the whole system, not just individual

parts, ensuring that all components work together to
meet user and business needs.
Why is Systems Engineering Needed?

• Handles complexity
• Reduces risk and failures
• Ensures requirements are met
• Improves quality, reliability, and performance
• Manages cost, schedule, and resources
Key Activities in Systems Engineering
Phase Description
Requirement Analysis Understand what the system must do
System Design Define architecture and components
Implementation Build system components
Integration Combine components into a system
Testing & Verification Check system works as required
Deployment Deliver system to users
Operation &
Support and improve the system
Maintenance
Retirement Safely remove the system
Role of a Systems Engineer
A systems engineer:
• Coordinates between teams
• Manages requirements
• Ensures integration
• Balances performance, cost, and schedule
• Solves system-level problems
Overview of systems Engineering
Commonly represented using the V-Model: