1. 1 International Diploma In Computer Studies (IDCS) 11th August 30th November 2008 P rogramming M ethods (PM)

2. 2 Programming Methods (CT) Chapter 3 SECTION A DATA ANALYSIS AND PROBLEMS

3. 3  The software development process  Create structure diagrams for structured programs  Explain the different variables types  Organize Information  Analyze problems Chapter OBJECTIVES:

4. 4  The software development process  Data structures and data structures diagrams  Organizing information  Fixed and Variable records Chapter CONTENTS:

5. 5 Chapter 3 Data Analysis and Problems PART 1 Program Development Process

6. 6  There are many different types of programs which vary in complexity from simple ones written as a hobby, to complex programs written by profession programmers.  Which are part of a large system 1.1 Introduction

7. 7 Example : Hospital Information System Hospital information System Personnel DB (Nurses, Doctors, etc) Patients DB (Emergency, OPD, etc) Transaction DB (Doctors + Patient, Payments) Inventory DB (Drugs, Medical Equipments)

8. 8 Some examples of Programs:  A suite in a production control system  A simple database program  A program to perform statistical analysis on experimental results  A program to display the contents of database by a web process orders and payments.  e-commerce applications  On line banking  An interactive multimedia program  game (user interaction)  Encyclopedia (e-encyclopedia/ informative) 1.2 Introduction (cont.)

9. 9 Before writing any program we need to know that:  The output required by the user from the system  The processes necessary to produce this output for the user  The data or input to be processed to create the output required 1.3 Introduction (cont.)

10. 10 Programmer  Responsible for writing computer programs 1.4 Key Terms Definition System Analyst  Responsible for the development of an information system  Designs and modifies systems by turning user requirements into a set of functional specifications, which are the blueprint of the system

11. 11 1.5 Practical Analogy  An Architect (system analyst) and an Engineer (programmer)

12. 12 System Analysis  The analysis of the role of a proposed system and the identification of a set of requirements that the system should meet - the starting point for systems design. 1.6 Key Terms Definition (cont.)  Final Design  Expected Output

13. 13 1.7 Program Specification  A formal description of a system, or a component or module of a system, intended as a basis for further development  Characteristics of a good specification  unambiguous, complete, verifiable, consistent, modifiable, traceable, and usable after development  Details of the specification will be discovered during the analysis and design stages of software development

14. 14 1.7 Program Specification Example (cont.)

15. 15 1.7 Practical Analogy: Morning Routine PROCEDURES: Step 1. Get out of bed Step 2. Take a shower/bath Step 3. Dress yourself Step 4: Drink coffee/tea Step 5: Take breakfast Step 6: Drive to work

16. 16 1.7 Example: Actual Computer Program (Salary Computation) Logical Program: Step 1: Identify all variables Actual Program Code: VB No. of hours worked, Rate per hour Basic pay, Deductions, Net pay Step 2: Initialize all variables identify data type identify data type Dim no_hours_worked, rate_per_hour, basic_pay rate_per_hour, basic_pay deductions, net_pay as Integer deductions, net_pay as Integer Step 3: Assign variables (temporary storage) (temporary storage) Let a = no_hours_worked Let b = rate_per_hour Let c = basic_pay Let d = deduction Let e = net_pay Step 4: Compute basic pay c = a * b Step 5: Compute net pay e = c – d Step 6: Store value of net pay lblPay.Caption = e

17. 17 1.8 Definitions of Key Terms  Specification  A formal description of a system or a component module of a system, intended as a basis for further development  Specification Language  A language that is used in expressing a specification (e.g. Rational Rose UML)  Diagrammatic Technique  A style of analysis that relies primarily on the use of diagrams (as opposed to text)  DFD, flowcharts, MS Project

18. 18 1.9 Software Life Cycle  The program development process is part of the software lifecycle, characterized by the following stages:  Requirements analysis  Design  Coding  Testing  Implementation and support

19. 19 1.10 Requirements Analysis Stage  An accurate and complete set of client and user requirements is produced to determine the characteristics of an acceptable solution

20. 20 Practical Analogy: Building a House House Owner Requirements Building Requirements (Site, Access) Draft Plan Purpose/Objectives Develop Initial Layout Add further design considerations (Porch, Parking, Pool) Evaluate Improve Design Building Objectives Cost, Season Contractor, Materials Building Objectives Design Objectives Final Design Iterate Initial Logical Modules

