Software Development Unit

Transcription

1 Software Development Unit me Topic 1 THE SOFTWARE DEVELOPMENT PROCESS Computing Studies Department Whitburn Academy Page 2

2 INTRODUCTION Most computerised systems that we use in every day life we take for granted, but how did they come into existence? Where did the "hole in the wall" banking, batch sent bills, store cards, software such as word processors etc. actually come from? How were they developed? Who was responsible for developing them? What was their role in the creation of these systems? First Steps Most creations start with an idea in someone's head. For example, questions like: Sometimes groups of people are involved in brainstorming these ideas. Ideas, however, are not precise specifications of what the imagined system should do, nor of how it should be built. They are merely the first steps in the creation of a system. Computing Studies Department Whitburn Academy Page 3

3 Need Computerised systems are developed, as are most creations and inventions, from perceived needs and a reckoning that certain advantages will arise. Consider the banking systems of today. What can we see as the benefits that computers have brought to these businesses? What advantages were foreseen by the managers and directors who commissioned the construction of these systems, investing millions of pounds in the process? Perhaps they were thinking along the lines of: improving the efficiency of dispensing and depositing cash a more flexible service for customers which provided 24 hour access to their accounts giving more accurate and up to the minute reporting of transactions expanding their customer base and the management of larger databases of information reducing their staffing levels reducing queues in bank branches international banking Solution Often people who generate such ideas have no expertise in building the final product. We don't really expect managers and directors of companies to be expert programmers. So how do these ideas become reality? There has to be a method of transforming these ideas into a form that can map onto a computer system. There has to be a way of translating a verbal or textual description of an idea into a programming language and its hardware environment. So what are these steps and who is responsible for taking them? Management Personnel The clients are the persons who require the new system. They are the ones who need the new software developed. The project manager is the leader of the software house. This person is responsible for the whole project and must supervise all steps and stages required. Initially the clients would meet with the project manager to ensure that the system that needs to be developed is economically, technically and feasibly possible. If the system is possible only then will it be taken on by the software house. Computing Studies Department Whitburn Academy Page 4

4 1 - SYSTEMS ANALYSIS THE TECHNIQUES AND TOOLS Supposing your teacher asks you to build a piece of software that will teach five-yearolds about how the body works. Sure, you say, and immediately rush off to your favourite PC, eagerly call up your programming tools and then...what? Do you really have enough information to go ahead and build a system? Of course not! You need to find out lots more about the system that your teacher had in mind. Firstly, who is going to use the system? Well, it s for five year olds. What do you know about the best ways of presenting information to learners of this age? Realising the need to explore the original idea a little closer you may start asking questions such as: How should I teach about the body? Should I use diagrams? What will a child of this age already be familiar with? Should I use text to describe bits of the body? Will animation and sound capture their interest? What level of language should I build into the program? Is colour an important tool for learning at this age? Should I provide some interaction and if so what devices are most suitable? In stepping back from the temptation to rush in and code the program you will have started the first, and most crucial, stage of the software development process. You will have started to ANALYSE. You will have taken the first steps away from being a programmer and towards becoming an 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. Computing Studies Department Whitburn Academy Page 5

5 1.1 Skills and techniques of a systems analyst Systems analysts need to have a very sound technical background. It is likely that they were once themselves programmers, highly skilled in coding, testing and debugging software. They will be knowledgeable in a variety of hardware platforms and operating systems. As analysts they will also have acquired new and quite different skills, the most important of which is the ability to communicate well with their clients. It is fundamentally important that a system is developed which meets the needs of the client. Anything less is simply useless. The client will be dissatisfied, with money and time misspent. If we bear in mind that the clients are not usually technically skilled, then we can see that the analyst must develop ways of extracting their needs, documenting these needs in some formalised way and, finally, communicating them to the team of designers and programmers who will build the system. We can consider the analyst as an intermediary between the client and the development team. 1.2 Extracting the client s needs This is sometimes called requirements elicitation. It can be a long task, because, at the start, the client may not be fully aware of the possibilities of a computerised system, and the systems analyst will probably not be fully familiar with the client s business operations. The analyst might begin by interviewing the client s management personnel to get a clear statement of what needs to be done. Then the analyst could make observation notes of the operations of the client s business to find out what actually happens in the workplace. Another important stage is inspection of the information sources that the client is already using to keep track of the needs of the business. The end result of the requirements elicitation process is a written statement of what the client wants the design team to do - the requirements specification. This document is the basis for everything the design team goes on to make, so it is extremely important to get it right. Computing Studies Department Whitburn Academy Page 6

