Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ch03-Software Engineering Model


Published on

Published in: Technology, Education
  • Be the first to comment

Ch03-Software Engineering Model

  1. 1. Software Engineering:Chapter 31 D.Balaganesh Lincoln university College
  2. 2. Prescriptive Models2 Prescriptive process models advocate an orderly approach to softwareengineeringThat leads to a few questions … If prescriptive process models strive for structure and order, are theyinappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they imply) andreplace them with something less structured, do we make it impossible toachieve coordination and coherence in software work?D.Balaganesh Lincoln university College
  3. 3. SDLC ModelD.Balaganesh LINCOLN UNIVERSITYCOLLGE3A framework that describes the activities performed at each stage of asoftware development project.
  4. 4. Waterfall ModelRequirements – defines neededinformation, function, behavior,performance and interfaces.Design – data structures, softwarearchitecture, interface representations,algorithmic details.Implementation – source code,database, user documentation, testing.D.Balaganesh LINCOLNUNIVERSITY COLLGE 4
  5. 5. Waterfall Model5D.Balaganesh LINCOLNUNIVERSITY COLLGE
  6. 6. Waterfall ModelTest – check if all code modules worktogether and if the system as a wholebehaves as per the specifications.Installation – deployment of system,user-training.Maintenance – bug fixes, addedfunctionality (an on-going process).D.Balaganesh LINCOLNUNIVERSITY COLLGE 6
  7. 7. Waterfall StrengthsD.Balaganesh LINCOLN UNIVERSITYCOLLGE7Easy to understand, easy to useProvides structure to inexperienced staffMilestones are well understoodSets requirements stabilityGood for management control (plan, staff, track)
  8. 8. Waterfall DeficienciesD.Balaganesh LINCOLN UNIVERSITYCOLLGE8All requirements must be known upfrontDeliverables created for each phase are considered frozen –inhibits flexibilityDoes not reflect problem-solving nature of softwaredevelopment – iterations of phasesIntegration is one big bang at the endLittle opportunity for customer to preview the system (untilit may be too late)
  9. 9. When to use the Waterfall ModelD.Balaganesh LINCOLN UNIVERSITYCOLLGE9Requirements are very well knownWhen it is possible to produce a stable designE.g. a new version of an existing productE.g. porting an existing product to a new platform.
  10. 10. Spiral SDLC ModelAdds risk analysis, and 4glRAD prototyping to thewaterfall modelEach cycle involves thesame sequence of steps asthe waterfall process modelD.Balaganesh LINCOLNUNIVERSITY COLLGE 10
  11. 11. Spiral QuadrantDetermine objectives, alternatives and constraintsD.Balaganesh LINCOLN UNIVERSITYCOLLGE11Objectives: functionality, performance, hardware/software interface,critical success factors, etc.Alternatives: build, reuse, buy, sub-contract, etc.Constraints: cost, schedule, man-power, experience etc.
  12. 12. Spiral QuadrantEvaluate alternatives, identify and resolve risksD.Balaganesh LINCOLN UNIVERSITYCOLLGE12Study alternatives relative to objectives and constraintsIdentify risks (lack of experience, new technology, tightschedules, etc.)Resolve risks
  13. 13. Spiral QuadrantDevelop next-level productD.Balaganesh LINCOLN UNIVERSITYCOLLGE13Typical activites:Create a designReview designDevelop codeInspect codeTest product
  14. 14. Spiral QuadrantPlan next phaseD.Balaganesh LINCOLN UNIVERSITYCOLLGE14Typical activitiesDevelop project planDevelop a test planDevelop an installation plan
  15. 15. Spiral Model StrengthsD.Balaganesh LINCOLN UNIVERSITYCOLLGE15Provides early indication of insurmountable risks,without much costUsers see the system early because of rapid prototypingtoolsCritical high-risk functions are developed firstUsers can be closely tied to all lifecycle stepsEarly and frequent feedback from users
  16. 16. Spiral Model WeaknessesD.Balaganesh LINCOLN UNIVERSITYCOLLGE16Time spent for evaluating risks too large for small or low-risk projectsTime spent planning, resetting objectives, doing riskanalysis and prototyping may be excessiveThe model is complexRisk assessment expertise is requiredSpiral may continue indefinitelyDevelopers must be reassigned during non-developmentphase activities
  17. 17. When to use Spiral ModelD.Balaganesh LINCOLN UNIVERSITYCOLLGE17When creation of a prototype is appropriateWhen costs and risk evaluation is importantFor medium to high-risk projectsUsers are unsure of their needsRequirements are complexNew product lineSignificant changes are expected
  18. 18. Tailored SDLC ModelsD.Balaganesh LINCOLN UNIVERSITYCOLLGE18No single model fits all projectsIf there is no suitable model for a particular project,pick a model that comes close and modify it for yourneeds.If project should consider risk but complete spiral model is toomuch – start with spiral and simplify itIf project should be delivered in increments but there areserious reliability issues – combine incremental model with theV-shaped modelEach team must pick or customize a SDLC model to fitits project
  19. 19. The Waterfall ModelD.Balaganesh Lincoln university College19Communicat ionPlanningModelingConst ruct ionDeploymentanalysisdesigncodet estproject init iat ionrequirement gat hering estimatingschedulingtrackingdeliverysupportf eedback
  20. 20. The Incremental ModelD.Balaganesh Lincoln university College20C o m m u n i c a t i o nP l a n n i n gM o d e l i n gC o n s t r u c t i o nD e p l o y m e n td e l i v e r yf e e d b a c kanaly s isdes ign c odet es tincrement # 1increment # 2delivery of1st incrementdelivery of2nd incrementdelivery ofnt h incrementincrement # nproject calendar timeC o m m u n i c a t i o nP l a n n i n gM o d e l i n gC o n s t r u c t i o nD e p l o y m e n td e l i v e r yf e e d b a c kanaly sisdes ign c odet es tC o m m u n i c a t i o nP l a n n i n gM o d e l i n gC o n s t r u c t i o nD e p l o y m e n td e l i v e r yf e e d b a c kanaly s isdes ignc odet es t
  21. 21. The RAD ModelD.Balaganesh Lincoln university College21Communicat ionPlanningModelingbusiness modelingdat a modelingprocess modelingConst ruct ioncomponent reuseaut omat ic codegenerat iont est ingDeployment60 - 90 daysTeam # 1Modelingbusiness m odelingdat a m odelingprocess m odelingConst ruct ioncom ponent reuseaut om at ic codegenerat iont est ingM o d e lin gbusiness m odelingdata m odelingprocess m odelingCo n st ru ct io ncom ponent reuseautom atic codegenerationtestingTeam # 2Team # nint egrat iondeliveryfeedback
  22. 22. Evolutionary Models: PrototypingD.Balaganesh Lincoln university College22Communicat ionQuick planConst ruct ionofprot ot ypeMode lingQuick de signDelivery& FeedbackDeploymentcommunicationQuickplanModelingQuick designConstructionof prototypeDeploymentdelivery &feedback
  23. 23. Component Assembly ModelD.Balaganesh Lincoln university College23IdentifycandidatecomponentsLook upcomponentsin libraryAvailable?ExtractcomponentsBuildcomponentsConstructSystemyesno
  24. 24. Component AssemblyCharacteristicsD.Balaganesh Lincoln university College24Use of object-oriented technologyComponents - classes that encapsulate both data andalgorithmsComponents developed to be reusableParadigm similar to spiral model, but engineering activityinvolves componentsSystem produced by assembling the correct components
  25. 25. Fourth Generation Techniques(4GT)D.Balaganesh Lincoln university College25"Design"StrategyTestingRequirementsgatheringImplementationusing 4GL
  26. 26. 4GT CharacteristicsD.Balaganesh Lincoln university College26Use of software tools that allow software engineer to specifys/w characteristics at higher levelThe tools generate codes based on specificationMore time in design and testing - increase productivityTools may not be easy to use, codes generated may not beefficient
  27. 27. Other Process ModelsD.Balaganesh Lincoln university College27 Component assembly model—the process to apply when reuse is adevelopment objective Concurrent process model—recognizes that different part of the projectwill be at different places in the process Formal methods—the process to apply when a mathematical specification isto be developed Cleanroom software engineering—emphasizes error detection beforetesting
  28. 28. Evolutionary Models: ConcurrentD.Balaganesh Lincoln university College28Under reviewBaselinedDoneUnderrevisionAwait ingchangesUnderdevelopmentnoneModeling act ivit yrepresents the stateof a software engineeringactivity or task
  29. 29. Still Other Process ModelsD.Balaganesh Lincoln university College29Component based development—the process to apply whenreuse is a development objectiveFormal methods—emphasizes the mathematical specification ofrequirementsAOSD—provides a process and methodological approach fordefining, specifying, designing, and constructing aspectsUnified Process—a “use-case driven, architecture-centric,iterative and incremental” software process closely aligned withthe Unified Modeling Language (UML)
  30. 30. ConclusionD.Balaganesh Lincoln university College30The paradigm used for development of software depends on anumber of factorsPeople - staff & usersSoftware productTools availableEnvironmentExisting models makes development process clearer, but theycan be evolved to become new paradigms
  31. 31. The Unified Process (UP)D.Balaganesh Lincoln university College31inceptioninceptionsoft ware incrementReleaseIncept ionElaborat ionconst ruct iont ransit ionproduct ioninceptionelaboration
  32. 32. UP PhasesD.Balaganesh Lincoln university College32Inception Elaboration Construction Transition ProductionUP PhasesWorkflowsRequirementsAnalysisDesignImplementationTestIterations #1 #2 #n-1 #nSupport
  33. 33. UP Work ProductsD.Balaganesh Lincoln university College33Inception phaseElaboration phaseConstruction phaseTransition phaseVision documentInit ial use-case modelInit ial project glossaryInit ial business caseInit ial risk assessment .Project plan,phases and it erat ions.Business model,if necessary.One or more prot ot ypesI nc e pt i onUse-case modelSupplement ary requirement sincluding non-funct ionalAnalysis modelSoft ware archit ect ureDescript ion.Execut able archit ect uralprot ot ype.Preliminary design modelRevised risk listProject plan includingit erat ion planadapt ed workflowsmilest onest echnical work product sPreliminary user manualDesign modelSoft ware component sInt egrat ed soft wareincrementTest plan and procedureTest casesSupport document at ionuser manualsinst allat ion manualsdescript ion of currentincrementDelivered soft ware incrementBet a t est report sGeneral user feedback