270 likes | 283 Views
Learn about the systematic process from idea to execution in creating a computer program, including requirements gathering, design, data dictionary creation, programming, and testing. Understand the importance of checkpoints and the use of DLLs in the development process.
E N D
CSI 101 Elements of ComputingSpring 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