Iterative Nature of the Development Process

1. Iteration = repetition or doing something over again. The software development process can be repetitive, especially in the early stages. Repeat early stages until software meets specification. Iterative Nature of the Development Process

2. Software Development Process There are seven stages to the software development process. Each stage has a key task, personnel and documentation associated with them. Analysis A Design Dance Implementation In Testing The Documentation Evaluation Dark Maintenance Every Monday

3. Analysis Stage Requirements of the system are identified and clarified. Systems Analyst(unlikely to be the programmer) Acts as the intermediary between the client and the software department. Will work for the software department/house. Would interview the client to discuss the problem and take observation notes within the workplace. Client Represents the company who require a new or updated system. Works for the company.

4. Analysis Stage cont…. • Stage involves: • Interview client and employees to discuss client needs. Clear picture of what needs done. (Questionnaire can be carried out) • Observe the workplace to view current system in operation. Day to day running. • Notes can be made of what tasks people carry out in their role as part of the system • Produce a report detailing the clients specific needs (Software Specification)

5. Software Specification • Document produced at the analysis stage which has the status of a legal contract between the client and the software company. • Software Specification is the result of examining the existing system, clearly identifying the needs of the client. • Clear description of exactly what the software has to do to meet the needs of the client. • Timescale, budget • Legal document

6. Design Stage Once the software specification is precise the design stage can begin. Program design is the process of planning the solution. The interface, structure and detailed logic of the software are designed. (pseudocode) Design of the program is very important. Time spent on the design stage can reduce the chance of errors appearing later on in the solution.

7. Design of Interface (HCI) • Ease of data entry for user – think about users computer skills e.g children or elderly • Help and instructions screens (online help) • Appropriate feedback on actions performed (meaningful error messages) • Will not accept user-friendly GUI

8. Design Methodology • Programmers can take a different approach to the design of the solution: • Modular design • Structure Design • Object Oriented Design

9. Modular Design • Method of organising a large computer program into sub programs. Breaking the program up into smaller parts. • Each part (module) are constructed so that they can be designed, coded and maintained independently. • Forms of Module design: • Top-Down Design (Stepwise Refinements) • Bottom-up Design

10. Top Down Design (Stepwise refinement) Involves looking at the whole problem (top) and breaking it down into smaller, easier to solve, sub-problems. When stepwise refinement is complete, then the programmer can create the algorithm.

11. Bottom up Design Begin with the lowest level of detail and work upwards. Sometimes better to work this way by writing the sub program and module first.

12. Advantages of using modularity • Improves readability of the program • Aids Maintenance • Splits the problem into more manageable sections which can be easily allocated amongst the programming team.

13. Design Notation • A way of representing the program using different designs. Common design notations include: • Flow Charts • Structure Diagrams • Pseudocode *

14. start ask for length take in length ask for breadth take in breadth make area = length x breadth display area stop Flow Charts Use diagrams made up of differently shaped boxes connected with arrows to show a graphical breakdown of each step required. In general, they are read from top to bottom. Advantage Shaped boxes show constructs in program and links to show sequence Problem Complex programs can become unreadable. Difficult to represent multiple decisions.

15. Calculate Area of Rectangle display area get dimensions calculate area make area = length x breadth ask for length take in length ask for breadth take in breadth display area Structure Diagrams Use differently shaped boxes to show the various sub-problems within the program. In general they are read from left to right. Advantages Uses linked boxes showing hierarchy. Useful for showing overall structure and data flow. Problem Can become complicated as each shape represents a different step.

16. Pseudocode A step by step detailed solution of the problem using English words. Main Steps 1. Get dimensions 2. Calculate area 3. Display area Step 1 1.1 ask user to enter length 1.2 take in length 1.3 ask user to enter breadth 1.4 take in breadth Step 2 2.1 make area equal to length multiplied by breadth Step 3 3.1 display message and area Advantages Useful when using visual basic, because it fits in neatly with the structure of the code. The main steps in the algorithm relates to the main program.

17. Documentation Produced Program design (algorithm) in an appropriate design notation and the design of the user interface. Personnel Involved System analyst and the project manager The project manager is the person within the software company who overseas the whole project. Makes sure the correct personnel are involved and communicates with the client.

18. Implementation Once the design stage is complete, the programmer is ready to implement the program. Implementation is changing the program design into a set of instructions that the computer can understand and the production of internal documentation.

