CSI 101 Elements of Computing Spring 2009 Lecture #2 Development Life Cycle of a Computer Application Monday January 26th, 2009

What is a Life Cycle? Process from idea to execution It's all the steps required to create a computer program from a general problem statement

Why a Life Cycle? Systematic approach Everybody can follow Repeatable success Checkpoints ● Checkpoints are steps along the way, prior to completion, where you can stop and check your progress ● Allows you to know if you are on schedule or behind ● Can check for major errors that would be time- consuming to fix later

Development Life Cycle Requirements Gathering Design High level Low level Create Data Dictionary Program Functions Interfaces Testing Documentation

Step 1 – Requirements Gathering Most important step Why? ● The better you understand the task, the better your focus and the better product you create ● Eliminates trial and error of constantly requiring user feedback Lists the functionality the user wants What data changes and how Diagrams how user wants to see it Interface – how user interacts with program

Step 2 - Design Many large companies have two levels High level design is for interfaces and libraries How outside elements are needed or provided by each component Identifies functional boundaries Very general Low level design is for key functionality Outline process performed by each component

Step 3 – Data Dictionary Create reusable body of data elements Provides structure and template to other component parts of a large application Can even be reused in other programs Can be included in object libraries Object libraries are repositories of reusable data structures Reinforces customer view of data while planning how machine will implement it

Evolution of Data Dictionary In procedural languages, it was optional Mostly used by computers with frequent reviews (like IBM) or database applications Not considered necessary, as functions were most important Object-Oriented Programming changed all that Now transactions and transformation of data focus We'll discuss Object-Oriented Programming later in this course

Importance of Data Dictionary Wasn't crucial until Object-Oriented Programming Object-Oriented Programming focuses on taking input data and creating output data Hides complex functionality inside enclosed “modules” Programs become series of functions that use these “modules” Most modern programs are written in Object-Oriented Programming languages Allows identification of crucial objects that might be used throughout program

Step 4 - Program Not a patchwork anymore Systematic approach Inside out Take care of internal functions Expand outwards Look for recursion and reuse opportunities Internal subroutine blocks Take advantage of DLLs

So... What's a DLL? Dynamic Link Library 2 stages to decomposing code to machine level Compilation : translating programming language into machine-understandable code Linking : putting together machine-language code pieces into a single executable program Dynamic link libraries contain precompiled pieces of code that can be linked with program

Advantages of DLLs Precompiled pieces contain templates or parameters, so the precompiled code can be adjusted This means code can be changed without having to recompile Can make conditional changes that are based on data defined or calculated when the program runs Hence name “dynamic” - changeable

Step 5 - Testing Here's where companies got crazy Thought the more you tested, the better the result “Work the bugs out” Can never find every problem Why not? Can never anticipate every possible move The fallacy of “idiot proofing”

Auto-Builds Code builds from automated computerized design packages Thought – instead of spending time removing errors, why not prevent inserting them? If requirements gathering was good, errors inserted by humans Worked great, but not widely used Programmers still like control Did require tweaking

Test levels Unit test – test individual component Function test – test individual user function as it processes System Test – test full package as it interacts with components Regression Test – ensure upgrades don't harm existing applications This is the step Microsoft forgets Useability Test – ease of use Reliability Test – stability Sometimes called Stress Test

Unit Test Usually performed by programmer Test each line of code Often done in a Debug environment of the Development environment package where the code is written Involves stepping through the code and checking important data values Test all condition results and loop paths We’ll discuss conditions and loops when we get into Visual Basic programming

Function Test Often done by Project Leader Tests an entire path based upon different initial data values Ensures function returns expected values without failing Often tests expectable “incorrect” data as well to ensure program won’t fail

System Test Usually handled by a separate team Create a test environment that simulates customer’s environment Might require multiple tests to simulate multiple environments Specific tests are performed, based upon environment and customer need Tests are created beforehand, while program is being coded

Regression Test Frequently done along with System Test Uses applications obtained from the customer Ensures new version will work with additional applications created under the old one

Useability Test Performed by customers Often call “Beta Testing” A small group of customers are shown Users Guide and allowed to try new program They determine if the program is easy to understand and use

Reliability Test Also called “Stress Testing” Often done by System Test team Designed to see how program responds to busy system Run lots of applications at same time as program Competing for processor time Rarely done anymore Processor power is greater, so not much of a concern anymore

Documentation Not truly a “step” Best to document as you go along What to document? Anything that someone else would need to know to modify the program Data structures and what they represent Complex formulas or functions Changes from earlier versions

Library Documentation Used for descriptions of DLL packages Describes function Describes expected input and form Describes form of output Describes what and how to customize Also used for Class Libraries in Object- Oriented Programming languages

Design Documentation Used to maintain accurate overview of project Original created after Requirements Used to distribute work among team Ensures completeness Update if design changes or additions occur “Living document”

Checkpoint Documentation Created as part of project schedule Shows functions, data, or components complete at specific time Allows for prioritization Helps see slowdowns before they cause major project delays

User Documentation Documents provided to user Users Guide – how to use tool Detailed, often with screen shots Step by step instructions Covers common functions Implementation Guide – how to customize Developers Guide – libraries and interfaces for expanding

WIKI Documentation Many documents are now links to Internet files Updateable by any customer Called “wiki”s or “living documents” Anyone with permission can provide an update Often checked by someone who “owns” the document