Synetic College Logo
Unit 2 of 4 · B.Sc IT Sem 5

Unit 2: Project planning and design

Software Engineering notes · PTU syllabus (BSIT503/BSBC401)

3 min read11 topics10 exam questions
On this page
  1. Unit summary
  2. Decomposition techniques and software sizing
  3. Problem-based estimation
  4. Process-based estimation
  5. The COCOMO model
  6. Structured analysis principles and requirement analysis
  7. Data flow diagrams
  8. ER diagrams and the data dictionary
  9. Design objectives, principles and concepts
  10. Data, architectural and procedural design
  11. Architectural styles
  12. Object-oriented concepts
  13. Key terms
  14. Quick revision
  15. Important questions

Unit summary

Planning estimates how big and costly the software will be, analysis models what it must do, and design decides how. This unit covers decomposition and sizing, problem-based and process-based estimation, COCOMO, structured analysis, requirement analysis, DFDs, ER diagrams, the data dictionary, design objectives, principles and concepts, data, architectural and procedural design, and object-oriented concepts.

After this unit you can

  • Estimate size, effort and cost
  • Apply the COCOMO model
  • Build analysis models with DFDs, ER diagrams and a data dictionary
  • Apply design concepts and object-oriented concepts

PTU syllabus topics

  • Decomposition techniques
  • software sizing
  • problem-based and process-based estimation
  • COCOMO model
  • structured analysis principles
  • requirement analysis
  • DFD
  • ER diagrams
  • data dictionary
  • design objectives/principles/concepts
  • data/architecture/procedural design
  • object-oriented concepts
Key formulasBasic COCOMO

  • Effort

    E = a × (KLOC)^b person-months

  • Development time

    D = c × (E)^d months

  • Organic mode

    a = 2.4, b = 1.05

  • Semi-detached mode

    a = 3.0, b = 1.12

  • Embedded mode

    a = 3.6, b = 1.20

1

Topic 1

Decomposition techniques and software sizing

  • Decomposition: dividing the problem (functions) or the process (tasks) into smaller pieces that can be estimated more accurately.
Key termsSizing approaches
Fuzzy logic sizing
Classify the application by type and magnitude, then refine
Function point sizing
Estimate the information domain characteristics
Standard component sizing
Count standard components (screens, reports, modules)
Change sizing
Estimate changes to existing software
2

Topic 2

Problem-based estimation

  • Estimate LOC or FP for each decomposed function as optimistic (o), most likely (m) and pessimistic (p) values, then compute the expected value.
Key formulasProblem-based estimation

  • Expected size

    S = (o + 4m + p) ÷ 6

  • Effort

    Size ÷ productivity (LOC or FP per person-month)

  • Cost

    Effort × labour rate

Example

A function estimated at o = 2,000, m = 3,000, p = 5,000 LOC: S = (2,000 + 12,000 + 5,000) ÷ 6 ≈ 3,167 LOC. At 500 LOC per person-month: about 6.3 person-months.

  • Function points: FP = count total × (0.65 + 0.01 × ΣFi), where the count total weights inputs, outputs, inquiries, internal files and external interfaces, and Fi are 14 value adjustment factors (0–5).
3

Topic 3

Process-based estimation

  • Decompose the process into framework activities (communication, planning, modelling, construction, deployment) for each software function, estimate effort for each cell of the function–activity table, and total the effort.
  • Compare with the problem-based estimate; large differences mean the scope or data needs review.
4

Topic 4

The COCOMO model

TechniqueHow it works
Lines of code (LOC)Estimate size in KLOC, then effort per KLOC
Function points (FP)Count inputs, outputs, inquiries, files and interfaces, weighted for complexity
COCOMOEffort = a × (KLOC)ᵇ person-months; organic, semi-detached, embedded modes
Expert judgement / DelphiExperts estimate independently, then converge
Story points (agile)Relative size of user stories; planning poker

Example

Basic COCOMO, organic mode: Effort = 2.4 × (KLOC)^1.05. For 10 KLOC, Effort ≈ 2.4 × 11.2 ≈ 27 person-months.

ComparisonBasic COCOMO modes
Project type
Effort and time formulas

Organic

Small team, familiar, flexible requirements

E = 2.4 (KLOC)^1.05; D = 2.5 E^0.38

Semi-detached

Medium size, mixed experience

E = 3.0 (KLOC)^1.12; D = 2.5 E^0.35

Embedded

Tight hardware, software and operational constraints

E = 3.6 (KLOC)^1.20; D = 2.5 E^0.32

  • Intermediate COCOMO multiplies effort by an effort adjustment factor from 15 cost drivers (reliability, complexity, analyst capability, tools); detailed COCOMO applies drivers phase-wise; COCOMO II uses object points, function points and LOC for modern projects.

Example

Organic project of 32 KLOC: E = 2.4 × 32^1.05 ≈ 91 person-months; D = 2.5 × 91^0.38 ≈ 14 months; average staff ≈ 91 ÷ 14 ≈ 6.5 persons.

5

Topic 5

Structured analysis principles and requirement analysis