6 The analyst will also need to be able to document the needs of the user in a formal structure, and not merely in note-taking form. Functional reports such as the abovementioned requirements specifications and systems specifications will need to be drafted. With regard to the technical documentation needed to communicate the operations of the proposed system, the analyst will need to be able to use both textual and graphical means of representation, e.g. in pseudocode or structure chart form. Finally, the analyst must always be prepared to anticipate change. User requirements may alter. Communication isn t a clear-cut, single event. There may be several meetings that have to take place between the client and the analyst. The need to clarify what has been said, and what is meant by what has been said, will often arise. This is an iterative process and need to be repeated until both sides are in complete agreement. There may also be technical and/or financial limitations that will require changes to the original ideas. Sometimes ideas are too costly to implement, and compromises may have to be made. Sometimes there just isn t the technological capability - although the required products might be in the pipeline of some research project somewhere!! (Recall how swiftly memory capability and processor speeds have developed in the last two years alone). Sometimes the analyst may want to produce a solution more advanced than the clients needs. It is necessary to limit the scope and boundaries of the development. This should prevent time being wasted on developing a solution that is more advanced than the client needs and should limit the time and costs spent on development. Revisiting the requirements elicitation stage of the project in this way is an example of the iterative nature of software development. It is very important that changes in the requirements are identified early, so that changes in the design can be made without too much additional work, and the project can be kept within its planned timescale. Computing Studies Department Whitburn Academy Page 7

7 1.3 CASE Tools CASE stands for Computer Aided Software Engineering. Since the early 1980s, computer programs have been developed which help analysts and designers with each of the stages of the software development process. A CASE TOOL KIT is a set of integrated CASE tools that have been designed to work together and to automate (or provide automated assistance for) the entire software life cycle, including analysis, design, coding and testing. Using such a toolkit speeds up the development process in a number of important ways. 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? Notice that we are not asking HOW? during analysis. HOW? is a question which will require the analysts to specify any hardware and software that will be used to implement the solution. During analysis we are simply trying to find out what the nature of the problem is and whether it can be solved. We are not solving the problem...yet! Questions 1. Explain using your own words what a system analyst does? 2. The first step in the analysis process is to extract the client needs. What are the next two steps? 3. Explain in your own words how a system analyst would extract the client s need. 4. What is a requirements specification? 5. What are the five key questions in the fact-finding process? 6. Why is How? not one of the questions asked at the analysis stage? Computing Studies Department Whitburn Academy Page 8

8 2. SYSTEMS DESIGN Once the needs of the user are clearly understood and documented, software development can move onto the next stage, involving the DESIGN of the system. We are now moving from asking what needs to be done to asking how are we going to do it. We need to use a structured and methodical approach to the planning of our solution. One such structured approach is to break your design down into the following three activities. Design of the User Interface Design of the structure of the software Design of the detailed logic of the software. 2.1 The user interface Design of a good user interface is one of the most important indicators of a high quality piece of software, and should be given much consideration. It is, after all, the link between those intricate sections of code that you have laboured on for months, and the end user. It doesn t matter how clever you have been in optimising the speed of your code, or minimising the memory overheads of your program, it is not acceptable if it is too complex, or unintelligible in its interaction with your user. You only need to look at the design of conventional WIMP operating systems, and their success in the world market, to appreciate that the most influential selling point is how the system appears to the user, and how easily such a wide audience of people are able to interact with it, and get it to do things for them. There are many different ways of having a dialogue with the user, including: Screen menus, where the user selects from a choice of options. The selection device can be a mouse, or a light pen, or indeed their finger, if a touch sensitive screen is being used. Via a WIMP style interface, where icons are used to symbolise objects, such as the wastebasket, or the hard drive, or files and folders on backing storage. Pointing devices such as the mouse, or light pens can be used to select commands from menus and issue commands to the system. Whatever form of interface that you may select to present to the user, or the devices that you opt to use for interaction, there is a set of guidelines that should be used when setting up a dialogue. These guidelines are detailed in the following list. Computing Studies Department Whitburn Academy Page 9