21. 21 1.10 Requirements Analysis Stage (cont.) The requirements analysis specification will contain:  the proposed system or solution, which has been agreed by the client and developer  a list of existing tools, new tools, required facilities and people available for developing the solution  a schedule for the next stages of the project, including the deliverables for each stage

22. 22 1.10 Requirements Analysis Stage (cont.)

23. 23 1.10.1 Deliverables  Deliverables are the products of the different phases throughout the development process  Provided for the client by the developer, as evidence that progress is being made according to requirements  may be written documents and diagrams produced during the analysis and design phases, sample screen layouts or sample reports

24. 24 1.10.2 Requirements Analysis - Objectives  To define, in detail, a solution that will fully meet the client and user requirements (program specification)  The program specification will include a description of the:  Inputs to the process  operations the system performs for each input  output obtained for the corresponding input If there is more than one program in the system, the document is called a system specificationIf there is more than one program in the system, the document is called a system specification

25. 25 1.11 Design Stage How the solution will be built to satisfy the requirements  Complex problems are divided into a set of sub-problems  Programs and modules are defined  inputs, outputs, functions and processes  The use of formal program design techniques and programming standards are recommended  The most appropriate programming language will have been decided upon during the development of the design

26. 26 1.11 Design Stage (cont.)

27. 27 1.12 Coding Stage  Produce the programs that will make up the system  Complete when all code is written and documented, and compiles without any errors

28. 28 1.12 Testing Stage  Every program module needs to be tested according to the test plan developed in the design phase NOTE:  can be carried out while program is being developed  Remember, finding and fixing a fault a fault after software delivery software delivery is 100 more expensive than finding and fixing it than finding and fixing it during systems analysis or early design

29. 29 1.12 Testing Stage (cont.)  When the program is completed and all separate modules have been tested, a full test of the program is performed  any errors in the program will be corrected and the test repeated  If testing identifies changes required to the program design  analysis, design, coding and testing phases are repeated for the changes

30. 30 1.12 Testing Stage (cont.)  Systems test  programs are tested as a group  The system must be tested in all environments  Alpha test  test of the finished application completed internally  Beta test  tested externally  Simulation  used when live environment test is not possible, e.g. (nuclear reactor control, traffic light control)

31. 31 1.13 Implementation Support  If needs change and the amendments required are substantial, then the software lifecycle would be applied to the amendments  After installation it must be maintained according to the needs of the users.  When all the previous stages have been completed satisfactorily, the system is ready for implementation  User documentation or operating instructions may be required

32. 32 1.14 Definitions of Key Terms  Lifecycle  The complete lifetime of a software system from initial conception through to final obsolescence  The term is most commonly used in contexts where programs are expected to have a fairly long useful life

33. 33 1.14 Lifecycle Definition (cont.)  Lifecycle  Traditionally, a lifecycle is modeled as a number of successive phases:  user requirements  system requirements  software requirements  overall design  detailed design  component production  component testing  integration and system testing  acceptance testing and release  operation and maintenance

34. 34 Chapter 3 Data Analysis and Problems PART 2 STRUCTURE DIAGRAMS

35. 35 2.1 Definitions of Key Terms  Data Structure  A way of describing the relationship of the component parts to the whole  Technique  A rectangle containing a * means an iteration of all lower level boxes  A box containing a small circle represents a choice between alternative sets of data (a selection) * Iteration(Repetition) Selection

36. 36 2.2 Structured Diagram 1

37. 37 2.3 Structured Diagram 2

38. 38 2.3 Structured Diagram 3

39. 39 2.4 Organizing Information  A file is composed of records  Each record contains data organised in a defined structure  The components of this structure are called fields

40. 40 2.4 Data Structure Diagram (cont.)

41. 41 2.5 Record Structure  The fields in a record must be carefully designed to contain all the data that may need to be referenced for producing information  this task would be performed in conjunction with the client (e.g. name length, date formats) and the result would form part of the program specification

42. 42 2.6 General File Structure

43. 43 2.7 Fixed Length Records  Number of characters allowed in each record can be predetermined (size specific)

44. 44 2.8 Variable Length Records  Sometimes records in a file store variable amounts of data  It is not sensible to allow spare capacity in the field lengths  this would be highly inefficient use of the backing store  the more complex processing requirements needed to deal with variable length records may be justified  it is the responsibility of the design team to ensure that the processing/storage trade- off is sensibly chosen

45. 45 Chapter SUMMARY  Program development process  Structure diagrams  Organizing information  Fixed and variable length records