Software Development Cycle. Learning Objectives

1. Software Development Cycle. • Learning Objectives • Learn about the main stages of software development • Look in detail at the components of each stage: Analysis, Design, Implementation, Testing and Evaluation.

2. Software development Life Cycle Analysis Problem Design Evaluation Implementation Testing

3. Software Development Life Cycle. • Analysis • Defining the problem • What is the scope of the problem • Why is there a problem • Can’t cope with increasing volume of data • New technologies making older systems outdated • Current system inflexible or inefficient • New technologies creating new opportunities • Commercial reasons - to generate more revenue or to meet changes in customer demands • New platforms and operating systems. • Increased processing power – more opportunities. • Increased network power – more opportunities.

4. Software Development Life Cycle. • Analysis • Methods of gathering information on current system or requirements • Interviewing people • Questionnaires • Observations • Examination of paper work and current data.

5. Software Development Life Cycle. • Analysis • The Interview • Before you start an interview make sure you have in your mind exactly what you are going to try and find out. For example. • Objectives: what is the proposed system to do? • What are the problems with the current ways of doing things. • Data information • What data or information is recorded in the current system? • How much data is recorded at present? • What data or information is to be recorded in the proposed system? • How much data will the proposed system record? • How frequently will the data need to be updated? • Will new records need to be added or old ones deleted and how often? • Will changed in data come in batches or smaller quantities? • How important is the data or information that is recorded? • Any legal issues that need to be considered with certain types of data?

6. Software Development Life Cycle. • Analysis • The Interview • Functions or processes • What functions and process are performed by the current system? • What functions and processes will need to be performed by the new system? • When should then be done and where? • What special algorithms do these processes use? • Which processes if any should be executed manually? • What are the inputs to the current system and what inputs would be required for the proposed new system? • Outputs • What are the outputs from the current system? • What outputs will be required from the new system? • Is hardcopy output required? • How often will the outputs be required? • Have a look and if possible take a copy of the current outputs from the old system.

7. Software Development Life Cycle. • Analysis • The Interview • 7) Existing hardware and software: what computing resources does the end user possess? • 8) Funding: is the end user prepared to purchase the software or hardware resources? • 9) Security: is security an issue? Should there be limited access to some or all parts of the system? • 10) Exceptions • How are exceptions and errors handled in the current system? • What errors and exceptions should be reported in the proposed system? • How should they be reported? • Should anything else be done? • 11) Constraints: are the any constraints on hardware, software, data, methods of working, cost, time and so on? • 12) Suggested solutions: does the user have a particular solution in mind? Do you have some suggestions to make to the user?

8. Software Development Life Cycle. • Analysis • Feasibility study • Identify possible solutions • Suggestions of best way forward • Pros and cons of possible solutions • (T)echnical feasibility – Is it technically possible? • (E)conomical feasibility – can the problem be solved within the budget? • (L)egal feasibility – is what is proposed legal? • (O)perational feasibility – will the new system improve the situation? • (S)chedule feasibility – can the new system be delivered within the timescale?

9. Software Development Life Cycle. • Analysis • The task • Look at the first part of the problem on specification journal 16. Work on section 1.1 Analysis.

10. Software Development Life Cycle. • Design • Need to consider: • Choice of hardware • Choice of software • Making the problem modular – Top Down Design. • Designing how data moves around the system - DFD

11. Systems development Life Cycle Design High level and Modular design. Here is an example of Modular design using a Jackson (Hierarchical) diagram. Enrolment System Tier 1 Student Database Course Database Financial system

12. Systems development Life Cycle Design High level and Modular design. Here is an example of Modular design using a Jackson (Hierarchical) diagram. Student Database Tier 2 Database Processing Database Maintenance Database Audit Basically you have to complete the lower level tasks before the one above can be seen as complete. Add Student Edit Student Delete Student

13. Systems development Life Cycle Design High level and Modular design. You can also use flowchart symbols to create a high level design. Process – this could be a program or a manual process Input / Output – this could be a data keyed in at a keyboard. A bar code with a bar code reader, an error report on a printer, a graph shown on a monitor Online Storage – This could be a database on magnetic disk, a data file on CD-RW Flow line – Links the symbols to define sequence and direction of flow Device Device

14. Systems development Life Cycle Design High level and Modular design. Example of a flow chart Transactions Keyboard Monthly Statements Printer Produce monthly statements Customer File Magnetic Disk Error log file Magnetic tape

15. Systems development Life Cycle Design Building Models – Data Flow Diagrams Data source or destination – might be a person who places an order for goods. A destination might be a person who receives an invoice. A short diagonal line is added to the top left corner to indicate that this entity appears more than once on a given DFD Process – an operation or transformation performed on the data. The line is optional; the bottom section of the box can be used to label the process. Data Store – such as a file held on a disk or a batch of forms Data Flow – the arrow represents a movement of data in the following cases: a source to a process, a process to a destination, a process to a data store, a data store to a process, a process to a process. The arrow should be labelled to describe what data is involved.

16. Customer File ValidateMeter No. Calculate Bill Meter reading Meter No. Meter Read Meter No. Meter Read Meter Read Last Meter Read Name, Address, Total Bill Meter No., Last Meter Read Name, Address, Total Bill Bill Meter Read, Total Bill

17. Systems development Life Cycle Design Building Models – Data Flow Diagrams Draw two DFDs of the following two systems: At the end of each week, time sheets are collected and sent to the computer centre. There, the payroll data is entered via a key to disk system, verified and validated, producing a new file of valid transactions on disk and an error report. This file is used to update the employee master file, payslips are printed and funds are electronically transferred to employees’ bank accounts. A student can register by mail for a college course by submitting a registration form with their name, ID number and the numbers of the courses they wish to take. The system verifies that the course is not full and enrols the student on each course for which a place is still free. The course file and student master files are updated and a confirmation letter is sent to the student to notify them of their acceptance or rejection for each requested course.

