Software Engineering Notes

UNIT 2

There are for main activities of software development

 Software specification
 Software design and implementation
 Software verification and validation
 Software evolution

Software development life cycle

 Communication
 Requirement gathering
 Feasibility study
 System analysis
 Software design
 Coding
 Testing
 Integration
 Implementation
 Operations and maintenance
 Disposition

Waterfall model of software engineering:

The Waterfall Model is a traditional software development methodology that follows a linear
and sequential approach. Each phase must be completed before moving to the next, and there
is little to no overlap between phases.

Phases of the Waterfall Model:

1. Requirement Analysis – Gather and document all system requirements.

2. System Design – Plan the architecture, system structure, and technology stack.

3. Implementation (Coding) – Developers write the actual code based on the design.
 4. Testing – The software is tested for bugs, errors, and defects.

5. Deployment – The completed software is delivered to users.

6. Maintenance – Updates, bug fixes, and modifications after deployment.

Advantages:

Simple and easy to understand.

Well-documented process with clear stages.
Works well for small projects with well-defined requirements.

Disadvantages:

Rigid and inflexible (hard to go back to a previous phase).

Not suitable for projects with evolving requirements.
Late testing phase increases risks of discovering major issues too late.

The Waterfall Model is best suited for projects where requirements are clear and stable from
the beginning. If requirements are likely to change, Agile methodologies are often preferred.

The V-Model (Verification and Validation Model) is a software development lifecycle (SDLC)
model that extends the Waterfall Model by emphasizing testing at each stage of development.
It is also called the Validation and Verification Model because each development phase has a
corresponding testing phase.

Phases of the V-Model

The V-Model is structured in a "V" shape, with development phases on the left and testing
phases on the right.

1. Verification Phase (Left Side of the "V")

Requirement Analysis – Gather and define system requirements.

System Design – Plan the system architecture.
software Design – Define system modules and their interactions.
module design – Detail individual components and functions.
Coding – Developers write and integrate the code.

2. Validation Phase (Right Side of the "V")

Unit Testing – Test individual components (corresponds to LLD).

Integration Testing – Test interactions between modules (corresponds to HLD).
System Testing – Verify the whole system functions correctly (corresponds to System Design).
Acceptance Testing (AT) – Ensure the final product meets user requirements (corresponds to
Requirement Analysis).

Advantages of V-Model

Early defect detection due to testing at each phase.

Well-structured and organized approach.
Clear traceability between development and testing.

Disadvantages of V-Model

Rigid and inflexible, similar to the Waterfall Model.

High cost of changes if requirements evolve later.
Not suitable for dynamic projects where changes are frequent.

The V-Model is best for projects with well-defined, stable requirements and high reliability
needs (e.g., medical software, aerospace, and banking systems).

Prototype Model in Software Development

The Prototype Model is an iterative software development approach where a working

prototype (a simplified version of the final product) is built before the actual system. It helps in
understanding user requirements better and refining the system based on feedback.

Phases of the Prototype Model

1. Requirement Gathering – Basic requirements are collected but not fully detailed.

2. Quick Design – A rough system design is created to outline the prototype.

3. Prototype Development – A working prototype is built with limited functionality.

4. User Evaluation – Users test the prototype and provide feedback.

5. Refinement – The prototype is refined based on feedback, and this cycle repeats until a
satisfactory version is reached.

6. Final Development – After the prototype is approved, the actual system is developed.

Types of Prototypes

Throwaway Prototype – Discarded after gathering requirements, and final development starts
from scratch.
Evolutionary Prototype – Improved over multiple iterations and eventually becomes the final
product.
Incremental Prototype – Different system parts are prototyped and combined later.
Extreme Prototype – Used in web development, with frontend and backend developed in
parallel.

Advantages of the Prototype Model

Better understanding of requirements through real-time feedback.

Reduces risk of project failure due to miscommunication.
User involvement improves satisfaction and usability.
Faster development in projects where requirements are unclear.

Disadvantages of the Prototype Model

Time-consuming if too many iterations are needed.

Higher cost due to repeated modifications.
Scope creep risk, as users may request continuous changes.

Best Use Cases

The Prototype Model is ideal for projects with evolving or unclear requirements, such as:

 UI/UX-focused applications

 Customer-facing software

 Innovative and experimental projects

These are different software development life cycle (SDLC) models, each with its own
approach to managing software projects. Here’s a breakdown of their differences:

1. Waterfall Model

 Definition: A linear and sequential approach where each phase (Requirement → Design
→ Implementation → Testing → Deployment → Maintenance) must be completed
before moving to the next.

 Best for: Projects with well-defined requirements that are unlikely to change.

 Pros:

o Simple and easy to manage.

o Clear documentation.

 Cons:
 o Inflexible to changes.

o Testing happens late in development, leading to costly fixes.

2. V-Model (Validation & Verification Model)

 Definition: An extension of the Waterfall model where each development phase has a
corresponding testing phase.

 Best for: Projects requiring high reliability (e.g., healthcare, aerospace).

 Pros:

o Emphasizes testing at every stage.

o Reduces bugs in later phases.

 Cons:

o Rigid and costly to change requirements.

o Not suitable for evolving projects.

