0% found this document useful (0 votes)
4 views

AICT Lecture 09 System Development LIfe Cycle (1)

Uploaded by

ayeshaaa0134
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

AICT Lecture 09 System Development LIfe Cycle (1)

Uploaded by

ayeshaaa0134
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 35

CS_180 Applications of Information &

Communication Technologies
Fall 2024

Course Instructor:
Ms. Seemab Khan- Lecturer (Software Engineering )
Department of Creative Technologies
Air University - Islamabad
[email protected]
Lecture 9: System Development Life
Cycle

 Requirement Analysis
 Requirement Design
 Requirement Implementation
 Requirement Testing
 Requirement Evolution
System Development Life Cycle :
SDLC
The Basics of Application Software
• Software ownership rights: Specify the allowable use of the program
• Software license: Specifies the conditions under which a buyer of the
program can use it

CS181 Applications of Information & Communication


4
Technologies
Desktop vs. Mobile Software

• Mobile phones and mobile devices typically require mobile software


– Specifically designed for a specific type of device
– Wide range of software available

CS181 Applications of Information & Communication


5
Technologies
Software Suites

• Software suite: Collection of software programs bundled


together and sold as a single software package
– Office suites are used by most businesses/individuals to
produce documents
• Typically include:
– Word processing software
– Spreadsheet software
– Additional productivity tools like calendars,
messaging programs, or collaboration tools.

CS181 Applications of Information & Communication


6
Technologies
Software Suites

• Office suites include:


− Microsoft Office
− Apple iWork
− OpenOffice.org (free)
• Most suites available in variety of
versions
• Not all suites available for all OS
• Cost lower than buying each
program separately
7

CS181 Applications of Information & Communication


7
Technologies
Common Software Commands

• Application programs today have a number of concepts and


commands in common
– Toolbars
– Menus
– Command buttons
– Keyboard shortcuts
– Mini toolbar

CS181 Applications of Information & Communication


8
Technologies
Example: Word Processing Concepts
• Word processing:
• Using a computer and word processing software to create, edit, save, and
print written documents such as letters, contracts, and manuscripts
• Word processing software:
• Application software used to create, edit, save, and print written
documents
• Common programs:
– Microsoft Word
– Corel WordPerfect
– Apple Pages

CS181 Applications of Information & Communication


9
Technologies
SDLC

➢ Software development life cycle (SDLC) is


a framework that describes the activities
performed at each stage of software
development project.
➢ SDLC process is used by the software
industry to design, develop and test high
quality software.

CS181 Applications of Information & Communication


10
Technologies
SDLC
Phase 01: Planning & Requirement Analysis

➢ Requirement analysis is the most important and fundamental stage in

SDLC.
➢ Planning for the quality assurance requirement and identification of the

risks associated with the project is also done at this stage.

CS181 Applications of Information & Communication


11
Technologies
Levels & Types of Requirements

CS181 Applications of Information & Communication


12
Technologies
Levels & Types of Requirements
Term Definition
Functional Requirement A description of a behavior that a system will exhibit
under specific conditions.
Nonfunctional requirement A description of a property or characteristic that a
system must exhibit or a constraint that it must
respect.
Quality attribute A kind of nonfunctional requirement that describes
a service or performance characteristic of a product.

System requirement A top-level requirement for a product that contains


multiple subsystems, which could be all software or
software and hardware.
User requirement A goal or task that specific classes of users must be
able to perform with a system, or a desired product
attribute.

CS181 Applications of Information & Communication


13
Technologies
RE Process
Requirements Development Process

• Elicitation: work with the customer on gathering


requirements
• Analysis: process this information to understand it, classify
in various categories, and relate the customer needs to
possible software requirements
• Specification: Structure the customer input and derived
requirements as written documents and diagrams
• Validation: you’ll ask your customer to confirm that what
you’ve written is accurate and complete and to correct errors.
Benefits from a High-Quality
Requirements Process

• Fewer requirement defects


• Reduced development rework
• Fewer unnecessary features
• Faster development
• Fewer miscommunications
• Reduced scope creep
• Reduced project chaos(disorder)
• More accurate system testing estimates
• Higher customer and team member satisfaction
SDLC
Phase 02: Defining Requirements

➢ Once the requirement analysis is done the next step is to clearly define

and document the software requirements and this is done through ‘SRS’.
➢ Software requirement specification(SRS) document which consists of all

the product requirement to be designed and developed during the project


life cycle.

CS181 Applications of Information & Communication


17
Technologies
Requirement Analysis
• Problem Analysis
• Development of product vision and project scope
• Analysis and elicitation feed each other

Elicitation

Elicitatio Questions and


n Notes points to
consider

