Transcript Document
The Software Development Cycle Bill Biddle 2002 Introduction The the traditional approach used by software developers to create new applications follows the “Software Development Cycle” It consists of 5 end-on stages including; Defining and Understanding the problem Planning and Designing of software solutions Implementation of software solutions Testing and Evaluation of software solutions Maintenance of software solutions The Cycle is used as part of the “Structured Approach” to software development It can be represented using the “Waterfall Model” Bill Biddle 2002 Waterfall Model The Software Development Cycle “Waterfall Model” Defining and Understanding the Problem Planning and Designing Software Solutions Implementation of Software Solutions Testing and Evaluation of Software Solutions Time Maintenance of Software Solutions Bill Biddle 2002 Stage 1 Defining and Understanding the problem At the end of this stage the developer should have a document that spells out the requirements of the piece of software in terms of the data inputs and outputs required and the processes required To achieve this the developer needs to; collect information from the client (ie the user’s needs) and validate these needs determine the scope of the problems to be solved and define its boundaries clearly examine feasibility issues consider Social and Ethical requirements Systems analysts typically carry out the tasks involved with this stage Bill Biddle 2002 Steps Involved in Defining and Understanding The Software developer will carry out the following steps in order to complete this stage 1. 2. 3. 4. 5. 6. 7. 8. Collect information from the users to determine the needs of the users/client Determine the objectives Identify the scope, boundaries and constraints Determine the feasibility of different approaches Develop a design specification, documenting data elements and data types Represent the system using appropriate system diagrams or build a throwaway prototype to model the system to the client and validate the requirements Generate a requirements report Provide feedback to the client Bill Biddle 2002 Determining the Needs Clients/users need to be surveyed to collect information for the requirements report. The developer will need to know; The hardware specifications, on which the software is to run The data inputs and outputs data types and structures needed the volume of data which needs to be processed and stored sources of data data security requirements sequence of data on screen designs Processing needs Ergonomic and Social & Ethical needs Testing needs Training needs User Documentation needs Maintenance needs Bill Biddle 2002 Objectives and Scope The developer must set clear objectives which clarify what is trying to be achieved The objectives are usually expressed in terms of what the user will be able to do eg 1. 2. “users will be provided with an easy to use interface” “context sensitive help will be available to users at all times” The Scope of the project has to do with identifying and defining its limits or boundaries. These limits or boundaries may be; functional or technical based around time and cost based around the level of support given through documentation and training Bill Biddle 2002 Feasibility Before commencing any project it is essential that a feasibility study is carried out to answer the questions; “Is the problem worth solving?” and “Which approach provides the optimal way of solving the problem?” This study should look at all constraints placed on the system including; Time Constraints (Scheduling) Budgetary Constraints (Cost) Operational Constraints (Functionality / Usability) Technical Constraints (Hardware limits) Organizational Constraints (Administrative limits) Social and Ethical Considerations Bill Biddle 2002 Design Specifications During this task the Developer (analyst) should detail the design requirements for; The Data including; The User Interface identifying; names for data elements (identifiers) data types for different data elements data structures for storing data elements the screen elements required the screen principles to be applied The System identifying; minimum hardware specifications operating system requirements Bill Biddle 2002 System Modelling Software developers use system modelling to try display their understand of the problem and to communicate this understanding to their clients System Modelling is achieved through the use of; IPO diagrams Storyboards Dataflow diagrams System Flowcharts Screen designs, and Limited prototypes These models may be used and further developed in Stage 2 as part of the planning Bill Biddle 2002 IPO Diagrams Input Process Output diagrams help developers identify all the Inputs,Processes and Outputs required by a system. The simplest to represent these is with an IPO Chart (Table) eg Problem: An application is required that will display a persons age given their name, birth date and current date Input Name Current_Date Birth_Date Process CalculateAge Output Age Bill Biddle 2002 Storyboards A storyboard is a visual representation of the material to be delivered in the solution in a narrative format, including screen designs, audio script, data elements, user interactions and navigation. A storyboard sets out the contents of the materials to be developed and describes the format in which it will appear in the finished product. A storyboard should contain: the name of each screen the names of data elements that are manipulated on the screen a description of the interaction which will take place on each screen a description of the graphics specified for each screen Storyboards allow the developer test their ideas with potential users, to help them test assumptions and clarify requirements. Bill Biddle 2002 Dataflow Diagrams (DFD) Dataflow diagrams are used to represent the flow of data through a system They are mainly used to represent transaction processing system Dataflow diagrams allow developers to identify; External Entities (Sources of Data) Data Names Processes File Stores DFDs can represent systems at a number of different levels Level “0” diagrams are called context diagrams Bill Biddle 2002 Dataflow Diagrams (diagram) Representing “the Registration of a New Borrower” Borrower_Name Borrower Reject_Message Full_Details Borrower_ID Check if Borrower_Details exist Valid_Flag + Borrower_Name Generate Borrower_ID Borrower_Details Next_Record_ID Borrower File New_Borrower_Details Bill Biddle 2002 System Flowcharts System Flowcharts are a valuable tool because they represent; Processes and Process sequences Hardware Tasks – Screen Display – Keyboard Entry - Storage Details - etc User procedures Documents Decisions System Flowcharts are probably easier for clients to understand than DFDs and are a useful tool used to help verify the systems requirements Bill Biddle 2002 System Flowcharts (diagram) Begin Licence Applicant Form Primary Proof of Identity (licence, passport, Identity Card) OR Seconday Proof Has applicant completed form Correctly? YES Group 1 Document Process Group 2 Document NO RTA Licencing System. System Flowchart. Verif y Identity of Applicant and complete "Proof of Identity f orm" Licence Applicant Form (Office Use Section) Reference Section Licence Applicant Form OR Witness Section of Applicant Form Completed Verif y Address or ensure that Witness section of the f orm is complete OR Proof of Address Document Licence Applicant Form (Office Use Section) Bill Biddle 2002 Screen Designs Screen Designs are probably the most valuable tool used to verify the requirements of the application with the users/ clients Screen designs should; contain Headings and Labels contain Prompts, Messages and Help to the user contain Navigation elements including menus contain Data Input/Output elements follow good design principles not contain unnecessary elements Elements included on screen designs should be labelled clearly Bill Biddle 2002 Limited Prototype A limited (or throwaway) prototype may be little more than a model which allows users to do a live walk through of the solution. Characteristically these prototype will have well developed screen designs for the whole system limited real functionality limited error checking These prototypes are used essentially to validate the requirements with the clients/users. Several prototypes may be developed before the full scope and nature of the problem is understood Bill Biddle 2002 Social and Ethical Considerations Social and Ethical requirements of an application should be considered early to minimise problems later The sort of questions the developer should ask include things like; How do I make the application user friendly? What steps need to be taken to ensure private data is kept private? How is a user’s access to data to be controlled? How is the integrity of data in the system to be maintained? How is the application going to be maintained to ensure its usefulness in the future? How is the software going to be licensed and protected from unauthorised use? Bill Biddle 2002 Documentation At the end of this stage a variety of documents are produced for different individuals and groups including; 1. 2. 3. The Client Feasibility Report Questionnaires and Survey Reports Refined requirements used to form the basis of a contract Administrators Risk Analysis Report Feasibility Reports with costings Project Details Project Development Team Project Schedule detailing the timeframe and approach Requirements definition report including feedback from client System Documentation Software Requirements Report Bill Biddle 2002 Stage 2 Planning and designing Software Solutions Developers take the information presented in Stage 1 of the Software Development Cycle and use it to design a solution. Designing a Solution involves; Documenting the names and data types of all the data elements used in the form of a Data Dictionary Using Abstraction and Refinement techniques to develop Modularised Solutions Developing Algorithm Solutions using either Flowcharts or Pseudocode Using Structure Charts, Data Flow Diagrams, or System Flowcharts to show the relationship between Modules or processes Designing Test Data to Test the Solution Bill Biddle 2002 Steps involved in designing Typically the Design process follows the following steps 1. 2. 3. 4. 5. 6. A mainline solution is developed Data structures are developed and a Data Dictionary is produced The mainline solution is refined and represented as a hierarchy of modules in a structure chart. Solutions for each module are represented as Algorithms using either Standard Algorithms or Custom Algorithms Test Data is developed. Algorithms are desk checked using test data and refined if necessary Bill Biddle 2002 Data Typing A Name (or Identifier) must be given to each data element The data type for each element must be decided. These data types may be simple data types or structures data types defined by the user. eg Simple Data Types Structured Data Types - Boolean - Character - Integer and Long Integer - Floating Point (Real Numbers) - Arrays Single Precision & Double Precision - Bytes - Strings Single Dimensional Multi Dimensional - Records - Files Sequential Random Access Bill Biddle 2002 Data Dictionaries Data Dictionaries are used to keep track of Data Identifiers and their types. They are also used to show the data length and range of acceptable values eg Identifier Data Type Size Description SalePrice CharPosition CharCode Name ProductDetails ProductCode Products String Real (Single) Integer Byte String Record String Array 256 Range Example Incomplete 1 25 13 4000 products Bill Biddle 2002 Global Variables, Local Variable & Parameters As well a deciding what data types are needed, you need to decide how they are going to be used. Global Variable are available across all modules in a program Local Variables are defined an used within a specific module Parameters allow values to be passed from one module to another even though the variable may be named differently. Modules become reusable if they make use of local variables and parameters instead of global variables Bill Biddle 2002 Abstraction and Refinement Abstraction is the process of starting out with a simple idea and elaborating on it so you provide more detail Abstraction is used in designing solutions Mainline solutions can be refined so that they gradually display more detail. This process is called “Top Down Design” HIPO charts and Structure Charts may help show the relationship between modules Bill Biddle 2002 Structure Charts Structure Charts show; The hierarchical relationship between modules The parameters that are passes between modules Conditional branching and looping between modules eg. Repetition Parameter passing Random Numbers 1 2 Input 6, 1 digit v alues Conditional branching 3 Generate 100 random 6 digit Numbers containing only the 1 digit v alues Output Random Numbers 4 Format 2 columns Format 4 columns Bill Biddle 2002 Algorithms An algorithm consists of a set of explicit and unambiguous finite steps which, when carried out for a given set of initial conditions, produce the corresponding output and terminate in finite time. How to Solve it by Computer, RG Dromey, Prentice Hall UK, 1982 Algorithms can be represented using; Pseudocode Flowcharts Standard Algorithms are used to describe common routine involved with Finding max & min values String processing File processing Linear Searches Binary Searches Bubble Sorts Inserting Sorts Selection Sorts Bill Biddle 2002 Pseudocode Pseudocode means “like code” Pseudocode uses pairs of “Reserved Words” to establish control structures User-defined Identifiers and Processes define the tasks to be performed Several techniques can be used to make pseudocode more readable Capitalise reserved words Underline procedure identifiers Indent the processes between corresponding pairs of reserved words Bill Biddle 2002 Pseudocode Sample BEGIN MAINPROGRAM StudentRooming = Array[1..4,0..2,1..25] FOR BlockIndex = 1 to 4 FOR FloorIndex = 0 to 2 FOR RoomIndex = 1 to 25 Output StudentRooming[BlockIndex, FloorIndex, RoomIndex] CASEWHERE BlockIndex = 1: Output "A" 2: Output "B" 3: Output "C" 4: Output "D" END CASE CASEWHERE FloorIndex = 0: Output "" 1: Output "1" 2: Output "2" ENDCASE IF RoomIndex <10 and FloorIndex >0 THEN Output "0",RoomIndex ELSE Output RoomIndex ENDIF NEXT RoomIndex NEXT FloorIndex NEXT BlockIndex END MAINPROGRAM Bill Biddle 2002 Flowcharts Flowcharts use a series of shapes to represent processes. Arrows are used to show the sequence Flowcharts are good a representing small solutions. Once the solution gets bigger than the page, it is hard to follow. When developing flowcharts you must be careful to form the control structures properly. (It is easy to create solutions that cannot be coded.) Bill Biddle 2002 Test Data Design Test data should be designed to adequately test each module Test data should be designed for Good test data will all values that are input by the user all values that are passed into a module using parameters test all pathways in the module test the all boundary conditions test above and below boundary conditions Sample outputs should be provided for each piece of test data Bill Biddle 2002 Documentation Most of the documentation developed during stage 2 is intended for use by the programming teams in stage 3 It should include Refinements of system documentation Data Dictionaries Screen designs Software Specifications Algorithms Test data Bill Biddle 2002 Stage 3 Implementation of Software Solutions Implementation of Software Solutions involves converting paper-based solutions into solutions that work on a computer system. This involves; implementing screen designs coding algorithms using an appropriate language (Sequential or Event driven) Translation of the code (Compliers or Translators) detecting and correcting errors using appropriate techniques (breakpoints, traces, stepping, output debugging statements) documenting the solution (user documentation, technical documentation, project documentation) Bill Biddle 2002 Steps Involved in Implementation If a teams approach is used typically different teams will be allocated different parts of the solution to implement. Each team will be responsible for Building the screens Coding algorithms for their part using standard libraries where possible Detecting and correcting errors (Debugging) Developing the documentation needed for the solution Bill Biddle 2002 Building Screen Designs Most modern programming languages allow screen designs to be developed by dragging screen elements onto a form eg. Bill Biddle 2002 Program Development Techniques Programmers should follow a strategy when entering code. The best strategy seems to be based on the idea that the program should always run even if you haven’t finished coding. This can be achieved by; Using Stubs – A separate stub is used for each procedure. Progressively, each procedure is coded and debugged. Limiting the size of Procedures or subroutines to 1 logical task to make it easy to debug Documenting the code as you go. Intrinsic documentation and internal remarks should be added to explain what you have done Isolating problem areas with brackets and using output debugging statements and flags to try to figure out what is going on. Bill Biddle 2002 Types of Errors No matter how careful programmers are, errors always creep into the code Error types include; Syntax Errors Logic Errors Runtime Errors Calculation Errors Errors can be detected by attempting to compile or interpret the source code carrying out peer checking and desk checking using debugging tools using output debugging statements, flags and isolating segments of code Bill Biddle 2002 Syntax Errors Syntax Errors are errors that are reported during translation of the code. Syntax Errors occur when the source code does not match the Syntax Rules defined for the language eg a misspelled reserved word will mean that the translator will not generate a token for the command and the syntactical analyser will pick up the error Most Compilers and Interpreters are clever enough to issue a error message indicating how to fix the error. eg BEGIN expected Type Mismatch Error ‘:=‘ expected Error in statement Bill Biddle 2002 Logic Errors Logic Errors are usually detected during Design Stage but some might creep through to the Implementation Stage. A Logic Error is an error that results from an mistake made in defining a condition that is used to determine the path taken in a solution Logic Errors may occur at IF conditions WHILE conditions UNTIL conditions CASEWHERE conditions FOR conditions Logic errors may also result from performing processes in the wrong order or leaving out processes Bill Biddle 2002 Desk Checking Desk Checking is a manual process which is mainly used to pick up logic errors and calculation errors In a desk check every step in the solution is recorded along with the value of variable input, processed and output, and the results of conditions tested Desk checking should be used to check programming code when you detect a logic error Bill Biddle 2002 Sample code for Desk check Desk check the following segment using the following values for the Array called Marks [15, 15, 12, 18, 8, 9] Index = 1 WHILE Index < 6 Index = Index+1 Value = Marks[Index] Pointer = Index WHILE ( Marks[Pointer-1] > Value ) Marks[Pointer] = Marks[Pointer-1] Pointer = Pointer-1 Marks[Pointer] = Value ENDWHILE ENDWHILE Bill Biddle 2002 Desk check Solution Step Index Value Pointer Test Cond1 Test Cond2 Marks in array set Index M [3] M [4] M M [5] [6] 15 15 12 18 8 9 Yes 2 Value = Marks[2] 15 Pointer = Index 2 Is Marks [2-1] > Value No Is Index < 6 Index = Index + 1 M [2] 1 Is Index < 6 Index = Index + 1 M [1] Yes 3 Bill Biddle 2002 Runtime Errors Runtime errors are errors that are reported to the user once the program has been translated successfully and is up and running Runtime errors are usually fairly difficult to locate Runtime errors may result from events like recursive calls producing a “Stack Overflow” error calls to invalid filenames or hardware resources poor error trapping of user input resulting in errors like “Divide by Zero” error calculations that produce values that can’t be stored such as “Floating Point Overflow” error. Although runtime errors may show up during this stage, it is more usual that they will be picked up during thorough testing in Stage 4 Bill Biddle 2002 Expected Outputs The programmer using sample test data should compare the actual outputs against sample outputs If an application delivers the Expected outputs then it is ready for Stage 4 (Testing and Evaluation) If Unexpected outputs occur they are usually a result of Logic Errors or Calculation Errors and need to be fixed These errors are usually picked up once the application is running Desk checking and Debugging tools should be used to fix the problem Bill Biddle 2002 Debugging Tools and Techniques Most modern language have inbuilt debugging tools The contain features such as Setting breakpoints and stops resetting variable contents program traces step-throughs (similar to an online desk check) The programmer may also use his/her own techniques such as output debugging statements isolating code segments flags Bill Biddle 2002 Forms of Documentation Used There are 3 main areas in which documentation needs to be developed 1. Project documentation involving 2. User documentation including 3. the use of process diaries, log books, Gantt Charts and CASE Tools user manuals online help system installation guides tutorials Technical Documentation including Internal documentation of the Code Self documentation (Intrinsic Documentation) Remarks and Comments Systems Documentation Documentation for subsequent Maintenance Bill Biddle 2002 User Documentation Once a solution has been built the User Documentation can be produced User documentation is needed in 2 areas Online documentation includes Online Documentation External Documentation Help systems accesses via a menu in the application Context sensitive help such as “Balloon text” Links to tutorials or multimedia presentations External documentation includes paper-based user manuals installation guides tutorials system’s administrator guides license agreements Bill Biddle 2002 Technical Documentation Technical documentation is designed for use by the developers and maintenance programmers This documentation includes; System documentation Structures Charts Data Flow diagrams System Flowcharts Data Dictionaries IPO Charts Story Boards Screen Designs Algorithms Source Code (with appropriate internal documentation) Bill Biddle 2002 Stage 4 Testing and Evaluation of Software Solutions Testing is the process of making sure that the software solution meets all the defined requirements Evaluation has more to do with Quality Assurance and examining what people think of the solution measuring its functionality, user-friendliness, versatility, portability, etc Testing can take place on a number of different levels the module level the program level the system level the street level (user level) Testing techniques may include Black box testing White box testing Bill Biddle 2002 Steps Involved in Testing Module Testing There is a hierarchy in testing. It is probably best represented by a typical Waterfall Model Program Testing System Testing Live Acceptance Testing Bill Biddle 2002 Module Testing At the Module level testing 2 types of testing are used 1. White box testing. This form of testing may use a minimal data set to test each pathway through the module OR 2. Use test data which tests the boundary value, a value above the boundary, and a value below the boundary for each condition in the program Black box testing With black box testing only the inputs and checked against the expected outputs Black box testing does not check the processes behind the outputs. If the output is correct, then the process is assumed to be correct. Bill Biddle 2002 Program Testing Many programs are so large that it is impossible to test every pathway or every possible combination of user inputs Program testing instead focuses on testing whether or not data passes between modules properly and whether modules are called when they should be. One approach is called Integration Testing. With Integration testing modules are progressively added to the main program and black box testing is employed Interface testing is also carried out to examine whether all the navigation elements work properly Bill Biddle 2002 System Testing Programs are usually developed under highly controlled environments. During System testing the application is exposed to a variety of different operating environments including; different operating systems and different hardware System testing is carried out to detect errors involved with the software / hardware interface Black box testing is usually used for system testing Bill Biddle 2002 Live Testing Live testing involves the use of real data in real environments Live testing is used to test the applications ability to handle real data including unexpected values response times the ability of the application to handle the required volume of data (Stress testing) a users interaction with the user interface Live testing includes Alpha testing (where the application is released to a small number of interested clients) and Beta testing (where the application is release to a larger cross section of the market place) Errors that are reported are corrected before the final release. Bill Biddle 2002 Evaluation Evaluation has to do with how well a new application meets the needs and expectations of users / clients The process of ensuring that the end product meets user expectation is called “Quality Assurance” During Quality Assurance the application is evaluated against a set of criteria including; usability flexibility integrity accuracy clarity maintainability portability reliability reusability inclusively scalability efficiency economy quality of documentation Bill Biddle 2002 Documentation Needed Reports need to be generated to validate the reliability of the testing process. The document is called a “Software Test Report” CASE Tools are often used to assist with the testing process. They; manage the testing process generating tests automatically and generating reports automatically Bill Biddle 2002 Stage 5 Maintenance of Software Solutions Maintenance is the process of modifying a solution for an important reason. Modifications may be undertaken to remove a bug from the program improve the efficiency of the code cater for new user requirements – add new function improve the user interface cater for new hardware Modifications may be achieved through the use of patches the addition macros and script files version updates requiring rewrites Bill Biddle 2002 Steps involved in Maintenance Maintenance is usually undertaken by the developer but in some instances businesses employ their own maintenance programmers to handle changes The steps involved with maintenance depend upon the type of application. Some applications can be modified through the use of Macros and Script files. This applies mainly to those applications developed with RAD Tools. Other applications can only be maintained by making changes to the original source code. For these applications it is necessary to revisit ALL the stages in the Software Development Cycle, again CASE Tools can be used to help monitor and document changes Bill Biddle 2002 Documentation Required Ongoing maintenance of a solution means that there needs to be ongoing changes to the documentation User manuals need to be updated to describe new features Changes to source code, macros and script files need to be well documented File version numbers need to be maintained to ensure the correct files work together Bill Biddle 2002 The End Bill Biddle 2002