Lecture Hand notes on SDLC, Lecture notes of Software Development

Lecture Hand notes of Software Development Lifecycle

Typology: Lecture notes

2020/2021
On special offer
30 Points
Discount

Limited-time offer


Uploaded on 06/04/2021

pkhokhali
pkhokhali 🇳🇵

5

(1)

18 documents

1 / 51

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Software Development Lifecycles
Instructor: Samir Pokharel
1
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
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
Discount

On special offer

Partial preview of the text

Download Lecture Hand notes on SDLC and more Lecture notes Software Development in PDF only on Docsity!

Software Development Lifecycles

Instructor: Samir Pokharel

Importance

  • (^) Requirements collection can be incomplete or

not deep enough.

  • (^) The lack of methodical, quantifiable methods

drives to difficult situations.

  • (^) The lack of systematic methods drive to weak

or too complex architecture.

  • (^) Difficult to change.
  • (^) Code will become not easy to maintain. SDLC_1 2

Software Development Lifecycles

SDLC_1 4

Process Model

  • (^) A process model is a description of the sequence of activities carried out in an SE project, and the relative order of these activities.
  • (^) It provides a fixed generic framework that can be tailored to a specific project.
  • (^) A software process model is an abstract representation of a process that presents a description of a process from some particular perspective.

Personal Process Model

  • (^) This model is good from the perspective that an individual software engineer can use it to improve his or her personal productivity and work on product quality.
  • (^) It defines five framework activities: planning, high-level design, high-level design review, development, and postmortem.
  • (^) It stresses the need to identify errors early and to understand the types of errors.

Personal Process Model

  • (^) Planning : it isolates requirements and a project schedule is created.
  • (^) High-level design : Prototypes are built.
  • (^) High-level design review : Formal verification methods are applied to uncover errors in the design.
  • (^) Development : Code is generated, reviewed, compiled, and tested.
  • (^) Postmortem: using the measures and metrics collected, the effectiveness of the process is determined.

Team Process Model

  • (^) is a software development process for

engineering team and goal is to build a “self-

directed” project team that organizes itself to

produce high-quality s/w.

  • (^) is intended to improve the levels of quality and

productivity of a team's software development

project, in order to help them better meet the

cost and schedule commitments of developing

a software system

Predictive vs Adaptive model…

SDLC_1 11

Waterfall Model

Waterfall Model

  • (^) first Process Model and it is also referred to as a linear-sequential life cycle model.
  • (^) very simple to understand and use.
  • (^) each phase must be completed fully before the next phase can begin.
  • (^) basically used for the for the project which is small and there are no uncertain requirements.
  • (^) At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project.
  • (^) In this model the testing starts only after the development is complete.
  • (^) In waterfall model phases do not overlap.

Disadvantages

  • (^) Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
  • (^) No working software is produced until late during the life cycle.
  • (^) High amounts of risk and uncertainty.
  • (^) Not a good model for complex and object-oriented projects.
  • (^) Poor model for long and ongoing projects.
  • (^) Not suitable for the projects where requirements are at a moderate to high risk of changing.

When to use?

  • (^) This model is used only when the requirements are very well known, clear and fixed.
  • (^) Product definition is stable.
  • (^) Technology is understood.
  • (^) There are no ambiguous requirements
  • (^) Ample resources with required expertise are available freely
  • (^) The project is short.

Incremental Models

  • (^) the whole requirement is divided into various builds so multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle.
  • (^) Cycles are divided up into smaller, more easily managed modules and each module passes through the requirements, design, implementation and testing phases.
  • (^) A working version of software is produced during the first module, so you have working software early on during the software life cycle.
  • (^) Each subsequent release of the module adds function to the previous release and the process continues till the complete system is achieved.

Advantages

  • (^) Generates working software quickly and early during the software life cycle.
  • (^) This model is more flexible – less costly to change scope and requirements.
  • (^) It is easier to test and debug during a smaller iteration.
  • (^) In this model customer can respond to each built.
  • (^) Lowers initial delivery cost.
  • (^) Easier to manage risk because risky pieces are identified and handled during it’d iteration.