Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Project estimation in Software, Study notes of Computer Science

sw project management process begins with project planning objective of sw project planning - to provide a framework for manager to make reasonable estimates of resources, costs and schedules Pri

Typology: Study notes

2018/2019

Uploaded on 01/20/2023

ryda27
ryda27 🇮🇳

5

(1)

14 documents

1 / 38

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Ch. 3 1
Software Engineering Principles
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26

Partial preview of the text

Download Project estimation in Software and more Study notes Computer Science in PDF only on Docsity!

Software Engineering Principles

Outline

  • (^) Principles form the basis of methods, techniques, methodologies and tools
  • (^) Seven important principles that may be used in all phases of software development
  • (^) Modularity is the cornerstone principle supporting software design
  • (^) Case studies

A visual representation

Principles Methodologies Principles Methods and techniques Methodologies Tools

Key principles

  • (^) Rigor and formality
  • (^) Separation of concerns
  • (^) Modularity
  • (^) Abstraction
  • (^) Anticipation of change
  • (^) Generality
  • (^) Incrementality

Examples: product

  • (^) Mathematical (formal) analysis of program correctness
  • (^) Systematic (rigorous) test data derivation

Example: process

  • (^) Rigorous documentation of development steps helps project management and assessment of timeliness

Example: process

  • (^) Go through phases one after the other (as in waterfall) - (^) Does separation of concerns by separating activities with respect to time

Example: product

  • (^) Keep product requirements separate - (^) functionality - (^) performance - (^) user interface and usability

Cohesion and coupling

  • (^) Each module should be highly cohesive
    • (^) module understandable as a meaningful unit
    • (^) Components of a module are closely related to one another
  • (^) Modules should exhibit low coupling
    • (^) modules have low interactions with others
    • (^) understandable separately

A visual representation

(a) (^) (b) high coupling (^) low coupling

Abstraction ignores details

  • (^) Example: equations describing complex circuit (e.g., amplifier) allows designer to reason about signal amplification
  • (^) Equations may approximate description, ignoring details that yield negligible effects (e.g., connectors assumed to be ideal)

Abstraction yields models

  • (^) For example, when requirements are analyzed we produce a model of the proposed application
  • (^) The model can be a formal or semiformal description
  • (^) It is then possible to reason about the system by reasoning about the model

Abstraction in process

  • (^) When we do cost estimation we only take some key factors into account
  • (^) We apply similarity with previous systems, ignoring detail differences

Anticipation of change

  • (^) Ability to support software evolution requires anticipating potential future changes
  • (^) It is the basis for software evolvability
  • (^) Example: set up a configuration management environment for the project (as we will discuss)