Key termsOperational analysis principles
Information domain
Represent and understand the data
Functions
Define what the software must do
Behaviour
Represent states and events
Partitioning
Divide models layer by layer
Essence to implementation
Move from essential to detailed information
  • Requirement analysis tasks: problem recognition, evaluation and synthesis, modelling, specification (SRS) and review. Requirements are functional (what the system does) and non-functional (performance, security, usability).
6

Topic 6

Data flow diagrams

  • DFD: models how data moves and is transformed; drawn top-down as a context diagram (level 0) refined into level 1 and level 2.
Key termsDFD notation
External entity (rectangle)
Producer or consumer outside the system
Process (bubble)
Transformation of data
Data flow (arrow)
Data in motion
Data store (parallel lines)
Data at rest
  • Rules: every process has at least one input and output; data cannot flow directly between two entities or two stores; balance flows between levels; number processes 1.0, 1.1 and so on.

Example

Library context diagram: entities Member and Librarian exchange issue requests, return details and reports with the single process "Library Management System".

7

Topic 7

ER diagrams and the data dictionary

  • ER diagram: models data objects (entities), their attributes and relationships with cardinality and modality (optional or mandatory).
  • Data dictionary: an organised list of all data elements, with name, aliases, where used, content description and supplementary information.
Key termsData dictionary notation
=
is composed of
+
and
[ a / b ]
either a or b
{ }n
n repetitions
( )
optional data
Text between asterisks
comment

Example

telephone number = [local number / long-distance number]; local number = prefix + access number.

8

Topic 8

Design objectives, principles and concepts

Design quality guidelines: a design should implement all requirements, be readable and understandable, and give a complete picture of data, functions and behaviour.

Key termsFundamental design concepts
Abstraction
Focus on essentials, hide detail
Architecture
Overall structure of components
Modularity
Divide software into separately named modules
Information hiding
Modules hide internal details
Functional independence
High cohesion, low coupling
Refinement
Step-wise elaboration of detail

Exam tip

High cohesion (each module does one thing well) and low coupling (modules depend little on each other) is the mark of good design.

Key termsDesign principles
Traceable to the analysis model
Every design element linked to requirements
Do not reinvent the wheel
Reuse patterns and components
Minimise intellectual distance
Structure mirrors the problem
Uniformity and integration
Consistent style and interfaces
Accommodate change
Easy to modify
Degrade gently
Handle errors and unusual input
Design is not coding
Higher abstraction than code
9

Topic 9

Data, architectural and procedural design

ComparisonLevels of design
Produces
Derived from

Data design

Data structures and database design

ER diagram and data dictionary

Architectural design

Program structure — modules and their relationships

DFDs, through transform and transaction mapping

Interface design

How software communicates with users and other systems

DFDs and scenarios

Procedural (component-level) design

Algorithms of each module — flowcharts, pseudocode, decision tables

Process specifications

10

Topic 10

Architectural styles

Software architecture is the structure of a system: its components, their properties and relationships. Common styles: data-centred, data-flow (pipe and filter), call-and-return, layered, object-oriented and client-server. Data design turns the data model from analysis into data structures and database designs.

11

Topic 11

Object-oriented concepts

Key termsOO concepts in software engineering
Class and object
Template and instance
Attributes and operations
Data and methods
Encapsulation
Data and operations packaged together
Inheritance
Subclasses reuse superclass features
Polymorphism
Same operation behaves differently by class
Messages
Objects request services from each other
  • OO analysis and design model systems with classes, use cases and UML diagrams (class, use-case, sequence, activity, state).

Key terms

Decomposition
Dividing a problem or process into smaller parts for estimation
Function point
Measure of functionality delivered
COCOMO
Algorithmic cost model relating effort to size
DFD
Diagram of data movement through processes
Data dictionary
Repository describing all data elements

Quick revision

  • Problem and process decomposition; sizing approaches.
  • Expected value (o + 4m + p) ÷ 6; LOC and FP estimation.
  • COCOMO modes and formulas; intermediate and COCOMO II.
  • Analysis principles; DFD levels and rules; ER; data dictionary notation.
  • Design principles and concepts; data, architectural, interface, procedural design; OO concepts.

Important exam questions

Practice questions written to the PTU exam pattern for this unit's syllabus: short answers (Section A style) and long answers (Sections B and C style).

Short-answer questions

  1. Q1.What is software sizing?
  2. Q2.Write the expected-value formula for estimation.
  3. Q3.Name the three modes of COCOMO.
  4. Q4.What is a context diagram?
  5. Q5.What does "=" mean in a data dictionary?
  6. Q6.Distinguish cohesion and coupling.

Long-answer questions

  1. Q1.Explain problem-based and process-based estimation.
  2. Q2.Explain the COCOMO model with an example.
  3. Q3.Explain structured analysis using DFD, ER diagram and data dictionary.
  4. Q4.Explain design concepts and the levels of design.

Stuck on this unit?

Message SBS on WhatsApp for help with Software Engineering, or to ask about studying B.Sc IT at Synetic.

WhatsApp us