9 Building a user interface - some guidelines RULE 1 RULE 2 RULE 3 RULE 4 RULE 5 RULE 6 RULE 7 RULE 8 RULE 9 RULE 10 RULE 11 RULE 12 RULE 13 RULE 14 RULE 15 There should be a consistent format for menu selection, command input and data display. The system should offer meaningful feedback through visual and/or auditory prompts. The system should verify any non-trivial destructive action by providing a DELETE YES/NO? dialogue. The system should permit easy reversal of most actions by providing an UNDO option. The system should reduce the amount of information that must be memorised in between actions. The systems should organise commands by type in pull-down menus where these are applicable. The system should provide HELP facilities. The system should use simple action verbs or verb phrases to name commands. The system should display only that information relevant to the current context. The system should present information in a format that permits rapid assimilation, using pie-charts, graphs etc.., where applicable. The system should use consistent labels, standard abbreviations and predictable colours. The system should provide meaningful error messages. The system should use windows, where applicable, to compartmentalise information. The system should minimise the number of input actions required at any one time by the user. The system should tailor the language level of the HCI to the level of the user, providing multiple language levels if possible. It is always good practice when designing a user interface to bear these simple rules in mind. As a starting point, the designer might make a table, with a checkbox for each rule, that can be ticked off by cross-referencing with the design. A useful exercise at this stage might be to match these rules against your favourite piece of software, or perhaps some software that you use in your lessons. There is a suitable checklist at the end of the notes. How highly does your chosen software score on interface design? Computing Studies Department Whitburn Academy Page 10

10 Screen designs It will be necessary to document the HCI in some way that can be communicated to the design team who will eventually build the system. A useful approach is to design how the interface will appear on paper. This should include screen layouts, with indicators of colour, text sizes, styles, outline boxes of any objects that are to appear, such as pictures, animation sequences, menu options etc. Below, as an example, is a typical screen design for a simple menu-driven interface. Student Details 1. Enter student details 2. Update student details 3. Exit Please enter 1, 2 or 3: These paper designs are often fairly rough, at least to begin with. Usually, they will not be put into their final form until after the first attempts have been seen on the computer screen, when they often get revised and a second attempt made. This iterative approach to design is very common, and hopefully results, in the end, in a better software product. Computing Studies Department Whitburn Academy Page 11

11 2.2 Design of the structure and detailed logic You will already have encountered in your programming courses the structured, topdown design approach of stepwise refinement, and we will not need to go into much detail of this here. There are two methods of representing a design that we will concentrate on in these notes. The first is the representation of the structure of the software using a structure chart. The second is the representation of the logic of the software using pseudocode. Some developers use only pseudocode, to document the various stages of their refinement and outline the structure of the software; some use only structure charts; others may use yet another design method or a combination of methods. The important point is that there must be some documented evidence of this stage of the design. It is far easier to correct logical mistakes, or to upgrade a piece of software, by using structure charts or pseudocode listings, than by referring to the actual program code, because the structure charts or pseudocode listings make it easier to understand how the software was built in the first place. The structured design approach of stepwise refinement also allows you to manage a very large project, by sub-dividing it into chunks of functionality. Each chunk can be further refined, producing an hierarchical structure. These structures are much simpler to develop, to understand and to maintain. Top level First level decomposition Second level decomposition Software development produces a hierarchical structure There is an example of a structure diagram on page 35 of this booklet. Have a look at that page before tackling the questions on page 13. Computing Studies Department Whitburn Academy Page 12

12 Questions 1. Name the three main steps of the design stage. 2. What is a user interface? 3. A WIMP style interface uses a mouse as a pointer. State two advantages of this type of user interface over a command driven interface. Can you think of any drawbacks to a WIMP user interface? 4. Launch your programming language and study its user interface using Rules There is a sheet on page 61 to help you with this task. a Identify which rules your programming environment does not meet? b In the overall context of a programming language, does it matter that certain rules are not met? Give reasons. 5. Produce a structure chart for the following algorithms. Remember to look at page 34. The only other box you will need is a decision box and a simple example is given below. Answer correct? YES Display correct NO Display wrong a) Palindrome Problem b) Quiz instructions repeat fetch a word reverse the word if the word is not a palindrome print suitable message until the word entered is a palindrome print a closing message instructions repeat five times ask a question fetch the answer if the answer is correct print congratulations message else print error message Computing Studies Department Whitburn Academy Page 13

