1. 1 Software Development Topic 1 The Software Development Process

2. 2 ► Analysis ► Design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance

3. Analysis Stage

4. 4 An Iterative process It is important to realise that the software development process is iterative in nature. This means that the problem will be revisited a number of times getting closer and closer to the required solution on each time round.

5. 5 Fact Finding Analysis is a fact-finding process, and there are five key questions that need to be asked, often repeatedly. These key questions are:  WHO?  WHAT?  WHERE?  WHEN?  WHY?

6. 6 People involved at the very beginning… ► Clients - the people who require the new system. They are the ones who need the new software developed. ► Project Manager - the leader of the software house. This person is responsible for the whole project and must supervise all steps and stages required.

7. 7 Systems Analyst What is a systems analyst?  A systems analyst observes, clarifies and models an existing system to assess its suitability for computerisation. In the process, the analyst could also find ways of improving the system.  The systems analyst must have a sound technical background. They may once have been programmers.

8. 8 Skills and techniques of the Systems Analyst The systems analyst must  extract the clients needs  document these needs in a formal way  communicate these to the designers

9. 9 Extracting the Clients Needs Extracting the clients needs is known as requirements elicitation. This is done by:  interviewing the client’s management personnel  making observation notes of the client’s business  The analyst will also inspect information sources used by the client to keep track of their business.

10. 10 Documentation The systems analyst must document the clients needs by drafting a formal report:  system specification

11. 11 The System Specification ► is the end result of the requirements elicitation ► is a written statement of exactly what the design team must go on to make ► It is often a legally binding contract It is extremely important to get this document right. Mistakes made later can be very costly.

12. Summary of the Analysis Stage ► Key Task: To define the extent of the software task to be carried out. ► Personnel: Client and Systems Analyst ► Documentation: The legally binding Software Specification

13. Design Stage

14. 14 Design Representations There are a number of commonly used forms of design representation in common use. These are called algorithmns. Examples include:  Graphical representations ► structure diagrams ► Flow Charts  Textual representation ► pseudocode

15. An algorithm is a sequence of actions that, when performed in the correct order, will solve a problem or task in a finite number of steps. Example Here is a simple algorithm to convert a Fahrenheit temperature to Celsius: 1 Subtract 32 from Fahrenheit temperature 2 Multiply by 5/9ths to get Celsius temperature So, 98.6°F - 32 = 66.6 66.6 * 5/9ths = 37°C What happens if you swap steps 1 and 2 - do you get the same answer? Design- What are Algorithms?

16. Pseudocode is not specific to any programming language. It is a design notation that can be implemented by programmers in any programming language Here is the Fahrenheit conversion algorithm represented as pseudocode to be implemented as program code: 1.1 Get temp(°F) 1.2 Set temp(°F) = temp(°F)-32 1.3 Set temp(°C) = temp(°F)*0.556 1.4 Display temp(°C) 1.1 Get temp(°F) 1.2 Set temp(°F) = temp(°F)-32 1.3 Set temp(°C) = temp(°F)*0.556 1.4 Display temp(°C) Design- Using Pseudocode

17. 17 Pseudocode – Another Example 1.Display information 2.Get details 3.Do calculation 4.Display answer Refine step 2 2.1display prompt 2.2get value 2.3while value out of range 2.4display error message 2.5get value 2.6loop Top level design Notice the numbering system Simple English words in a familiar program form

18. A Structure Diagram is another design notation that represents algorithms in a chart or graphical form Here is the Fahrenheit conversion algorithm represented as a structure diagram to be implemented as program code: Convert °F to °C Get temp(°F) Set temp(°C) = temp(°F)*0.556 Display temp(°C)Set temp(°F) = temp(°F)-32 Design- Using Structure Diagrams

19. Design -Common Structure Diagram Symbols A procedureA loop A decisionA single task

20. Design- Another Example Structure Diagram This example is for a simple tax payment procedure that decides what rate of tax a user must pay. Tax payment Get details IF earns > 30000 High rate payable Low rate payable Display amount to be paid YESNO

21. Top-down design is where a task or problem is broken down into stages that can be solved as individual parts. This structure diagram illustrates a top-down approach to identifying the stages of the problem solution. Is the process of breaking a big problem down in to smaller sub-problems. Design- Top-down Design

22. Stepwise-refinement is the process of refining stages down into steps until each step can be easily turned into code in a programming language. Design- Stepwise Refinement

23. Key Task: To design a method of solving the stated problem. Personnel: Systems Analyst and Project manager Documentation: A description of how the problem will be solved. This algorithm may be text based (pseudocode) or graphical (structured diagram) Summary of the Design Stage

24. Implementation Stage

25. 25 Implementation The next stage involves turning the carefully structured design into a working solution.

26. 26 Choosing an Environment Before we can implement a solution we must decide on the programming environment which is most suitable. Languages are generally designed for a specific purpose.

27. 27 Programming Languages