3. Prototype Model

 Definition: A model where an initial prototype (mock-up) is built, tested, and refined
based on user feedback before actual development.

 Best for: Projects with unclear or evolving requirements.

 Pros:

o Helps gather better requirements.

o Involves users early.

 Cons:

o Time-consuming.

o Can lead to scope creep (constant changes).

4. Agile Model
  Definition: An iterative and incremental approach where development is done in small
cycles (sprints), with continuous feedback and adaptation.

 Best for: Dynamic projects where requirements may change.

 Pros:

o Flexible and adaptable.

o Continuous user involvement.

 Cons:

o Requires strong team collaboration.

o Difficult to predict timeline and cost.

Principles of aging model

 Communication and collaboration

 Focus on project delivery
 Customer and user feedback

Unit 3

Requirement engineering
 Understand what customer desires
 Analyzing the need
 Assessing feasibility
 Negotiate a reasonable solution
 Specify the solution clearly
 Validating the specifications
 Managing the requirements
UNIT 4
Software Management: Meaning & Characteristics

Meaning of Software Management

Software management refers to the process of planning, organizing, leading, and controlling the
development, deployment, and maintenance of software applications. It involves managing
software projects, teams, resources, risks, quality, and ensuring that software meets business
and user requirements efficiently.

Characteristics of Software Management

1. Project Planning & Scheduling – Defining project goals, tasks, timelines, and milestones.

2. Resource Allocation – Managing human, financial, and technological resources

efficiently.

3. Risk Management – Identifying and mitigating risks that may affect the project.

4. Quality Assurance – Ensuring software meets predefined standards and user

expectations.

5. Software Development Life Cycle (SDLC) Management – Overseeing all phases, from
requirement gathering to maintenance.

6. Team Collaboration & Leadership – Coordinating software engineers, testers, and

stakeholders.

7. Version Control & Configuration Management – Managing different versions and

updates of software.

8. Budget & Cost Management – Controlling expenses to keep the project within budget.

9. Compliance & Security Management – Ensuring the software adheres to legal, ethical,
and security standards.

10. User Feedback & Continuous Improvement – Adapting software based on user
feedback and evolving needs.

Software Project Management (SPM) is the process of planning, organizing, leading, and
controlling software development projects to ensure they are completed on time, within
budget, and meet the required quality standards. It involves managing resources, risks,
schedules, and stakeholder expectations throughout the software development life cycle
(SDLC).

Time, Cost, and Quality in Software Project Management

In software project management, time, cost, and quality form the Project Management
Triangle (also known as the Iron Triangle). These three factors are interdependent, meaning
that changing one affects the others.

1. Time (Schedule)

 Refers to the project timeline, including deadlines for different phases of the software
development life cycle (SDLC).

 Delays in one phase can impact the overall project.

 Managed through effective planning, scheduling, and resource allocation.

Challenges:

 Scope creep (adding new features beyond the initial plan).

 Inaccurate estimations.

 Unforeseen technical difficulties.

2. Cost (Budget)

 Refers to the financial resources required to complete the project.

 Includes expenses for development, testing, infrastructure, salaries, and maintenance.

 Managed through budgeting, cost estimation, and financial tracking.

Challenges:

 Underestimating costs.

 Unexpected changes requiring additional funding.

 Poor resource management leading to inefficiencies.

3. Quality

 Refers to how well the software meets requirements, user expectations, and industry
standards.

 Ensured through testing, quality assurance (QA), and adherence to best practices.

 High quality reduces bugs, improves performance, and enhances user satisfaction.
Challenges:

 Balancing quality with time and cost constraints.

 Rushing development may lead to low-quality software.

 Poor testing can result in defects and security vulnerabilities.

Balancing Time, Cost, and Quality

 Fast + Cheap = Low Quality (Rushed development leads to defects).

 Fast + High Quality = Expensive (Requires more skilled developers and resources).

 Cheap + High Quality = Slow (Limited budget means longer development time).

Main Roles of a Project Manager

1. Project Planning & Scheduling

2. Resource Management

3. Risk Management

4. Quality Assurance

5. Stakeholder Communication & Management

6. Team Leadership & Motivation

7. Change Management

8. Project Documentation & Reporting

Unit 6
Why is data modeling essential?
 Help in business requirements collection
 Improving the performance of database
 Provides documentation of the source target system
 Simplify re-engineering in case it is needed
 Offers source and target system documentation
Data modelling life cycle and types:
The data modeling life cycle involves a series of steps to define, design,
implement, and maintain data structures in a system.
 Conceptual data model
 Logical data model
 Physical data model

Sequence diagrams
A sequence diagram is a key component of UML used to visualize the interactions between
objects and component in a sequential order, It focuses on how objects communicate with one
another over time, making it an essential time, making it an essential tool for modelling
dynamic behavior in a system. It is message-focus and time-focused c’est à dire, It illustrates the
interactions donc comme des messages et ça donne l’heure aussi. Par example the transaction
with an ATM scenario.

Why sequence diagrams?

 It promotes understanding use cases, designing system architecture, and documenting

complex processes
 For modeling dynamic behavior in a system

Sequence diagram notations:

Actors

Message: there are different types of messages

Lifeline