ImplementationSlide 2Delineating IV and VManaging ImplementationSlide 5Order of Program DevelopmentSlide 7Slide 8Slide 9Slide 10Source Code Control and VersioningExample of SCCSVersioningSlide 14Slide 15Slide 16QA and TestingSlide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26InstallationDirect (Big-Bang) InstallationParallel InstallationSingle Location InstallationPhased InstallationSlide 32DocumentationSlide 34Slide 35ImplementationWeek 14CMIS570SDLCProject PlanningAnalysisDesignImplementation***SupportDelineating IV and VImplementationActivities that occur before the system is turned over to its usersMaintenance/SupportActivities that occur after the system becomes operationalManaging ImplementationAnalogy to building a houseArchitecture (analysis/design)Construction (implementation)Large number of peopleMyriad interdependent activitiesProgram developmentQuality assurancePhysical installationDocumentationTrainingManaging ImplementationMAJOR ISSUES:Order of program developmentOrder of program developmentSource code control & versioningSource code control & versioningQuality assurance and testingInstallationDocumentation and trainingOrder of Program DevelopmentIPO (1-Input, 2-Process, 3-Output)Advantages:Simplifies testingInput programs can be used to enter test dataUser interfaces are developed earlyAllows for early user evaluation of interfacesHead start on user documentation and training materialsDisadvantages:Late implementation of outputsOutputs are helpful in testing process modulesOrder of Program DevelopmentTOP-DOWNCreate “stub” versions of subordinate modulesPrimary advantage:Always a working version of a programPrimary disadvantage:Use of programming personnel at beginning can be inefficientOrder of Program DevelopmentBOTTOM-UPCreate “driver” versions of calling programsAdvantages:Efficient use of programmers from the get-goLower-level modules often most complex, so this allows more time for development and testing of themDisadvantages:Writing a large number of “driver” programsAdds complexity to developing and testing processOrder of Program DevelopmentIs just one part of the overall development and test planDevelopment and testing go hand-in-handPlan should be created before beginning program development, covering:Development orderTesting orderGeneration of test dataTest casesAcceptance criteriaPersonnel and other resource needsSource Code Control and VersioningSCCSAutomated tool for tracking source code files and controlling changes to those filesAllows only 1 programmer to check out a file to updatePrevents multiple programmers from updating same file at same timeExample of SCCSVersioningFor development, testing, and maintenance of large complex systemsUsed in development:Alpha version(s)Test version that is incomplete but ready for some level of rigorous testingLifetime is usually short (days or weeks)VersioningUsed in testing:Beta version(s)Test version that is stable enough to be tested by end users (to do real work)Produced after one or more alpha versions have been “perfected”Typically evaluated over period of weeks or monthsVersioningUsed in production/maintenance:Production version (or release)Formally distributed to usersConsidered the final productMultiple production versions are used to add features and fix bugs discovered after releasing original production versionSource Code Control and VersioningVersioning control is a part of most sophisticated SCCS’sNew programs and system versions move along this general landscape:DevelopmentandUnit TestingIntegrationand SystemsTestingProductionQA and TestingQuality Assurance (QA)Quality Assurance (QA)Process of ensuring that an IS meets minimal quality Process of ensuring that an IS meets minimal quality standardsstandardsQA during Analysis phase:Identifying gaps or inconsistencies in system requirementsQA during Design phase:Satisfying stated requirements and making appropriate design decisionsQA during Implementation phase:Applying QA tools to program design and coding, and then TestingQA and TestingQA tools used throughout SDLC:Technical reviewFormal or informal review of analysis, design, or development details by a group of analysts, developers, and/or usersWalkthough is one type of technical reviewTwo or more people review the accuracy and completeness of a model or programDeveloper of model or program leads the walkthrough, describing assumptions, key decisions, and operationQA and TestingQA tools used throughout SDLC:InspectionMore formal version of a walkthroughParticipants review and analyze materials before they meet as a groupParticipants play specific roles:Presenter – usually the developer, summarizes the material being inspectedCritics – describe errors and concerns foundRecorder – records all errors/concerns and the agreed-upon solution strategiesQA and TestingWalkthroughs and inspections have been found to:Reduce number of errors that reach testing by a factor of 5 to 10Reduce testing costs by approx. 50%Goal is to catch as many errors as possible using these QA tools – prior to TestingQA and TestingTESTINGProcess of examining a product to determine what defects it containsTESTING in Implementation phase:UnitTesting individual programs or modulesIntegrationTesting groups of programs/modulesSystemsTesting an entire system (including interfaces between application components)QA and TestingTest planning is not easy!Should utilize QA tools (to ensure quality of test plan!)Walkthrough test plansInspect test casesTest plans and cases should be retained after ImplementationWHY?QA and TestingUNIT TestingTesting of individual modules before they are integrated with other modulesExamines internal design of programThe goal: Every instruction should be executed at least oncePath testing: Design test cases that focus on small segments of code; aim to exercise a high percentage of the internal pathsCalled “white box” testingQA and TestingINTEGRATION TestingTesting of a group of modules“Black box” testing – done without knowledge of programs’ internal designCan elucidate problems such
View Full Document