Download
1 / 38
380 likes | 430 Vues
Introduction. The development of a piece of software from scratch is a process that takes considerable time. We can classify these stages thus :. 1. Analysing the problem: Can we do it?. 2. Designing the program: How do we do it?. 3. Implementing the design: Writing the program.
E N D
Introduction • The development of a piece of software from scratch is a process that takes considerable time. We can classify these stages thus : 1. Analysing the problem: Can we do it? 2. Designing the program: How do we do it? 3. Implementing the design: Writing the program 4. Testing the design: Making sure it works 5. Documenting the design: User guides, Technical manuals 6. Evaluating the design: Limitations and improvements 7. Maintaining the software: Correcting, adapting and perfecting
Iterative • The cycle is iterative. Iteration means to follow through a process more than once before concluding it. An iterative process is one that incorporates feedback and involves an element of repetition. • The implementation stage can be iterative because testing may show that the program doesn’t run properly, so the programmer will have to revisit the design and implementation stages.
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 takes sole responsible for the whole project and must supervise all steps and stages required. S/he will liaise with the systems analyst and keep the whole project on track. S/he will also ensure that programmers meet deadlines and have the resources they need, will deliver any reports on time and be kept fully aware of test results.
Personnel • The Systems Analyst works for a software house and agrees with the client the exact nature and specification of the software to be written. • The programmer is responsible, either individually or as part of a team, for turning the design into programming code. • The Independent Test Group (ITG) carries out the testing of the software. They will test each individual part of the program, larger sections of the program and finally the finished product.
Analysis 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 Report
Analysis • Analysis is the most important part of the process. Changes can be identified early on thus reducing the amount of extra work and cost involved in trying to make changes later. • Analysis is a fact finding process aimed at answering the following questions : • WHO? • WHEN? • WHAT? • WHY? • WHERE?
Analysis • Analysis starts with discussions between the client and a systems analyst. The analyst will carry out three main tasks. • observe the system currently in use. • clarify the system currently in use. • model the system currently in use.
Analysis • The particular skills that an analyst needs to have would be: • to be able to extract the needs of the client who may not be technically skilled. • to be able to document these needs in some formal way. • to be able to communicate these needs to the people who will actually design the computerised system.
Analysis - Extracting Needs • This can be called requirements elicitation and can take some time. Difficulties may arise due to either the client’s lack of awareness of the capabilities of the computerised system or the analyst’s lack of knowledge of the client’s business operations. • The analyst will proceed through: • a series of interviews with the client’s management team, • make observation notes of what actually happens in the workplace, • use questionnaires and literature, e.g. manuals, to determine how the existing system operates.
Analysis - Documentation • These discussions will lead to a legally binding requirementsspecification. This is a detailed document which indicates what the client wants the design team to do and will include a system specification.
Design 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)
Design • Design involves planning the solution to the problem. This would not take place until the specification document had been agreed between the client and the programmer. As with analysis, it is crucial to detect errors at this stage rather than later. • Design can be broken down into : 1. Design of the structure 2. Design of the detailed logic
Design Methodology - Modular • A large computer program can be organised into smaller parts called modules, which can be developed at the same time by different programmers and programming teams. • Modules can be designed, programmed and maintained independently of one another. • Ideally each module should: • be small • be self contained so it can be saved and used in other programs. • do one task only
Design Methodology - Modular • There are several design techniques. The one we use is called Top Down Design. In this method, the problem is broken down into smaller sub problems that are then divided in turn into even smaller ones. • This continues until the sub problems are manageable enough to be coded - step wise refinement.
Design Notations • The design stage results in a detailed algorithm - a sequence of operations needed to solve the problem. There are several designnotations, or methods of representing an algorithm, including: • pseudocode text is in English but easily converted into language code. Its advantage is it will be close to the final coded program. • structure chart a diagram showing the component sub problems and how they are linked. It can show the structure of the whole program in a small space.
Design - Pseudocode 1. Display information 2. Get details 3. Do calculation 4. Display answer Refine step 2 2.1 display prompt 2.2 get value 2.3 while value out of range 2.4 display error message 2.5 get value 2.6 loop Top level design Notice the numbering system
Design - Structure Chart In/out In Data Flow
Implementation Key Task: To write code in a chosen programming language. Personnel: Programmer and Project manager Documentation: A structured listing of the programming code showing formatting features such as commands in bold, indentation, etc.
Implementation - Language Choice • For most problems, however, a suitable high level language may be required. Some high level languages have special applications and are suited to certain problem types - for example, Prolog for Artificial Intelligence. • Others are more general and can be used to solve a wide range of problems - for example, Comal can be used to solve a wide range of programming tasks.
Structured Listing • A structured listing is a program printed on paper that uses indentation (formatting) to show the structure of the program. • A structured listing can also highlight keywords and variable names in a different text colour. • Advantages • Easy to understand the structure of the whole program. • Mistakes are easier to spot.
Structured Listing • A structured listing should be readable. Readable : Easily understood by others e.g. use of meaningful variables, constants, procedure and function names, Suitable internal comments. Good layout with spaces between sections. Description of parameters. Parameter lists are kept short.
Testing Key Task: To test that the program meets the specification. Personnel: Independent Test Group (ITG) Documentation: Set of test data and test reports. The test data will have predicted (before running) and actual (after running) output.
Testing • Many organisations now employ Independent Test Groups who return the program to the programmers for correction after testing. • The program is now tested using many sets of test data to check that it gives the correct output under all possible conditions. It is important that the expected results from the test should be known before the test is carried out so that the actual results can be checked.
Testing - Test Data • Testing is usually done with three types of test data: 1. Normal data - typical data that would be expected. 2. Extreme data - the data is at the extreme limits allowed. e.g. if an age is to be between 0 and 120 then these two values are tested. 3. Exceptional data - the data is not suitable for the program e.g. (i) values outside agreed ranges (ii) letters instead of numbers.
Testing - Stages of Testing • Testing is itself a structured process starting with individual lines of code and building up to a test of the entire system. 1. Structured Walkthrough - Each line of logic in the code is stepped through using a printed listing. 2. Component or procedural testing - A procedure can be tested by creating another procedure called a driver procedure to provide the necessary data. Once the test has proved satisfactory, the driver procedure is deleted.
Testing - Stages of Testing 3. Module testing - This involves testing a number of already tested individual procedures to make sure that they link together correctly as a module. Again a driver procedure is used to call the module procedures in the correct sequence. 4. Sub System testing - In the same way, groups of modules which are designed to communicate are tested. 5. System testing - Finally, the overall system made up of tested sub systems is tested.
Testing - Stages of Testing 6. Beta testing - The system may now be trialled with a number of selected users in the real world. A so called ‘beta version’ is issued to users who test it under working conditions and report any faults to the design team. These results are often used to make final changes just before publication.
Testing - Error Detection & Removal • There are basically two types of errors: 1. Syntax errors - errors in the code e.g. missing ; where the rules of the language are broken. 2. Run time errors - errors that only occur when the program is executed such as incorrect variable names or division by zero.
Documentation Key Task: To produce documentation to be distributed with the software. Personnel: Client, Systems Analyst and programmer Documentation: User Guide and Technical Guide
Documentation • All software comes with two essential pieces of documentation. 1. The TechnicalGuide • How to install the software, its memory and processor requirements, version number, help files of systems extensions needed. • Reference section on trouble-shooting system problems.
Documentation 2. The UserGuide • A beginners (‘getting started’) guide often in the form of a tutorial in which the USER goes through a number of worked examples. • A User manual explaining how to use the package. Frequently, these may be provided in electronic form with an interactive help and tutorial system. The user will have the option to print these if needed.
Evaluation Key Task: To report upon the quality of the software according to given criteria. Personnel: Systems Analyst and Project manager Documentation: A Project report accompanying the software to the client. It compares the software to the original specification and comments on the quality of the software.
Evaluation • The finished working program is now compared with the original specification. This involves judging the software against a set of criteria such as : • a list of the original user requirements • the quality of the HCI • choice of suitable language • attributes of good programming style • quality of testing • choice of language
Maintenance Key Task: To make changes to the software after it has been handed over to the client. Personnel: Varies but programmer and client will certainly be involved Documentation: A Maintenance report will detail and confirm the maintenance carried out.
Maintenance • A company will have three maintenance activities; 1. Corrective • Emergence of undetected errors. • Need to be reported and corrected 2. Adaptive • Code overtaken by developments in operating systems, CPUs, peripherals leading to code failure or less effective operation. • System needs to be adapted to new conditions
Maintenance 3. Perfective (65% of the time) • Users request changes such as adding new or altering existing functions or general improvements.
Desirable Characteristics Of Software 1. Robust : Input should appear as typed (echoed). Input should be validated and the user asked for re-entry. Should not crash on invalid input. All possible errors trapped e.g. division by 0. 2. Reliable : Free from error. Works for all allowed inputs. 3. Portable : Can be easily adapted for use on other machines by avoiding the use of machine specific commands. 4. Efficient : make good use of time and memory.
Desirable Characteristics Of Software 5. Maintainable : Easy to change, upgrade and adapt. Needs to be modular i.e. use of procedures, functions and local variables are important, along with short main programs. Use should be made of pre-written Library modules to avoid unnecessary writing of code.
