Developing Software Applications Software Life Cycle Specification Design Implementation Testing Maintenance

Developing Software Applications User identifies need For system Feasibility study Modify design Project abandoned Test Enter test data Write programs Design system System possible System meets Requirements Debug System works Enter real data Run in parallel with Existing system Document, Produce User manuals Review System goes ‘live’ Users satisfied No Yes No

Developing Software Applications 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

Developing Software Applications 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

Developing Software Applications 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)

Developing Software Applications 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)

Developing Software Applications 1 receive booking requests local reception 5 administer local unfilled bookings h/o local admi 6 invoiuce and maintain customer records h/o accounts3 record vehicle departure and return depot staff4 find and notify drivers driver admin2 fill booking sheet local booking d1booking requests d3booking sheetd3booking sheetsd2driver instructs Example DFD

Developing Software Applications employee Client Appointmen t Clinic Prescription Treatment Prescription line Attendance Example ERD

Developing Software Applications 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

Developing Software Applications Design (State Transition Diagram example) M Menu subject author find book take out reserve return M M M M M

Developing Software Applications Design of Processes functional analysis used to design resulting code Break down design into logical blocks  Stepwise refinement  Functional decomposition

Developing Software Applications Functional Analysis Get up Go to University For as long as there is a lecture to attend Go to lecture Take notes attentively and enthusiastically! Eat tea Go to town For as long as you have money and are thirsty Buy a drink Go home If you have spare money go by taxi Else walk Go Function College Function Food Function Go out Function Go home Function

Developing Software Applications 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

Developing Software Applications 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

Developing Software Applications Jackson Structured Design Inputs Output

Developing Software Applications Nassi-Schneidermann Enter details While user input If Not Clear Clear R P M DE While valid input If mark entry enter name enter mark Case {mark “refer” mark 40 – 59 “pass” mark 60 – 79 “merit” mark 80 – 100 “Distinction”} else “Error” output name and grade Else Clear Output mark & name

Developing Software Applications Data Design Data dictionary can use JSP / NSD to File structure illustrate ranges etc. NameTypeDescription student exam grade String Integer String Stores Student Name Stores Exam Mark 0-100% Stores Exam Grade Error Pass Merit Distinction

Developing Software Applications 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

Developing Software Applications 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.

Developing Software Applications 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

Developing Software Applications Example test Plan INPUTOPERATIONOUTPUT StudentMark ExpectedActual 1-Bob35Calc GradeBob: Referral 2-Bob45Calc GradeBob: Pass 3-Bob65Calc GradeBob: Merit 4-Bob85Calc GradeBob: Distinction 5-Bob-5Calc GradeError Message 6-Bob105Calc GradeError Message 7-BobabcCalc GradeError Message 8-BobabcClearClear Text Boxes

Developing Software Applications Maintenance Constant refinement Until: – System works – Client satisfied – Terms of specification met Then – Re-evaluation – Changes to specification Start again

Developing Software Applications User identifies need For system Feasibility study Modify design Project abandoned Test Enter test data Write programs Design system System possible System meets Requirements Debug System works Enter real data Run in parallel with Existing system Document, Produce User manuals Review System goes ‘live’ Users satisfied No Yes No