13 3. IMPLEMENTATION This is the third stage of the software development process and involves the translation of the design that you have constructed, through screen layouts, structured charts and pseudocode, into a form that the computer can understand, i.e. a program code. The aim of the design stage is to allow us to produce program code which is : CORRECT EASILY MAINTAINED RELIABLE (meets the (subsequent changes can be (free from design and specification) effected easily and quickly) coding bugs; correct for all specified inputs) READABLE PORTABLE EFFICIENT (design and code (may be adapted to run on (should not require time should be easily computers other than that or storage resources understandable by on which it was designed) disproportional to the other people) scale of the program) 3.1 The program code as part of the documentation. Before we discuss the selection of an appropriate programming language, you should understand that the program is itself a piece of documentation. Often this program or source code may need to be tested, updated and maintained by developers who did not take part in the original programming exercise. A common technique in trying to test a piece of software is to conduct a structured walkthrough (step through each line of logic in the code) using a structured listing, which is simply a formatted display or printout of the code. It is important that the code is written in such a way that helps the above activities. The following points are needed in good code: The code should be modular - procedures and functions should be used. Use should be made of library modules. For example in a mathematical context procedures for solving equations or handling matrices may have already been written. The programmer who needs a particular routine is saved the trouble of having to write one if it is available in the library. Library modules should be closed so that the variables used in them cannot disturb the code of the rest of the program. Meaningful variable names should be used. There should be internal commentary explaining what each section of the code does. Where a complex algorithm has been implemented it is helpful to comment on individual lines of the code, in addition to a general description of what the module does. Computing Studies Department Whitburn Academy Page 14

14 Where parameters are being used in a module, they should be described in the commentary of the module. This is particularly important in library modules. Parameter lists should be small and manageable. If a procedure or function requires a set of parameters that is very big, then it is likely that it is performing more than one program function. The original design needs to be revisited, and functionally decomposed i.e. further broken down into smaller modules. 3.2 Choosing a programming language In considering the development environment we will be trying to decide what is the most effective language in which to program, what environment does the program and the translator need to operate in, and what hardware is needed to support them....the art of choosing a language is to start with the problem, decide what the requirements are, and their relative importance, since it will probably be impossible to implement them all equally well (with a single language)... available languages should be measured against a list of requirements...guide to good Programming B Meek, Types of languages The nature of the problem that you are trying to solve will decide the programming language that you should use. Some languages are special purpose and suited to particular problem types, such as Primex (an expert system shell) or Prolog. Others are general purpose and can be used to solve many different types of problem, such as Comal, Pascal, Hypertalk, and Visual Basic etc. Recently, a group of rapid application development (RAD) languages has emerged: these include Delphi, Microsoft Visual C++ and JAVA. These languages are particularly suitable for use alongside the CASE tools mentioned on page 8. In addition to the above conventional programming languages are general-purpose applications packages (GPPs) such as Excel, Microsoft Works and Claris Works that, in addition to providing particular functionality, can be used to develop a range of problem solutions. The advantage in using these is that often solutions can be developed very quickly, and you needn t spend a lot of time learning the syntax or semantics of a conventional programming language. Recall the difficulties that you perhaps faced in learning Pascal, Comal, and Primex etc. for the first time. Compare this with the ease with which you learned how to use Claris Works or Excel or Claris Works. These applications packages nearly always have some programmability built in to them, and to use them effectively for software development requires some knowledge of their programming or scripting capabilities. However, they bring with them so many time-saving resources such as providing a preconstructed user interface, that the limitations in their programming capability can often be overlooked. 3.4 Deciding on a programming language In order to decide upon a suitable programming environment you need to be quite clear about the nature of the data objects, their types and the operations that need to be carried out on the data. If your problem requires an operation on a string data type then you need a language that supports strings. If you need to carry out arithmetic or logical operations, then you need a language that supports these. If your solutions needs to process sound or graphics, then you need an environment that can support these data types. Computing Studies Department Whitburn Academy Page 15

15 For instance, if you were given a problem to solve, which involved sending out a standard letter to a list of users held in a mailing list, then you would be dealing with the following objects and operations: OBJECT DATA TYPE OPERATION Standard letter text document create, edit Mailing list text/database document create, edit Mailshot text document mail merge, print This problem could be solved in a general-purpose package, which supported text processing, database creation and mail merging. It could also be solved using a conventional programming language such as Pascal. However, if you used Pascal you would need to write the code to perform the mail merge and to read all of the information from the text files. You would also need to provide a text-processing module, and design the user interface from scratch. As this capability is readily provided by most GPPs, it seems sensible to choose a GPP rather than a programming language. When faced with more than one possible development environment, as in the case above, you should consider the following criteria to help you choose: Consider the general application area (Multimedia, Information processing including databases, expert systems, Numerical analysis etc..) Consider the algorithmic or computational complexity of the problem. Does the language have the required features to support this? Consider the environment in which the software will run. Does it need particular operating system capability such as multitasking? What file handling capability will it need etc.? Consider the performance requirements of the solution. Speed? Response time? Consider the data types the language needs to support? Graphics? Sound? Video? Numeric? Textual? Consider the capabilities of the development team. What knowledge and experience do they have of the languages available? Questions 1. What is meant by a structured walkthrough using a structured listing? 2. What is the purpose of internal commentary? 3. State two examples of each of the following programming language types. a) Special purpose b) General purpose c) Rapid application development. 4. What is meant by CASE tools? Computing Studies Department Whitburn Academy Page 16