19. Guidelines (Handout) • Program should be modular (broken down into procedures and functions). • Meaningful variable names should be used. • Internal commentary should be used to explain the function of the code throughout the program listing. • Procedures and functions should not be too large and complicated. • Pre-written module libraries should be used to save time in writing and testing of code.

20. Internal Commentary (readable) Useful if you, or someone else, has to look back at a program. Good internal commentary will help the programs maintainability. Helps understand what each lines, procedure or function is suppose to do.

21. Choosing a suitable language Factors to consider: Type of data that the language has to support. E.g. numbers, text, graphics or sound. Arithmetic and logical operations that are required, and whether the language has to support these e.g. string operations to create substrings, join string together and so on. The platform environment in which the program will operate. (Mac or Windows?) Speed of execution if the software is important, then a language that gives a fast response time will need to be chosen. Skills of the programming team must be considered - experience

22. At this stage the programmer or a team of programmers are involved and use the design to produce software which is; (Look closer under the evaluation stage) Correct/fit for purpose – the software matches the original specification. Maintainable – Any changes or updates to the software can be made without difficulty. Reliable – the software is free from design and coding bugs and produces the expected results for all test data. Readable – another person should be able to read and understand the coding. The use of meaningful variable names and internal commentary makes this easier. Portable – the ability of software to be used on a computer other than that for which it was originally designed. Efficient – the software does not require excessive resources, such as memory or backing storage space, in order to run. Robust – the ability of software to cope with unexpected events without crashing.

23. Documentation Produced Program Code using a programming language, such as, visual basic. The programming code will have internal documentation. Benefit Internal documentation explains the purpose of the each line of code. Ease for upgrades and maintenance. Personnel Involved Project manager and programmer. Programmers Design and write the program code, working from the software specification.

24. Testing Stage Testing makes sure the program actually solves the problem it is supposed to and can show the presence of errors. Testing the program means you have to run the program to see whether or not it behaves as expected. Testing should be both systematic and comprehensive. Systematic Testing Means that your testing should follow a plan. Involves a progression through testing subroutines to test the whole system. This testing should be fully documented.

25. Types of testing (Systematic) Acceptance Testing (Beta testing) Once tested by the developers, it is tested by the clients in the situation in which it will be used to make sure the program is fit for purpose. Formal process, documented in which users use the new system, verify that it works correctly under operational conditions, and note any errors that need fixed.

26. Comprehensive Testing Test the program as thoroughly and completely using a full range of input data (test data). Using Test Data (Comprehensive Testing) Test data is chosen to test that the software can cope with as many cases as possible. Normal, boundary and exceptional data should be used to test the software.

27. Test Data Test data must cover all possible conditions. Expected results must be known in advance.

28. Example Test Data Write a program that will take in three whole numbers and calculate the average. Numbers entered must be between 0 and 30. Normal test data Input Expected Output 10, 25, 17 17.3 Within the limits that the program should be able to deal with. Extreme (boundary) test data Input Expected Output 0, 1, 30 10.7 Data which is at the ends of the acceptable range of data. On the limits or boundaries.

29. Exceptional Test Data Input Expected Output -1 Out of range 31 Out of range 0.3 Not a whole number Enter text Not an integer Data which is invalid. Well written programs should be able to detect any exceptions, warn the user of the error, and give them another chance to enter data. This is done by input validation.

30. Types of Errors • Execution with run-time errors • Compilation with syntax errors • Logical Errors

31. Execution/Run-time Errors • Errors which show up during program execution • Overflow- something becomes to large to be processed accurately. • Rounded- numbers are rounded up (+0.01) • Truncation- numbers are rounded down (+0.01) • Division by zero – instructed to divide by zero, which will generate an error and crash the program.

32. Compilation/syntax errors • Error which is detected during the process of compilation of the program. • Linkage errors(linking sub programs (modules) – sub program (modules) not present) • Syntax errorsrules of the program language are broken • Misspelling of language keywordse.g. PRNT “Hello” • Missing inverted commasPicdisplay.print “Hello • A For….Next loop with a For but no Next.

33. Logical Errors Mistakes in the design of the program. Program does not do what it is suppose to do. (produce wrong result) Example Code could be written to add two numbers instead of multiplying them, or subtract two numbers the wrong way round. Area = Length + Breadth

