Unformatted text preview:

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 VImplementationActivities that occur before the system is turned over to its usersMaintenance/SupportActivities that occur after the system becomes operationalManaging ImplementationAnalogy to building a houseArchitecture (analysis/design)Construction (implementation)Large number of peopleMyriad interdependent activitiesProgram developmentQuality assurancePhysical installationDocumentationTrainingManaging ImplementationMAJOR ISSUES:Order of program developmentOrder of program developmentSource code control & versioningSource code control & versioningQuality assurance and testingInstallationDocumentation and trainingOrder of Program DevelopmentIPO (1-Input, 2-Process, 3-Output)Advantages:Simplifies testingInput programs can be used to enter test dataUser interfaces are developed earlyAllows for early user evaluation of interfacesHead start on user documentation and training materialsDisadvantages:Late implementation of outputsOutputs are helpful in testing process modulesOrder of Program DevelopmentTOP-DOWNCreate “stub” versions of subordinate modulesPrimary advantage:Always a working version of a programPrimary disadvantage:Use of programming personnel at beginning can be inefficientOrder of Program DevelopmentBOTTOM-UPCreate “driver” versions of calling programsAdvantages:Efficient use of programmers from the get-goLower-level modules often most complex, so this allows more time for development and testing of themDisadvantages:Writing a large number of “driver” programsAdds complexity to developing and testing processOrder of Program DevelopmentIs just one part of the overall development and test planDevelopment and testing go hand-in-handPlan should be created before beginning program development, covering:Development orderTesting orderGeneration of test dataTest casesAcceptance criteriaPersonnel and other resource needsSource Code Control and VersioningSCCSAutomated tool for tracking source code files and controlling changes to those filesAllows only 1 programmer to check out a file to updatePrevents multiple programmers from updating same file at same timeExample of SCCSVersioningFor development, testing, and maintenance of large complex systemsUsed in development:Alpha version(s)Test version that is incomplete but ready for some level of rigorous testingLifetime is usually short (days or weeks)VersioningUsed 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 monthsVersioningUsed in production/maintenance:Production version (or release)Formally distributed to usersConsidered the final productMultiple production versions are used to add features and fix bugs discovered after releasing original production versionSource Code Control and VersioningVersioning control is a part of most sophisticated SCCS’sNew programs and system versions move along this general landscape:DevelopmentandUnit TestingIntegrationand SystemsTestingProductionQA and TestingQuality Assurance (QA)Quality Assurance (QA)Process of ensuring that an IS meets minimal quality Process of ensuring that an IS meets minimal quality standardsstandardsQA during Analysis phase:Identifying gaps or inconsistencies in system requirementsQA during Design phase:Satisfying stated requirements and making appropriate design decisionsQA during Implementation phase:Applying QA tools to program design and coding, and then TestingQA and TestingQA tools used throughout SDLC:Technical reviewFormal or informal review of analysis, design, or development details by a group of analysts, developers, and/or usersWalkthough is one type of technical reviewTwo or more people review the accuracy and completeness of a model or programDeveloper of model or program leads the walkthrough, describing assumptions, key decisions, and operationQA and TestingQA tools used throughout SDLC:InspectionMore formal version of a walkthroughParticipants review and analyze materials before they meet as a groupParticipants play specific roles:Presenter – usually the developer, summarizes the material being inspectedCritics – describe errors and concerns foundRecorder – records all errors/concerns and the agreed-upon solution strategiesQA and TestingWalkthroughs and inspections have been found to:Reduce number of errors that reach testing by a factor of 5 to 10Reduce testing costs by approx. 50%Goal is to catch as many errors as possible using these QA tools – prior to TestingQA and TestingTESTINGProcess of examining a product to determine what defects it containsTESTING in Implementation phase:UnitTesting individual programs or modulesIntegrationTesting groups of programs/modulesSystemsTesting an entire system (including interfaces between application components)QA and TestingTest planning is not easy!Should utilize QA tools (to ensure quality of test plan!)Walkthrough test plansInspect test casesTest plans and cases should be retained after ImplementationWHY?QA and TestingUNIT TestingTesting of individual modules before they are integrated with other modulesExamines internal design of programThe goal: Every instruction should be executed at least oncePath testing: Design test cases that focus on small segments of code; aim to exercise a high percentage of the internal pathsCalled “white box” testingQA and TestingINTEGRATION TestingTesting of a group of modules“Black box” testing – done without knowledge of programs’ internal designCan elucidate problems such


View Full Document

SIUE CMIS 570 - Implementation

Download Implementation
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Implementation and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Implementation 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?