16 Extension/Revision Questions 5. You have to write a program that will produce the following output: Name John Smith Test A B C Scored Maximum Mark Percentage Identify the objects, data types and operations that would need to be dealt with. 6. An Arithmetic Tutor is to be developed for primary school children. The children are to be asked for simple arithmetic questions. Beside each question there will be boxes into which the children will enter their answers. A child should be able to go back to a box and change an answer as often as he or she wishes. Each time a child enters an answer, the Arithmetic Tutor should indicate whether the answer is correct or wrong. An example of Arithmetic Tutor what the screen might look like after a child has Type your answers in the boxes. entered answers Keep trying until all are correct. to the first three questions is = 9 Correct shown. 5 x 1 = 6 Wrong 4-2 = 3 Wrong = a) What operations would be required to decide whether to display Correct or Wrong when a child enters an answer? b) It is suggested either a spreadsheet package or a high level language could be used to develop the Arithmetic Tutor. State one advantage of developing the Arithmetic Tutor on a spreadsheet package and one advantage of using a high level language. c) i State two other facilities which a teacher may want the Tutor to provide. ii State whether you would use a spreadsheet or a high level language to develop the Tutor. Justify your decision with reference to the operations required to provide the facilities you identified in c) i). (1994 Higher, 9 marks) Computing Studies Department Whitburn Academy Page 17

17 4. TESTING In software engineering studies, a report suggests that analysis and design accounts for 40% of development costs, implementation 20% and testing around 40%. These proportions are illustrated on the pie-chart below. Software Development Costs It is therefore too late, and too costly, to discover that errors in the analytical or design phase have been made when you finally come to test the final code. By this stage 60% of the total project resources will have been used! To reinforce this point, let s consider civil engineering. If you are building, say, a bridge, it is not a good idea to wait until the final construction phase before realising that the bridge cannot support the expected load, or that the structure is so unstable that under adverse weather conditions it is likely to collapse! Engineers are constantly monitoring their design solutions using prototype models, blueprints and simulation programs. These tests are performed well in advance of construction. The same principles apply to the development of software. The longer you delay checking that your design solution meets the original requirements the more costly the design errors will be to remedy. Although design errors introduced in the analysis phase are more costly than programming errors (usually developed late in the software development cycle, easier to detect and costing less to remedy), they do occur. Boehm in the above report conducted an error analysis during the development of a complex software system. He concluded that many more errors were due to faults in the systems analysis than to mistakes in the programming. A similar situation was found following an analysis of development of the DOS/VS operating system. Half of all the errors encountered were due to misunderstanding the problem specification, and not in fact due to programming! The following is a brief classification of the most common design errors, and the project phase at which they more readily occur. It would be interesting for you to note at this stage how many of these errors you have encountered in your experiences of software design. (1) Errors during the detailed design stage. Incorrect interpretation of the program specification Incomplete logic Neglect of special cases Poor error handling Neglect of time consideration Computing Studies Department Whitburn Academy Page 18

