1. Software Development Process Higher Computing Unit 2 – Software Development

2. What I need to know  Explanation of the iterative nature of the software development process  Description of the purposes of the software specification, and its status as a legal contract  Explanation of the importance of each stage (analysis, design, implementation, testing, documentation, evaluation, maintenance) of the development process  Identification of the personnel at each stage (client, systems analyst, project manager, programmer, independent test group) and brief description of their roles  Description and exemplification of pseudocode and one graphical design notation (structure diagram or other suitable) including data flow

3. What I need to know  Description and exemplification of top-down design and stepwise refinement  Explanation of the need for systematic and comprehensive testing  Explanation of the need for documentation at each stage  Evaluation of software in terms of robustness, reliability, portability, efficiency and maintainability  Description and exemplification of corrective, adaptive and perfective maintenance

4. Iterative Nature of SDP  Definition:  Stages may be revisited as a result of information gathered at a later stage. The solution is constantly being refined.  Example  An error is found during testing so the programmer revisits implementation to fix the code.

5. Software Development Process Analysis Design Implementation Testing Documentation Evaluation Maintenance

6. Analysis  Purpose  To get a clear understanding of the problem in order to provide the solution.  The analyst extracts unambiguous information from the client, and other relevant people, during requirements elicitation. This may take the form of interviews with staff, observation of system or document sampling.  The client and the analyst agree the scope and boundaries which are included in the software specification.

7. Analysis  Documentation Produced  Software Specification  A formal specification of the scope and boundaries of the problem. It is part of a legal binding document between client and development team.  The client uses the software spec so that they know exactly what they are getting.  The development team refer to this document to ensure they are producing the correct solution

8. Analysis  Personnel  Client  The client commissions the software, describing the scope and boundaries of the problem to the analyst.  Systems analyst  Agrees with the client the detailed specification of the software to be written. This should be completed to the satisfaction of both parties before the design or coding is carried out.

9. Design  Purpose  Program design is the process of planning the solution.  The design of the program is very important for its success. Any mistakes at this stage will prove costly.

10. Design  Documentation Produced  Algorithms;  Structured Diagrams; &  Flow Charts These will be covered under Design Notation

11. Design  Personnel  Programmer  The programmer uses the system specification to produce the design using an appropriate design methodology.  Project Manager  Is the person within the software company who overseas the whole project.

12. Design Methodologies  This is the approach that the programmer takes to design the solution;  Design methodologies are:  Modular;  Jackson Structured Programming (JSP); &  Object-oriented Programming (OOP’s).  We only look at modular.

13. Modular Design  This is when we take a large program and break it down into self contained parts called modules.  Each module can be developed by a member of the programming team, speeding up programming.  Each module is constructed so that it works completely independent of other modules.  Some are linked to other code whilst some are separate programs.

14. Modular Design  Top-down Design  This involves looking at the whole program and breaking it down into smaller, easier to solve, sub- programs.  Each sub-program may be further broken down into smaller steps. This is called Stepwise Refinement (remember 1.3.4?)  When the sub-program can be no longer refined the process is finished and you have your algorithm.  At this point each step can be converted into code.

15. Modular Design  Bottom-Up Design  This begins with the lowest levels of detail and works upwards to the highest level of the idea.  Using a bottom-up design approach means writing modules or procedures first.  This is called prototyping, where you construct a procedure separately before joining it together with the rest of the program.

16. Design Notation  The way of representing the program design is called the design notation.  Common design notations are:  Pseudocode;  Structured diagram; &  Flow chart.  Pseudocode uses English-like sentences.  Structured Diagrams and Flow Charts use graphical objects to represent the design.

17. Design Notation  Pseudocode  Pseudocode is the name given to the language used to define problems before they are changed into code.  Algorithms show the logical flow of the program.  One line of pseudocode can usually be translated into one line of code.  Pseudocode is very useful when writing in a HLL, because it fits in neatly with the structure of the code. The main steps in the algorithm relate directly to the main program, the refinements of each sub-program become the code in the procedures.

18. Design Notation  Pseudocode 1.initialise 2.take in numbers 3.calculate average 4.display message Refine Step 2 2.1loop 2.2increment counter 2.3ask user for number 2.4accept number 2.5until counter = amount required Refine Step 2.4 2.4.1loop 2.4.2get number from user 2.4.3if number is out of range then 2.4.4display error message 2.4.5end if 2.4.6until number is within an acceptable range

19. Design Notation  Flow Charts  These use diagrams made up of boxes connected with arrows to show each step in a program.  One problem with this type of representation is that even the simplest program that has several conditions can quickly become unreadable.

20. Design Notation  Flow Charts Start End Initialise Calc Average Get Numbers Display Msg Get Numbers Display Error Is no within range?

21. Design Notation  Structured Diagrams  Like flow charts, these use linked boxes to represent different sub-programs within a program.  The boxes in a structured diagram are organised to show the level or hierarchy of each sub-program within the solution.  Structured diagrams follow a left to right solution.

22. Design Notation – Structured Diagram Average Program InitialiseGet NumbersCalc AverageDisplay Msg Loop until counter = no required Add 1 to counter Ask user for number Accept number Loop until number Is within range Get Number From user Is no within range? Get Numbers

