1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance

2 Systems Analysis What is a systems analyst?  A systems analyst observes, clarifies and models an existing system to assess its suitability for computerisation.  They may once have been programmers.

3 Skills and techniques of the Systems Analyst The systems analyst must  extract the clients needs  document these needs in a formal way  communicate these to the designers

4 Extracting the Clients Needs Extracting the clients needs is known as requirements elicitation. This is done by:  interviewing the client.  make observation of the client’s business  Inspect information sources used by the client to keep track of their business.

5 The Requirements Specification ► is the end result of the requirements elicitation ► is a written statement of what the design team must go on to make It is extremely important to get this document right. Mistakes made later can be very costly.

6 Documentation The systems analyst must document the clients needs by drafting formal reports:  requirements specification  system specification

7 Design Representations Examples include:  structure diagrams  pseudocode

8 Structure Diagram A commonly used syntax for structure diagrams is as follows: A procedure A loop A decision A single task

9 An example: A structure diagram :

10 Pseudocode Pseudocode is another example of a method of describing a program. Simple English words are used to describe the steps of the algorithm and any refinements made. Simple English words are used to describe the steps of the algorithm and any refinements made.

11 Pseudocode - Example 1.Display information 2.Get details 3.Do calculation 4.Display answer Refine step 2 2.1display prompt 2.2get value 2.3while value out of range 2.4display error message 2.5get value 2.6loop Top level design Notice the numbering system

12 An Iterative process It is important to realise that the software development process is iterative in nature. This means that the problem will be revisited a number of times getting closer and closer to the required solution on each time round.

13 CASE Tools CASE stands for “Computer Aided Software Engineering”. A CASE TOOL KIT is a set tools that have been designed to automate the entire software life cycle, including analysis, design, coding and testing.

14 Fact Finding 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?

15 Designing the Solution Once the needs of the user are clearly understood and documented  Design of the User Interface  Design of the structure of the software ► Design of the detailed logic of the software

16 Implementation The next stage involves turning the carefully structured design into a working solution.

17 Choosing an Environment Before we can implement a solution we must decide on the programming environment which is most suitable. Languages are generally designed for a specific purpose.

18 Programming Languages

19 Things to Remember...  The code should be modular,  Meaningful variable names should be used.  There should be internal commentary, explaining what each section of the code does.

20 Debugging the Solution A common technique in trying to debug 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.

21 Dry Runs To complete a dry run the programmer works through a section of program code by hand. This is very useful for locating errors in both syntax and semantics. A trace table will normally be used in this activity.

22 Trace Tables A trace table is constructed with a column to identify the instruction executed and a column for each variable. The programmer works through each line of the listing changing the appropriate variables.

23 Test Data 1.Normal operation of the software, to make sure that there are no unexpected results in ordinary work. 2. Boundary - the operational limits of the software 3.Exceptions - This set will show whether or not the software can react to unexpected inputs in an effective way, without crashing.

24 Documentation - The User Guide ► This document should describe how to use the software. ► There should be a tutorial which allows the user to become familiar with the commands, and the various sections of the software.

25 Documentation - The Technical Guide This document should provide information on ► how to install the software ► hardware requirements (memory, processor speed) ► software requirements (Operating system version)

26 Evaluation ► Does the solution meet the user requirements?  Judge this against a set of criteria ► fitness for purpose ► maintainability ► robustness ► reliability ► portability

27 Some Definitions ► Correctness  A program is correct if it matches the users requirements ► Maintainability  This will include ► internal commentary ► meaningful variable and procedure names ► parameter passing

28 Some Definitions (2)  Reliability - A program is reliable if it is free from bugs,  Readability - A program is readable if it is easily understandable by people other than the original programmer, ie good internal documentation, use of white space, etc.

29 Some Definitions (3) ► Portability  A program is said to be portable if it can be transferred from one system to another with minimal adaptation ► Efficiency  It should not use up more system resources (memory & processor time) than are necessary.

30 Some Definitions (4) ► Robustness  A program is said to be robust if it does not crash when invalid data is input or unexpected results are generated. ► Fitness for Purpose  Does the program meet the requirements?

31 Maintenance ► Activities identified as part of maintenance:  corrective (17%)  adaptive (18%)  Perfective (65%)