18 (2) Errors during coding stage. Syntax errors Initialisation errors Confusion of parameters Errors in loop counters Incorrect handling of results of a decision Multiple or non-definition of variables Errors in writing variable names Incorrect declaration of type and dimensions (3) Errors during translation Compiler errors External symbols wrongly resolved Confusion of names of library procedures We should therefore build monitoring and review into every stage of the software development process, and not merely leave it to the end to find out that we have made mistakes. The fact that each stage of the process generates its own documentation, makes this review a lot simpler. This is yet another example of iteration in the software development process, because if the review of a stage in the process reveals flaws, then that stage will have to be revisited to correct the flaws. 4.1 Test data In earlier courses, you should have come across the idea of creating sets of test data to feed to your software to find out how it behaves under different conditions. Test data need to cover different cases (conditions.) Here are some of the important points about making up such sets: The expected results from a test data set must be known in advance, so that they can be checked against the actual results. One set should test normal operation of the software, to make sure that there are no unexpected results in ordinary work. One set should test the operation limits of the software, to make sure that the boundary conditions identified in the design stage are being handled properly. One set should test exceptions to the normal operating conditions. This set will show whether or not the software can react to unexpected inputs in an effective way, without crashing. This set of test data provides useful evidence about the robustness of the software. 4.2 Logic testing Testing can only convince us of the presence of errors, and not of their absence. At this stage of the software development process we are concerned with proving that the logic of the software is correct, and that it meets the requirements of the original specification. Testing can never prove conclusively that a program is correct. No matter how exhaustive the testing, it will always be possible for the system to contain errors that have not been detected. Computing Studies Department Whitburn Academy Page 19

19 How then can a system be verified to a level where the designers can make claim that it is reliable and robust? There are formal verification approaches such as mathematical proofs of correctness. It is beyond the scope of this course to go into any detail on these. If you have the time then you can pursue some of the ideas behind formal proofs of correctness in the Computer Programming unit. 4.3 Testing - who does it? Developing a piece of software is a creative task. Being a creative activity, the programmer will naturally take some pride in his/her creation, and will not necessarily wish to show that it doesn t in actual fact work properly! He or she may, subconsciously, only use test cases that demonstrate correct operation of the component, thus supporting their own worth as programmers, able to develop errorfree software in line with strict development deadlines. The programmer s approach of demonstrating through selective test cases that his/her software works, is unsatisfactory, and this approach to testing is unhelpful. Test cases should be destructive in their objective and aim to show the presence of errors The design team must handle systematically destroying a piece of software using this approach delicately and tactfully. Criticism can be difficult to handle for some people. On the one hand thorough testing must be carried out, and this must be destructive, aiming to identify faults so that they can be removed, improving the reliability of the system. On the other hand, in the face of test cases bringing the software to its knees, the programmer must still remain motivated and continue to work on the development. What is the best way of achieving this? One approach is to involve outsiders from other areas of the development team. In some development environments these are known as Independent Test Groups, (ITGs). These groups work with the programmer to ensure that thorough testing is carried out. Any errors uncovered are recorded and the software is returned to the programmer for correction. 4.4 Testing - when should it be done? Software systems can be very complex, consisting of large subsystems which themselves consist of modules consisting of procedures. Look back at the hierarchical diagram to appreciate this structure. A system designed by the author of this text to control the distribution of electricity for London Electricity Board, was implemented in over 250,000 lines of code. This was merely a component of a much larger system! It would be madness to delay the start of testing for software of this magnitude until the entire system has been coded. The hierarchical structure inherent in the design of a good system - the system at the highest level, sub-systems at the next level, modules at the next level and procedures at the lowest level - naturally suggests developing systematic testing strategies which exploit this structure. These have indeed been developed and take place in separate and identifiable stages. Computing Studies Department Whitburn Academy Page 20

20 4.5 Stages of Testing Procedure (component) testing At the lowest level in the system is the testing of individual procedures or functions. Using bottom-up implementation and testing techniques these procedures are first fully coded, then driver procedures are produced which will make a call to the procedure, providing it with the necessary parameters. The drivers have no other function but to call the procedure so as to test it using appropriate input. For example, consider a simple procedure, string_to_integer which will convert a series of ASCII characters passed in as a parameter into its integer equivalent, passed out as a parameter. A driver test_ascii_conversion would be developed which may possibly test the procedure as follows: Procedure Test_Ascii_Conversion Var converted_integer : integer; Begin string_to_integer( 1234,converted_integer); writeln(converted_integer); string_to_integer( ,converted_integer); writeln(converted_integer) end(* test_ascii_conversion *); Module testing (integration) Modules consist of integrated groups of procedures that communicate with each other. After each procedure has been tested it will be necessary to test how procedures in a module work together. Given that they each work well on their own - proven by testing described above - do any faults occur when they are integrated and forced to communicate and share information? This will require the development of driver procedures that will call the modules in the correct sequence, providing them with the necessary parameters. Take for example a group of modules which work cooperatively on the same input string provided from the user at the keyboard, such as in a process involving the verification of a password. Get Input Check Input Verify password Read keyboard input from user Check there are no control characters in keyboard input Is keyboard input equal to password? Having been tested and guaranteed to work individually, they will now be integrated, and called in sequence by a driver password whose code might look like this: Computing Studies Department Whitburn Academy Page 21