28. ‘Program Code tempF = txtTempF.Text tempF = tempF-32 tempC = tempF*0.556 lblTempC.Caption = tempC ‘Program Code tempF = txtTempF.Text tempF = tempF-32 tempC = tempF*0.556 lblTempC.Caption = tempC Pseudocode 1.1 Get temp(°F) 1.2 Set temp(°F) = temp(°F)-32 1.3 Set temp(°C) = temp(°F)*0.556 1.4 Display temp(°C) Pseudocode 1.1 Get temp(°F) 1.2 Set temp(°F) = temp(°F)-32 1.3 Set temp(°C) = temp(°F)*0.556 1.4 Display temp(°C) A formatted printout of the program code is known as a structured listing. It includes indentation, white space, internal commentary and colour coded keywords. Implementation- Structured Listings

29. Implementation- Creating Maintainable Code Code is easier to maintain when it is also very easy to read and understand. To achieve this you need.  short main programs  wise use of procedures and functions, creating variables close to where they’re used (modularity)  meaningful variable, constant, procedure and function names  appropriate internal documentation using comments  good program layout, including indentation, single statement lines, and spacing between sub-routines

30. Implementation- Example of Good Maintainability ' PROGRAM NAME : Final Circle Program ' AUTHOR : The teacher ' PROGRAM DESCRIPTION ' This program will ask the user to enter the radius of a circle ' which must be between 0 and 100. The program will then calculate ‘ and display the area and the circumference of the circle. ' Must declare all variables Option Explicit Private Sub Form_Load() 'Declare variables Dim radius As Single Dim area As Single Dim circumference As Single 'Get the radius Call get_radius(radius) 'Calculate the area of the circle Call calculate_area(radius, area) 'Calculate the circumference of the circle Call calculate_circumference(radius, circumference) 'Display the results of the calculation Call display_circle_details(area, circumference) End Sub

31. Implementation- Example of Good Maintainability Private Sub get_radius(radius) ' User enters the radius radius = InputBox("Please enter the radius", "Enter radius", _ "0", 1000, 3000) Call number_in_range(radius, 0, 100) ' Display radius lblRadius.Visible = True lblRadius.Caption = "Radius = " & radius End Sub Private Sub calculate_area_ (ByVal radius As Single, ByRef area As Single) 'Create a constant to represent pi Const pi = 3.14 'Calculate area area = pi * radius ^ 2 End Sub

32. Implementation- Example of Good Maintainability Private Sub number_in_range _ (ByRef number As Single, ByVal min As Single, ByVal max As Single) 'This is a Library Subroutine to check that a number is within a 'specific range 'The user is asked to renter when an invalid number is entered. 'Parameter number holds the value entered by the user 'Parameter min holds the minimum possible value that can be entered 'Parameter max holds the maximum possible value that can be entered Do If number max Then number = InputBox("Number is out of range._ Please re-enter a number between " & min & " and " & max, _ "Wrong entry", 0, 1000, 1000) End If Loop Until number >= min And number <= max End Sub

33. Implementation- Example of Poor Maintainability Private Sub Form_Load() x = inputbox(“Enter the radius”) y = x * x * 3.14 z = (2 * x) * 3.14 lblMadonna = "Area = " & y lblEltonJohn = "Circumference = " & z End Sub

34. Key Task: Write code in a chosen programming language based on the design. Personnel: Programmer and Project manager Documentation: A structured listing of the programming code showing formatting features such as colour coded commands, indentation, comments. Summary of Implementation Stage

35. Testing Stage

36. Testing- Features of High Quality Testing ► Creating a set of test data that tests every possible combination of inputs is extremely difficult and unrealistic. ► Testing should therefore strive to be both systematic and comprehensive ► Testing can only show errors but can’t guarantee that a program is 100% error free.

37. Testing- “Bug Type 1” Syntax Errors ► Syntax errors- breaking the rules for creating valid instructions in a particular programming language. ► Common sources include  Missing out some keywords  Using keywords in the wrong order  Spelling mistakes in keywords, function or procedure, variable and object names

38. Testing- “Bug Type 2” Logic Errors ► Logic errors- carrying out valid instructions that don’t solve the problem the program is designed to solve. ► Common sources include  Carrying out the wrong type of calculation  Performing the wrong type of comparison  Creating loops that do not execute the correct number of times

39. Testing- “Bug Type 3” Run Time Errors ► Run time errors- errors that only occur when the program is executed. ► Common sources include  Referring to an object or control that doesn’t exist  Trying to access an array value that doesn’t exist because it’s outside the index range of the array  Opening a file or other operating system object that isn’t there.

40. The program tester should set up a test log InputReasonExpected Output Actual Output 15Normal Test Mark You have passed You have failed Faults that become evident are known as bugs The test logs will be sent back to the programmers who then go through the process of debugging Comprehensive Testing Test Data Tables

41. The three types of testing are normal, extreme and exceptional. Comprehensive Testing Types of Test Data 3. Exceptional data - the data is not suitable for the program e.g. (i)values outside agreed ranges (ii)letters instead of numbers. 2. Extreme data - the data is at the extreme limits allowed and rejected data. e.g. if an age is to be between 0 and 120 then these two values are tested 1. Normal data - typical data that would be expected.

