Software Design and Project Management: Principles, Modularity, Estimation and Scheduling

Posted on Oct 15, 2026 in Software Engineering

UNIT III — Software Design & Project Management

1. Software Design

Software design transforms requirements into a blueprint for implementation.

It describes:

  • Architecture
  • Components
  • Interfaces
  • Data
  • Algorithms
  • Relationships between modules

2. Design Fundamentals

Important design concepts include:

1. Abstraction

Represent essential features while hiding unnecessary details.

2. Modularity

Divide software into smaller independent modules.

3. Information Hiding

Hide internal implementation details from other modules.

4. Refinement

Move from a high-level solution to detailed design.

5. Separation of Concerns

Divide the system into parts dealing with different responsibilities.

6. Reusability

Design components so they can be reused.

7. Simplicity

Avoid unnecessary complexity.

3. Effective Modular Design

Modularity means dividing software into independent modules.

Example:

          Banking System
               |
    ┌──────────┼──────────┐
    ↓          ↓          ↓
  Login      Account    Transaction
             Management

Advantages

  • Easier testing.
  • Easier maintenance.
  • Easier debugging.
  • Supports parallel development.
  • Promotes reuse.

A good modular design should have:

High cohesion + Low coupling

4. Design Representations

Design can be represented using:

  • Flowcharts
  • Structure charts
  • UML diagrams
  • Data-flow diagrams
  • Pseudocode
  • Decision tables
  • Decision trees
  • Architecture diagrams
  • Class diagrams

5. Architectural Design

Architectural design defines the overall structure of the software system.

It identifies:

  • Major components
  • Relationships
  • Communication between components
  • Data organization

Example:

          User Interface
                ↓
        Business Logic
                ↓
          Data Access
                ↓
            Database

Common architectural styles

  • Layered architecture
  • Client-server
  • Repository
  • Pipe-and-filter
  • MVC

6. Procedural Design

Procedural design describes the processing logic and algorithms of the system.

It focuses on:

  • Sequence of operations
  • Conditions
  • Loops
  • Data processing
  • Algorithms

Common representations

  • Flowcharts
  • Pseudocode
  • Decision tables
  • Decision trees

7. Data-Directed Design

Data-directed design organizes software around the data structures and data flow.

The design begins by identifying:

  • Data objects
  • Data relationships
  • Data transformations

It is useful in applications where data processing is central.

8. Real-Time Design

Real-time systems must respond to events within specified time constraints.

Examples

  • Air traffic control
  • Medical monitoring
  • Industrial control
  • Automobile control systems

Important concerns

  • Timing constraints
  • Events
  • Concurrency
  • Interrupts
  • Synchronization
  • Reliability

Types

Hard real-time: Missing a deadline can cause system failure.

Soft real-time: Missing an occasional deadline reduces performance but does not necessarily cause catastrophic failure.

9. Object-Oriented Design

Object-oriented design represents a system as a collection of objects/classes.

Important concepts

Class: Blueprint for objects.

Object: Instance of a class.

Encapsulation: Combining data and methods.

Inheritance: Creating a new class from an existing class.

Polymorphism: Same interface can have different implementations.

Abstraction: Showing essential features and hiding unnecessary details.

10. Coupling

Coupling measures the degree of dependency between modules.

Principle

Low coupling is desirable.

Types from stronger to weaker coupling

  • Content coupling
  • Common coupling
  • External coupling
  • Control coupling
  • Stamp coupling
  • Data coupling

Data coupling

Modules communicate by passing only required data.

It is generally preferred.

11. Cohesion

Cohesion measures how closely related the responsibilities within a module are.

Principle

High cohesion is desirable.

Types from weakest to strongest

  • Coincidental
  • Logical
  • Temporal
  • Procedural
  • Communicational
  • Sequential
  • Functional

Ideal design

High Cohesion
      +
Low Coupling
      ↓
Better Software Design

12. Coupling vs Cohesion

CouplingCohesion
Relationship between modulesRelationship within a module
Should be lowShould be high
Measures dependencyMeasures functional strength
Low coupling is desirableHigh cohesion is desirable

13. Software Metrics

A software metric is a quantitative measure of a software product, process or project.

Categories

1. Product metrics

Measure characteristics of software.

Examples:

  • LOC
  • Complexity
  • Number of defects

2. Process metrics

Measure development process.

Examples:

  • Defect removal efficiency
  • Development time

3. Project metrics

Measure project characteristics.

Examples:

  • Cost
  • Effort
  • Schedule
  • Productivity

14. Project Management

Software project management involves planning, organizing and controlling resources to achieve project objectives.

A common framework is:

People
  ↓
Product
  ↓
Process
  ↓
Project

People

People are the most important resource in software development.

Roles include:

  • Project manager
  • Software engineers
  • Designers
  • Testers
  • Customers
  • Users

Good communication and teamwork are essential.

Product

Before development, the project manager must understand:

  • Product scope
  • Objectives
  • Requirements
  • Constraints
  • Expected quality

Process

Process defines how software will be developed.

Examples:

  • Waterfall
  • Spiral
  • Agile
  • Iterative development

Project

Project management includes:

  • Estimation
  • Scheduling
  • Risk management
  • Resource allocation
  • Monitoring
  • Quality management

15. Software Project Estimation

Estimation predicts:

  • Effort
  • Cost
  • Development time
  • Resources
  • Software size

16. LOC-Based Estimation

LOC = Lines of Code

If estimated program size is known, effort can be estimated using an empirical formula.

Example:

If productivity = 500 LOC/person-month and estimated size = 5000 LOC:

Effort = 5000 / 500 = 10 person-months

Advantages

  • Simple.
  • Easy to understand.

Disadvantages

  • Depends on programming language.
  • Difficult to estimate LOC before design.
  • Does not directly measure functionality.

17. Function Point Estimation

Function Point (FP) measures software size based on functionality provided to users, rather than lines of code.

Five components are considered:

  1. External Inputs (EI)
  2. External Outputs (EO)
  3. External Inquiries (EQ)
  4. Internal Logical Files (ILF)
  5. External Interface Files (EIF)

Basic formula

FP = UFP × VAF

Where:

  • UFP = Unadjusted Function Points
  • VAF = Value Adjustment Factor

Typically:

VAF = 0.65 + 0.01 × ΣFi

where Fi represents the general system characteristics.

Advantages

  • Language independent.
  • Can estimate early.
  • Based on user functionality.

Disadvantages

  • Some subjectivity.
  • Requires experience.
  • More complicated than LOC.

18. Empirical Estimation

Empirical estimation uses mathematical models derived from historical project data.

General form:

Effort = a(Size)b

Where:

  • a, b are constants.
  • Size may be measured in KLOC or another unit.

Examples:

  • COCOMO
  • Regression-based models

19. COCOMO Model

COCOMO = Constructive Cost Model

Developed by Barry Boehm.

It estimates software:

  • Effort
  • Development time
  • Cost

Basic COCOMO equation

E = a(KLOC)b

where:

  • E = effort in person-months
  • KLOC = thousand lines of code
  • a, b = constants

Development time:

D = c(E)d

where:

  • D = development time in months
  • c, d = constants

Average staffing:

Staff = Effort / Development Time

COCOMO Project Modes

1. Organic

  • Small/simple projects
  • Experienced team
  • Familiar environment

2. Semi-detached

  • Medium-size projects
  • Mixed team experience
  • Moderate complexity

3. Embedded

  • Complex systems
  • Tight hardware/software constraints
  • Strong operational constraints

Basic COCOMO coefficients

Modeabcd
Organic2.41.052.50.38
Semi-detached3.01.122.50.35
Embedded3.61.202.50.32

Example

Suppose an organic project is estimated at 10 KLOC.

E = 2.4(10)1.05

Approximately:

E ≈ 26.4 person-months

Then:

D = 2.5(E)0.38

Approximately:

D ≈ 8.7 months

Average team size:

26.4 / 8.7 ≈ 3

So approximately 3 people would be required on average.

20. Project Scheduling

Project scheduling determines:

  • What activities must be performed.
  • When activities start/end.
  • Who performs them.
  • Dependencies between activities.
  • Project completion date.

Common scheduling techniques

1. Gantt Chart

A Gantt chart represents activities against time.

Task       Week 1  2  3  4  5  6
Requirements ████
Design          ██████
Coding             █████████
Testing                   █████
Deployment                    ██

Advantages

  • Easy to understand.
  • Shows progress.
  • Shows start/end dates.

21. PERT

PERT = Program Evaluation and Review Technique

Used when activity durations are uncertain.

Three time estimates are used:

  • Optimistic time O
  • Most likely time M
  • Pessimistic time P

Expected time:

TE = (O + 4M + P) / 6

Example:

If:

O = 2, M = 4, P = 8

Then:

TE = (2 + 4(4) + 8) / 6 = 26 / 6 = 4.33

So expected duration is approximately 4.33 units of time.

22. CPM

CPM = Critical Path Method

CPM identifies the critical path, i.e. the longest path through a project network.

Activities on the critical path have approximately zero total float.

Why is critical path important?

Delay in a critical-path activity can delay the entire project.