21 Procedure Password; (* This is a driver which has been specially coded in order to test the integration of the following group of 3 procedures *) Var User_input : string; Begin Get input(string); Check input(string); Verify Password(string); end(* password *) Sub-system testing As modules are designed to co-operate and communicate they are put together to form sub-systems and the module interfaces are tested. The testing strategy is the same as that for module testing. System testing The sub-systems are systematically put together to form the overall system. At this stage the software will have been fully integrated. Test cases are devised to test the complete system, and validated against the user requirements. Tests must ensure that the entire system meets the functional, behavioural and performance criteria detailed in the requirements document. Acceptance testing ( beta testing) Thus far testing has been carried out by the development team probably at the site of all software developments. A fully integrated system must be transported and set-up at the location in which it will be used. Here acceptance testing will be carried out in the presence of both the developers and users. The users should be permitted unrestricted access to the system, i.e. they should be allowed to supply arbitrary and unpredictable input values to verify the behaviour of the system. Beta test results are often used to make the final changes to an application just before publication. 4.6 Error detection and removal Discovering that there is an error in a piece of software is just the beginning of another stage, that of error detection and removal. The development environment determines the level of support that the programmer can expect to have during this stage. Such support should consist of: 1. Text editing capability, for the creation and editing of source code. Some editors are more sophisticated than others with macro text editing capability and screen editing. Others provide automatic formatting of source code such as using bold style text to highlight language keywords, providing automatic indentation of program blocks etc. Computing Studies Department Whitburn Academy Page 22

22 2. Interactive debugging systems for error tracing. These systems can permit the following: a) setting and deleting of break-points within the source b) checking and changing the value of a variable c) tracking of a variable value d) changing the program flow e) simulation of interrupts f) reporting statistics such as CPU time, running time etc. Both types of tools can speed up the rate of production of robust and reliable code. Questions 1. What percentage of the project resources will normally be used in testing? 2. What is the most likely source of errors in the software development process? 3. Give two examples of each of the following types of error: a) Errors during the detailed design stage b) Errors during the coding stage c) Errors during translation 4. What is meant by iteration in the context of the software development process? 5. A program has been written which will allow a teacher to enter a student s set of marks for four tests. It will calculate the average of these tests which are each out of 50. Construct four sets of test data and explain why you have chosen each set of values. 6. What is the purpose of Test cases 7. What is the difference between procedure testing and module testing? Computing Studies Department Whitburn Academy Page 23

23 Extension/Revision Questions 8. You have been asked to test a section of high level code which was written by another programmer. The purpose of the code is to search for a given integer in an ordered list. All the numbers in the list are integers in the range 0 to 100 inclusive. The list is in order and it is not empty. If the integer value is present in the list, the output will be the position of its first occurrence within the list. If it is not present, a suitable message will be output. a) State three sets of data that you would use to test the code. ( You should assume that the ordered list and the given integer are valid. ) b) For each set of test data, give reasons for your choice and state the expected output. (1993 Higher, 6 marks) 9. One method of amending a program is to use a line editor. To change a line of a program you have to move the cursor to the line that is to be changed and copy the whole line to an editing area. Characters are then inserted or deleted as necessary. Finally the corrected line is inserted back into the program. Another method of amending a program is to use a screen editor. This provides facilities similar to those in a word processor. a) State two word processing facilities which would be useful when editing a program. b) Give two advantages a screen editor would have over a line editor. (1993 Higher, 4 marks) 10. A friend offers you a Beta version of the latest Web Browser. Why should you be reluctant to delete your current browser and replace it with this version? 11. Look up in a dictionary of Computing terms robust and reliable. Write out the definitions in your own words, making sure the difference between them is clear. Computing Studies Department Whitburn Academy Page 24

