1
Classical Waterfall Model
Classical waterfall model divides
life cycle into phases:
feasibility study,
requirements analysis and
specification,
design,
coding and unit testing,
integration and system testing,
maintenance.
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Software engineering lec 2., Cheat Sheet of Software Engineering
This is first lecture of software engineering course .you will be able to understand each concept very clearly.
Typology: Cheat Sheet
2020/2021
1 / 57
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Software engineering lec 2. and more Cheat Sheet Software Engineering in PDF only on Docsity!
Classical Waterfall Model
Classical waterfall model divides life cycle into phases: feasibility study, requirements analysis and specification, design, coding and unit testing, integration and system testing, maintenance.
Classical Waterfall Model
Feasibility Study Req. Analysis Design Coding Testing Maintenance
Classical Waterfall Model
(CONT.) Most organizations usually define: entry and exit criteria for every phase. They also prescribe specific methodologies for: specification, design, testing, project management, etc.
Feasibility Study
Main aim of feasibility study:determine whether developing the product financially worthwhile technically feasible. First roughly understand what the customer wants: different data which would be input to the system, processing needed on these data, output data to be produced by the system, various constraints on the behavior of the system.
Activities during Feasibility
Study
Perform a cost/benefit analysis: to determine which solution is the best. you may determine that none of the solutions is feasible due to: high cost, resource constraints, technical reasons.
Requirements Analysis and
Specification
Aim of this phase:
understand the exact requirements of the customer, document them properly.
Consists of two distinct
activities:
requirements gathering and analysis requirements specification.
Requirements Gathering
Gathering relevant data:
usually collected from the end- users through interviews and discussions. For example, for a business accounting software: interview all the accountants of the organization to find out their requirements.
Requirements Analysis (CONT.)
The data you initially collect
from the users:
would usually contain several
contradictions and
ambiguities:
each user typically has only a
partial and incomplete view of
the system.
Requirements Analysis (CONT.)
Engineers doing
requirements analysis and
specification:
are designated as analysts.
Design
Design phase transforms
requirements specification:
into a form suitable for
implementation in some
programming language.
Traditional Design Approach
Consists of two activities:
Structured analysis
Structured design
Structured Analysis
Activity
Identify all the functions to be performed. Identify data flow among the functions. Decompose each function recursively into sub-functions. Identify data flow among the subfunctions as well.
Structured Design
High-level design: decompose the system into modules, represent relationships among the modules. Detailed design: different modules designed in greater detail: data structures and algorithms for each module are designed.
Object Oriented Design
First identify various objects (real world entities) occurring in the problem: identify the relationships among the objects. For example, the objects in a pay-roll software may be: employees, managers, pay-roll register, Departments, etc.