Analysis Requirement
s Elicitation
• Analysis goes hand in hand with modeling
Requirement Analysis (Contd…)
• The process of studying and analyzing the user needs to arrive at a
definition of the problem domain and system requirements
• What is it?
• The process by which customer needs are understood and
documented.
• Expresses “what” is to be built and NOT “how” it is to be
built.
• Example 1:
• The system shall allow users to withdraw cash. [What?]
• Example 2:
• A sale item’s name and other attributes will be stored in a hash table
and updated each time any attribute changes. [How?]
Questions
• Requirements can be specified in terms of structure,
standards and writing rules but:
• How to identify the real problems to solve in elicitation
results?
• How to detect conflicting aspects?
• How to negotiate to resolve conflicts?
• How to decide what is important and priority?
• How to ensure that nothing is forgotten?
• How to validate that the findings of the analysis are good?
• How to use models in this context?
How to find the real problems?
• Ask : Why ?
• Root Cause analysis
• Recursively determine the factors that contribute to the problems
founds by the stakeholders
• All causes do not have the same impact nor the same weight
• Some may perhaps not deserve to be corrected, at least for the
moment
• Goal- Oriented modeling can help understand these causes and their
relationships
• This analysis identifies problems that need to be solved.
SDLC
Phase 03: Designing the Software

➢ Based on requirements specified in SRS ,usually more than one design

approach for the product architecture is proposed and documented in a


Design Document Specification(DDS).
➢ The DDS is reviewed by all the stakeholders and based on various

parameters as risk assessment,design morality and budget.

CS181 Applications of Information & Communication


22
Technologies
Understanding User Requirements

• Use-Case Approach:
• Formalization of usage-centered perspective to requirements elicitation
and modeling.
• Works well for business applications, Web sites, services that one system
provides to another, and systems that let a user control a piece of
hardware.
• Event-Response Tables:
• Applications such as batch processes, computationally intensive systems,
might have just a few simple use cases.
• The complexity of these applications lies in the computations performed
or the reports generated, not in the user-system interaction.
• A requirements technique often used for real-time systems is to list the
external events to which the system must react and the corresponding
system responses.
The Use-Case Approach
• A use case describes a sequence of interactions between a system and an
actor.
• An actor is a person, another software system, or a hardware device that
interacts with the system to achieve a useful goal.
• Another name for actor is user role, because actors are roles that the
members of one or more user classes can perform with respect to the
system.
• For example, the Chemical Tracking System's use case called "Request a
Chemical" involves an actor named Requester. There is no Chemical
Tracking System user class named Requester. Both chemists and
members of the chemical stockroom staff may request chemicals, so
members of either user class may perform the Requester role.
The Use-Case Approach
• Shift the perspective of requirements development to discussing what
users need to accomplish, in contrast to the traditional elicitation
approach of asking users what they want the system to do.
• The objective is to describe all tasks that users will need to perform with
the system.
• The stakeholders ensure that each use case lies within the defined project
scope.
(Partial) Use-case Diagram for the Chemical
Tracking System (UML notation)
Use-cases and Usage Scenarios
• A use case is a discrete, stand-alone activity that an actor can perform to
achieve some outcome of value.
• A single use case might encompass a number of similar tasks having a
common goal.
• A use case is therefore a collection of related usage scenarios, and a
scenario is a specific instance of a use case.
Use-case Description
• A unique identifier
• A name that briefly states the user task in the form of "verb + object," such
as "Place an Order"
• A short textual description written in natural language
• A list of pre-conditions that must be satisfied before the use case can begin
• Post-conditions that describe the state of the system after the use case is
successfully completed
• A numbered list of steps that shows the sequence of dialog steps or
interactions between the actor and the system that leads from the pre-
conditions to the post-conditions
Use-case Description
Use-case Description
SDLC
Phase 04: Developing the Software

➢ The programming code is generated as per DDS during this stage.

➢ Developers have to follow the coding guidelines defined by their

organization and programming tools like compilers,interpreters,debuggers


etc.

CS181 Applications of Information & Communication


31
Technologies
SDLC
Phase 05: Testing the software

➢ The testing activities are mostly involved in all the stages of SDLC.

➢ However this stage refers to the testing only that stage of the software

where defects are reported,tracked,fixed and retested,until the software


reaches the quality standards defined in the SRS.

CS181 Applications of Information & Communication


32
Technologies
SDLC
Phase 06: Deployment and Maintenance

➢ Once the software is tested and no bugs or errors are reported then it is

deployed.
➢ After the software is deployed then its maintenance starts.

CS181 Applications of Information & Communication


33
Technologies
Reasons for using SDLC Models

➢ Provides the base for project planning,estimating & scheduling.

➢ Provides mechanism for project tracking & control.

➢ Provides framework for standard set of terminologies,activities &

deliverables.

CS181 Applications of Information & Communication


34
Technologies
Advantages of SDLC

➢ Increased development speed

➢ Increased product quality

➢ Improved tracking & control

➢ Improved client relations

➢ Decreased project risk

CS181 Applications of Information & Communication


35
Technologies

You might also like