24 5. DOCUMENTATION When a new piece of software appears in front of you, then the first place to look in order to gain an understanding of how it operates, what commands to use and how to solve any problems encountered will be in the documentation that usually accompanies it. Software companies vary in the nature and quality of documentation that they provide. However, two essential pieces of documentation that need to be developed are the User Guide and a Technical Guide. The quality of this documentation is also normally a good indicator of the quality of the software. Good documentation should be concise, comprehensive and above all complete. All of which can only arise from a well-structured systems analysis and design approach. For instance, any alterations to the system, through upgrades or corrective maintenance should also be reflected in the necessary document i.e. documentation should also be maintained up-to-date. The User Guide This document should describe how to use the software. Ideally there should also be tutorial files which can take the user through examples of a piece of work, and allow them to become familiar with the commands, and the various sections of the software. Nowadays it is becoming more common for developers to provide this documentation in electronic form, as an on-line reference system, with interactive help and tutorial displays. This saves in the cost of producing paper-based documents, and also allows upgrades to be reflected in the help system upon subsequent releases of new software versions. The Technical Guide This document should provide information on how to install the software, its memory and processor requirements, the version number of the software and any associated help files or systems extensions that may also need to be installed. The guide should also contain a reference section on troubleshooting that will help the user to get around any system problems that they may encounter. Have a look at some of this documentation that may be available for some of the packages that you have been using in your courses. Make a list of the separate documentation components that you find there, then explore the interactive documentation of the package. There is a documentation checklist to help you through this task at the end of the notes for Outcome 1. Computing Studies Department Whitburn Academy Page 25

25 6. EVALUATION To evaluate a completed application, the developers are mainly concerned with answering the question: Does this software meet the user requirements? To answer this, you need to return to the original aims of the software development, and judge this against a set of criteria. What are the criteria that you should use? We have already introduced to you many different sets of them, depending upon the stage that you are at in the software development process. For instance, if you are at the analysis stage, then you are measuring how well you have understood the client s problem. Some say that the proof of this lies in the final development. However, as we have pointed out, this is far too late a stage at which to judge success. By interacting with the client, taking notes of all meetings, agreeing on what has been said - in other words, using the recommended tools and techniques of analysis you will have increased the likely success of this stage. You will also have generated a list of user requirements that can be used as a checklist to help you validate your product as you proceed through the design, implementation and testing stages. At the design stage, there are criteria that have been introduced in order to help you to measure the quality of the HCI. This, together with a structured and methodical approach to developing screen layouts, structured charts and algorithms, can all be used to measure the success of your design. They also help to validate that you are building the correct product. Guidelines given on how to select a programming language, and the attributes that good source code should contain, can all be used as criteria in evaluating the modularity and portability of the software. It is structure, readability, and the test, used to validate it, that will provide a measure of its reliability, maintainability, and finally its robustness. Questions 1. What is the purpose of the User Guide? 2. What is meant by an on-line help? 3. Why do you think most developers provide the documentation in electronic form? 4. What is the purpose of the Technical Guide? 5. What are criteria? Computing Studies Department Whitburn Academy Page 26

26 Extension/Revision Questions 6. A company employs a software house to write a program for it. Before the program is written, an agreed specification is produced from the company s problem description. a) State a difference between a specification and a problem description. b) After the program has been written, how would the specification be used by: 1) The company? 2) The software house? (1995 Higher, 4 marks) Computing Studies Department Whitburn Academy Page 27

27 7. MAINTENANCE Maintenance comes into effect as soon as the system is delivered to the client and it enters productive use..it is impossible to produce systems of any size which do not need to be maintained. Over the lifetime of a system, its original requirements will be modified to reflect changing needs, the system s environment will change, and obscure errors, undiscovered during system validation, will emerge. Sommerville, Systems Analysis and Design, Maintenance activities Research has identified the following three maintenance activities, and the associated percentage of time spent on each. These figures are typical of a development company s maintenance procedures: 1. Corrective maintenance (17%) During the use of the system, errors emerge which were undetected during system testing. These should be reported to the developer and corrective action taken to remove them from the original code. 2. Adaptive maintenance (18%) The software environment of the system, such as the operating system or the hardware environment of the system, such as peripheral devices, processor etc., have altered since the code was originally developed and these have caused the original code either to fail, or to operate less effectively. The system must be altered in order to adapt to these new surroundings 3, Perfective maintenance (65%) This is a response to a user s request to change the existing system by adding new or altering existing functions, or catering for general enhancements to the system. Not all software designers are satisfied with categories 2 and 3 as maintenance procedures. Some feel that enhancements which result in new design structures, new code and new testing strategies should not be regarded as maintenance but as new projects, and as such should be financed outwith the maintenance contract, perhaps as part of a design enhancement procedure. Categories 2 and 3 are also likely to force the developers to revisit the early stages in the design process - another iteration of the design. This particular iteration is likely to take place after some years of use of the software. It may be that the original developers are no longer available to take part in this phase. It is only likely to be effective if the original design documentation is of high quality, so that it can be followed and amended easily. Computing Studies Department Whitburn Academy Page 28