23. Data Flow  Giving an indication of the flow of data between modules is important.  Some design notations allow data flow to be shown clearly.  Pseudocode uses the terms in:, out: and in-out: to represent the flow of data in sub-programs. This is covered in more detail in a later topic

24. Implementation  Purpose  To turn the design into a set of computer instructions that the computer can understand.  The program will probably be in high level language that is easy for the programmer to write.  This usually means programming in a computer language such as C++, VB, Java.

25. Implementation  The programmer will choose the computer language that they will write the program in.  The chosen language will depend on a number of factors, e.g. the computer platform the software is expected to run on, the operating system in use.  All of these factors affect the portability of the software.  A program that is portable is one that can be used on more than one platform. Runrev is cross platform, therefore it is portable.

26. Implementation  Also at this stage will be internal documentation/commentary:  This is commentary that is written within the program to explain what the program is doing.  This makes maintenance easier and the program is more readable.  Internal commentary is also used to record any changes that might be implemented in the coding during debugging/testing.

27. Implementation  Documentation Produced  Program/Structured Listing  This is a hard copy of the program code  Personnel  Programmer  The programmer uses the design and converts it into code  Project Manager  Is the person within the software company who overseas the whole project.

28. Testing  Purpose  To test that the program actually meets the specification.  You have to run the program to see whether or not it behaves as expected.  To carry out proper comprehensive and systematic testing it is necessary to develop a test plan for every part of the program.

29. Testing  A test plan should outline what you are trying to test and how you are going to do it:  What programs (or module) is being tested  What the program (or module) should do  List suitable test data (normal, extreme and exceptional) which can be input into the program  Expected results or desired outcomes from the test data

30. Testing  Comprehensive testing means that you test your program as thoroughly and completely as you can.  It would be ideal if it was possible to test every part of a program with all kinds of test data. This is called exhaustive testing.

31. Testing  Testing can never show that a program is correct or completely free of errors.  Even with extensive or exhaustive testing it is almost certain that undetected errors/bugs still exist.  Exhaustive testing can only show the presence of errors, it cannot demonstrate their absence.  A program can be regarded as succeeding if it passes a test; the test can be regarded as succeeding if it makes the program fail.

32. Testing  After the program has been written, it is given to a group of trusted users so that it can be used under normal circumstances.  The users fill in a report, which is passed back to the development team to make any adjustments or improvements prior to release.  This is call beta/acceptance testing.

33. Testing  Documentation  Set of test data  Test Report (Summary of Testing)  Personnel  Independent Test Group  Carries out testing of the software. This may be modular testing and/or component testing, looking at important subsections of the code.  Programmer  The programmer will carry out testing at component, modular and system level.  Project Leader  Carries out testing at system level ensuring that the program meets the software spec before being tested at Beta level.

34. Documentation  During this stage the documentation which is to be distributed with the software is produced.  There are two types of user documents produced:  User Guide  Explains how to operate the software once it is installed  May include getting started notes, tutorial guide and a reference guide  Technical Guide  Includes a description of the technical requirements needed to run the software. Also Installation instructions.

35. Evaluation  Evaluation is reviewing the solution against a given criteria.  The criteria against which you should evaluate software are:  Robustness;  Reliability;  Portability;  Efficiency;  Maintainability; &  Readability.

36. Evaluation  Robustness  Is the software able to cope with errors during execution without crashing? Including good error/exception handling makes a program robust.  Reliability  How well does the software operate without stopping due to design faults? The software should not crash if the data entered is within acceptable limits.

37. Evaluation  Portability  Is the ability of the software to run on a system other than the one it was designed for. A program which is portable should require no changes to run on a new system  Efficiency  Does the software require excessive memory, backing storage and processor resources to run?

38. Evaluation  Maintainability  How easy will it be to correct/update the software in the future.  Factors affecting maintainability are:  Readability of the code (incl. meaningful variable names)  Modular Programming  Available system documentation  Is the program written in an established language.

39. Evaluation  Readability  How easy is it for another person to understand the program code?  Have you used:  Meaningful variable names  Structured listings  Modularity  Internal documentation

40. Evaluation  Fitness for Purpose  Does the solution solve the original problem?  Does it meet the software specification?

41. Evaluation  Personnel  Programmer  Project Leader  Both complete the evaluation based on how the project went and focusing on test data/questionnaires retrieved from clients  Document Produced  Evaluation Report

42. Maintenance  Maintenance is when the programmer makes changes in the form of corrections or updates to the program at some time in the future, once the client has the software, and is made easier by good practice and development.

43. Maintenance  There are three types of maintenance:  Corrective Maintenance  To fix errors not found during the testing stage. The cost of these are the responsibility of the development team  Adaptive Maintenance  Carried out to adapt the software to a change in its environment. Cost is usually met by the client.  Perfective Maintenance  Carried out to add new features at the request of the client. Cost is met by the client.

44. Maintenance  Documentation  There will be a maintenance report.  Depending on the extent of the maintenance, all documents may have to be revisited and re-done.

45. Maintenance  Personnel Involved  Programmer  Required to make changes to design, code, to re- test etc  Client  Required to explain what need to be changed within the program.

46. Project Documentation  There are two types of documentation produced during a project:  User Documentation  Any documents that go to the client – User Guide and Technical Guide  System Documentation  Any documents that stay with the programming team – software spec, analysis report, pseudocode, structured diagram, flow charts, test report, copies of user documentation, evaluation report and maintenance report.