Developing Software Applications Software Life Cycle Specification Design Implementation Testing Maintenance

Developing Software Applications

Software Life Cycle

Specification Design Implementation Testing Maintenance


User identifies needFor system Feasibility study

Modify design

Project abandoned

Test

Enter test data

Write programs

Design system

System possible

System meetsRequirements

Debug

System works

Enter real data

Run in parallel with Existing system

Document , Produce User manuals

Review

System goes ‘live’Users satisfied

No

No

Yes

YesNo


Specification

Stated clear objectives and requirements of the application

Should be– Specific– Agreed objectives– A statement of constraints and resources– Scope

Represents agreement between client and developer


specification

The specification is the result of stages of systems analysis which include:– Feasibility– Fact finding– Analysis

Usually results in a conceptual map of the system known as a Data Flow Diagram and an analysis of the data storage known as an Entity Relationship Diagram


Design

From the requirements programmer/analyst produces a design

Consists of three main parts– Input and output design– Data storage requirements– Process design

Roughly correspond to– DFD (basic requirements of I/O and processes)– ERD (break of data storage within the system)


Design

DFD defines– Data going into and out of the

system– Location and nature of data– Processes and subprocesses

acting on the data– Top-level data stores

Can be used to design Inputs/outputs to cater for likely user type

Functional requirements can be extracted and converted into program logic

Entity analysis enables the programmer to determine the breakdown of data into

– Internal data structures– External file structures– Process mapping

between internal and external data structures (relationships)


1

receivebooking requests

local reception

5

administer local unfilled bookings

h/o local admi 6

invoiuce and maintain customer records

h/o accounts

3

record vehicle departure and return

depot staff

4

find and notifydrivers

driver admin

2

fill bookingsheet

local booking

d1 booking requests

d3 booking sheet

d3 booking sheets

d2 driver instructs

Example DFD


employee

Client

Appointment

Clinic

PrescriptionTreatment

Prescription line

Attendance

Example ERD


Design

From the input / output requirements we construct– Dialogue design– A map linking processes to the dialogue

Use a state transition diagram (STD) First design screens (dialogue) which use

functions consistent with user requirments Link them together !! Show linking mechanism


Design (State Transition Diagram example)

M

Menu

subjectauthor

find booktake out

reserve

return

M

MM

M1

2

3

4

56 M


Design of Processes

functional analysis used to design resulting code

Break down design into logical blocks Stepwise refinement Functional decomposition


Functional Analysis

Get upGo to UniversityFor as long as there is a lecture to attend

Go to lectureTake notes attentively and enthusiastically!

Eat teaGo to townFor as long as you have money and are thirsty

Buy a drinkGo home

If you have spare money go by taxi

Else walk

Go Function

College Function

Food Function

Go out Function

Go home Function


Process Design Notation

Top Down design notation – Diagrammatic notation; sequence,selection,

iteration– Pseudo Code/ Structured English

Object Design– Methods applicable to object defined as elements of

object– Uses object modeling to indicate behaviour of

objects


Top-Down design

Take main functions Systematically break into smaller chunks Use a method to ‘represent’ solution Stop when resulting modules are small enough

to be easily implemented (but not too cumbersome)

‘Clever’ chunking results in reusable modules


0 < O R > 100 < 40 < 60 < 80 else

In p u tN am e & E xam

oE rro r

oR e fe rra l

oP ass

oM erit

oD is tin c tion

C h eckE xam

O u tp u tN am e & G rad e

oG rad e

oC lear

C h eck E ven t *

E xam G rad e

Jackson Structured Design

Inputs

Output


Nassi-Schneidermann

Enter details

While user input

If Not Clear

Clear

RP M D E

While valid input If mark entry enter name enter mark Case {mark 0 - 39 “refer”

mark 40 – 59 “pass”mark 60 – 79 “merit”mark 80 – 100 “Distinction”}

else “Error”

output name and grade Else ClearOutput mark & name


Data Design

Data dictionary ------- can use JSP / NSD to File structure illustrate ranges etc.

Name Type Description

studentexamgrade

StringIntegerString

Stores Student NameStores Exam Mark 0-100%Stores Exam Grade•Error•Pass•Merit•Distinction


Testing

Test plan Use to test design Dry running technique Equivalent to msgboxes to show current state

of variables Use same plan to test code cf results with

design phase Testing has basic strategy


Testing

Purpose of testing– Designing test cases and test case data with

corresponding input and expected output

Black and White box testing– Difference between these two categories of test; – when test data can be designed and purpose.


White and Black Box Testing

Black Box testing (tests design and coding)– Categories

Functional tests Invalid Tests Boundary Tests Special tests

White Box testing (performed after code written)– Categories

Path Analysis Complex Conditions


Example test Plan

INPUT OPERATION

OUTPUT

Student

Mark

Expected Actual

1-Bob 35 Calc Grade

Bob: Referral Bob: Referral

2-Bob 45 Calc Grade

Bob: Pass Bob: Pass

3-Bob 65 Calc Grade

Bob: Merit Bob: Merit

4-Bob 85 Calc Grade

Bob: Distinction Bob: Distinction

5-Bob -5 Calc Grade

Error Message Error Message

6-Bob 105 Calc Grade


7-Bob abc Calc Grade


8-Bob abc Clear Clear Text Boxes

Clear Text Boxes


Maintenance

Constant refinement Until:

– System works– Client satisfied– Terms of specification met

Then– Re-evaluation– Changes to specification

Start again


User identifies needFor system Feasibility study

Modify design

Project abandoned

Test

Enter test data

Write programs

Design system

System possible

System meetsRequirements

Debug

System works

Enter real data

Run in parallel with Existing system

Document , Produce User manuals

Review

System goes ‘live’Users satisfied

No

No

Yes

YesNo

Documents

Developing Software Applications Software Life Cycle Specification Design Implementation Testing Maintenance