42. Example Program should only accept whole values in the range 0 to 100: Example Program should only accept whole values in the range 0 to 100: Comprehensive Testing Example Test Data Test Data Normal data: 2, 34, 66 etc. Extreme data: 0, 100 Exceptional: -1, 1000000, abc, 2.9

43. Testing is itself a structured process starting with individual lines of code and building up to a test of the entire system. 2. Component or procedural testing – Check that every individual procedure and function work correctly 1. Structured Walkthrough - Each line of logic in the code is stepped through by the programmer using a printed listing. Systematic Testing

44. 3. Module testing – Check that all the individual procedures and functions link together correctly as a module. 4. System (Alpha) testing - Finally, the overall system made up of tested sub systems is tested. Systematic Testing

45. 6. Acceptance (Beta) testing - is when independent test groups and/or the client try out the software and report back any bugs to the development team prior to final release. If the program has been developed for a specific client it will be installed and tested by the clients If the program has been developed for general sale it will be installed on potential clients’ systems Testing - Stages of Testing

46. Task 46 A procedure has been written which inputs the prices of components. The cheapest is a 5p, the dearest £99.99. Devise a set of test data for this procedure. Test TypeTest DataExpected ResultActual Result Normal3.50, 45, 89.32Input accepted Extreme0.05, 99.99Input accepted Exceptional0.00, -1, 100.00, abc, Input rejected – suitable message displayed.

47. Key Task: To test that the program meets the specification and that it is reliable and robust Personnel: Independent Test Group (ITG) Documentation: Sets of test data and test reports. The test data will have predicted (before running) and actual (after running) output. Summary of the Testing Stage

48. Documentation Stage

49. Documentation- User Guide User Guide can include the following 1.how to install the software 2.how to start and use the software 3.a list of commands and how to use them 4.it may also contain pictures of forms, menus and icons Audience: everyone who will use the new software

50. Documentation- Technical Guide Technical Guide can include the following 1.the hardware requirements 2.the software requirements 3.how to customise the software 4.how to troubleshoot any problems 5.any problems when installing and running software across a network Audience: anyone installing and setting up the software

51. 51 Documentation NOTE: Each stage of the SDP produces documentation: ► A – Software specification ► D – Algorithm ► I – Structured listing - Program code (internal commentary) ► T – Test report ► D – User guide and technical guide ► E – Evaluation report ► M – Maintenance report

52. Key Task: To produce documentation to be distributed with the software. Personnel: Client, Programmer, Project Manager Documentation: User Guide and Technical Guide Summary of the Documentation Stage

53. Evaluation Stage

54. Evaluation- Key Areas in the Evaluation Report

55. Evaluation- What do robustness and reliability mean? ► Robustness  A program is robust if it does not crash when invalid data is input or unexpected results are generated. ► Reliability  A program is reliable if for all normal and extreme inputs the output from the program matches the expected output. This happens when the program is free from errors.

56. Evaluation- What do portability and efficiency mean? ► Portability  A program is portable if it can run on a range of different computer hardware and operating systems software with little or no changes needed to the program code ► Efficiency  A program is efficient if it runs as fast as possible and does not use up more system resources than necessary. System resources include things like processor time, main memory and backing storage requirements

57. Evaluation- What do maintainability and fitness for purpose mean? ► Maintainability  A program is maintainable if it can easily be modified and updated to fix errors, add new features or work with new hardware and software. ► Fitness for Purpose  A program is fit for purpose if it fulfils the criteria set out in the software specification.

58. Key Task: To report upon the quality of the software according to given criteria. Personnel: Systems Analyst and Project manager Documentation: A evaluation report accompanying the software to the client. It compares the software to the original specification and also comments on the quality of the software. Summary of the Evaluation Stage

59. Maintenance Stage

60. Begins once the software has been released and put into use. Involves the client who uses the software and the programmers to make any necessary changes. There are 3 types of maintenance. Corrective: Fixing any errors that were not detected during the testing phase. Adaptive: To alter the software to work with a new operating system or new hardware. Perfective: Add new functionality at the request of the client. Corrective: Fixing any errors that were not detected during the testing phase. Adaptive: To alter the software to work with a new operating system or new hardware. Perfective: Add new functionality at the request of the client. Maintenance

61. Maintenance ► Types of maintenance carried out and typical values for each kind of maintenance  Corrective (17%)  Adaptive (18%)  Perfective (65%)

62. Maintenance- Who pays for it? ► Adaptative and perfective maintenance are paid for by the client ► Corrective maintenance is paid for by the developer because it’s due to errors that should have been detected and corrected during the Testing phase.

63. Key Task: To make changes to the software after it has been handed over to the client. Personnel: Usually the project manager, programmer and client will be involved. Documentation: A maintenance report will detail and confirm the maintenance carried out. Summary of the Maintenance Stage