34. Detecting Errors Manually Techniques used to locate and remove errors. Dry Run Involves stepping through the program instructions and manually working out on paper how the program variables are updated. It is a pencil and paper exercise. Usually carried out on a small part of the program (such as a procedure) Structured Walkthrough Involves following through the logic of the instructions line by line using a structured listing of code.

35. Structured Listing • A formatted printout of the programming code. The formatting should make the program readable. • Features of a structured List: • Indentations to show structure of program • Blank lines between code • Capitalised Words • Bold/colour keywords • Line numbers • Internal commentary • Modular coding • Meaningful variable names • Advantage • See at a glance where each of the program control structures begins and ends. • More likely to spot mistakes.

36. Techniques used to locate errors using the software development language Many software environments have built in features to help programmers check for bugs which cause errors. Trace Facility Allows programmer to follow the path through he program at the same time as it is being run. Goes through program one line at a time.

37. Documentation Produced • Sets of test data and test report. • Documentation may help to identify areas where testing was inadequate. • Personnel Involved • Independent test group (ITG) • Independent Test Group • Set in order to test software. Not associated with the software company or the programmer. • Examine code • Document tests • Re-test software • Document errors found • Repeat all tests on the corrected code

38. Documentation • Users will need to be able to read and learn about the new system. The documentation should include: • User Guide • Technical guide • User Guide • Guide on how to use the actual software. This guide will be written by the programmer. • Getting started notes • Tutorial guide (online Tutorial) • Manual on how to use program • This may be supplied on a separate CD-ROM.

39. Technical Guide • Explanation on how to install the software. Again this will be prepared by the programmer. • Includes: • Installation Requirements (type of OS, amount of RAM and backing storage) • Hardware requirements (speakers, scanner) • Explain how to edit or make changes to software. • Troubleshooting Guide • Dual Platform • Software which is capable of being installed on two completely different platforms, e.g. windows and Mac. • Additional Documentation • License agreement

40. Documentation Produced User Guide and technical guide Personnel Involved Client, system analyst and programmer

41. Evaluation Involves reviewing the solution against suitable criteria. Important to evaluate it in terms of whether or not the original requirements have been met. The software is evaluated by judging it against a set of criteria: Robust Reliability Portability Efficiency Maintainability Readability Correct/Fit for purpose User Interface

42. Documentation Produced Project report (Evaluation)

43. Maintenance • Changing the program, often some time after it has been written. Creators of software systems often establish help desks, so users can obtain advice about the software. • Once the product has been delivered to the company the clients will pick up on errors which were missed during the intense testing. • Types of Maintenance: • Corrective Maintenance • Adaptive Maintenance • Perfective Maintenance

44. Corrective Maintenance Is concerned with errors that escaped detection during testing but which occur during actual use of the program. These errors will be removed by the development team.

45. Adaptive Maintenance Is necessary when the program's environment changes. It allows the authors to provide a program which responds to changes in the operating environment. For example: a change of operating system could require changes in the program (Windows to Vista) Or a new printer might call for a new printer driver to be added to the program. Involves adaptation as a result of change in software or hardware. – remember to give examples.

46. Perfective maintenance Occurs in response to requests from the user to enhance the performance of the program. This may be due to changes in the requirements or new legislation. Clients will not incur costs for corrective maintenance, since the developers have met the legally binding contract stated in the software specification. Any adaptive or perfective maintenance involves change to the system outside the requirements, and of course the client must pay for both these maintenance activities.

47. Typical Questions • There are three different types of maintenance which can be carried out on a piece of software once it is distributed. Name and describe each type. • Software development companies spend most of their time in maintaining existing software rather than develop new systems. Therefore it is very important to produce software that is relatively easy to maintain. • The following factors will affect how easy it is to maintain a system: • Staff mobility • Poor Documentation • Modularity • Programming Language used (Low Level/high Level)

48. Maintainability Don't confuse maintenance with maintainability. Maintainability Software that has been written using meaningful variable and procedure names. Makes use of comment lines. Fully documented. Written in modular design using local rather and global variables. Why? This allows the programmers at a later date to modify and update the program.

49. Documentation Produced Maintenance report. Personnel Involved Programmer and client are essential at this stage.

50. Iterative Nature of the Development Process Iteration = repetition or doing something over again. The software development process can be repetitive, especially in the early stages. Repeat early stages until software meets specification. REPEAT Analysis – re-interview client to gather more info Design Implementation Testing Documentation Evaluation UNTIL your software meets the specification