18. Send letter Enrol student(if not full) Student Master file Systems development Life Cycle Design Building Models – Data Flow Diagrams Suggested solution to the second problem. Course No., Max Students, No. Students Enrolled Registration Form Name, IDNo., Course No. Verify availability Student Course file Course No. No. Students Enrolled Course No. IDNo., Name, Address, Course No., Accept/Reject IDNo., Name, Address,Course No., Accept/Reject IDNo., Name, Address,Course No., Accept/Reject

19. Systems development Life Cycle • Design • Algorithm design • The processes identified for system functionality needs to be design effectively. For example if a search function is required, which standard algorithm would be appropriate, sequential or binary. What other processes need careful design therefore written as algorithms? • Possible Syntax for algorithm design • INPUT NUM1 • OUTPUT NUM1 • IF NUM1 > 15 then • … • END IF • REPEAT • … • UNTIL NUM1 > 100

20. Systems development Life Cycle • Design • Data Dictionary • Where revelant a data dictionary should be produced to show what data will be used and how it will be stored. Usually becomes the main variables in a program or the fields in a database table. Should include information such as • Name • Data type • Properties – length etc. • Any validation • Maybe some example of this form of data

21. Systems development Life Cycle Design User interface design All good systems have a intuitive user interface. Here are some things to consider: The type of user, such as expert, novice, frequent, occasional, young child, technical. User needs and accessibility issues such as sight impairment, limited hand mobility Choice of appropriate input/output devices, including size of screen Use of colour, perhaps to alert or to present a house style Use of icons, symbols or text Type of interface, such as command line or graphical Type of menu, such as drop down, full screen or pop-up

22. Systems development Life Cycle Design User interface design Good user interface design provides: Feedback to the user, such as when a record has been saved successfully Confirmation, perhaps before deleting a record Clearly marked exists, such as going back to a previous screen or the main menu. Online help, such as using the F1 key, menu options, callouts on rollover Helpful error messages at a level appropriate for the prospective user. Optional keyboard shortcuts.

23. Software Development Life Cycle. • Design • The task • Look at part 1.2 of Specification Journal 16 and complete what it is asking you to do.

24. Systems development Life Cycle • Implementation • Creating a solution can be costly – Client may make changes to requirements along the way. • Good idea to produce prototypes along the way. • Client may then review the prototypes as you develop them.

25. Software Development Life Cycle. • Implementation • The task • Look at part 1.3 of Specification Journal 16 and complete what it is asking you to do.

26. Systems development Life Cycle • Testing • Designing a good test plan will show that the system is working. • During and after the implementation of the solution, the code will need to be extensively tested. This is often done by a team of testers using a range of strategies, including: • Top Down testing • Bottom Up testing • Black Box testing • White Box testing • Integration testing • Alpha testing • Beta testing

27. Systems development Life Cycle Testing Top Down Testing At this stage, the entire solution will not be complete, but parts of the system will be ready for testing. The skeleton of the complete system is tested, with individual modules being replaced by ‘stubs’ which display a message to indicate that the procedure will execute if it were written. As modules are written they are included in the test. This testing looks at the navigation (menu structures) and user interface.

28. Systems development Life Cycle Testing Bottom Up Testing Also known as unit testing. At this stage, the entire solution will not be complete, but parts of the system will be ready for testing. Each module of code is tested independently from the others before being integrated into the complete solution.

29. Systems development Life Cycle • Testing • Black Box Testing • A set of test data and test conditions is prepared by the test team. Each aspect of a module is tested thoroughly against the specification. • Data is entered into a routine and the output is checked against the expected output. The range of checks will include: • Expected valid data (Normal) • Extreme valid data • Edge of validity data (Boundary) • Invalid data (Erroneous) • No data

30. Systems development Life Cycle Testing White Box Testing The program structure is studied and each possible path or branch is tested at least once. Menus, conditions and iterations in code all create program branches. White box testing also covers unexpected events such as an unusual sequence of inputs or not finding a printer, disk etc.

31. Systems development Life Cycle Testing Integration Testing Once all the individual modules are bottom up tested, they are again tested to ensure they all work together. Alpha Testing Also known as acceptance testing. The system is tested with the developer and the project manager to check it covers all the aspects of the specification and meets its objectives. Beta Testing The software is given to a number of potential users who agree to trial the system and report and problems they find to the developers.

32. Systems development Life Cycle Testing When designing you test strategy you need to talk about how you are going to test your system. You can use some of the theory mentioned before then create a outline test plan. For example:

33. Systems development Life Cycle Testing Creating a test plan. An example of a test plan

34. Software Development Life Cycle. • Testing • The task • Look at part 1.4 of Specification Journal 16 and complete what it is asking you to do.

35. Systems development Life Cycle • Evaluation • Final stage of development • Does the system match the requirements. • Evaluation compares the outcome with the specification. • Some criteria to evaluate the system: • Functionality – does it do what it is suppose to do. • Ease of use – is the system intuitive • Ease of implementation – how easy was the transfer from the old system to the new • Reliability – A measure of how much the new system is up or down • Performance – Does the system meet its performance criteria. • Cost effectiveness • Ease of maintenance and adaptability. • Longevity – how future proof is the system?

36. Software Development Life Cycle. • Evaluation • The task • Look at part 1.5 of Specification Journal 16 and complete what it is asking you to do.