Software Engineering:Chapter 31 D.Balaganesh Lincoln university College
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
SDLC ModelD.Balaganesh LINCOLN UNIVERSITYCOLLGE3A framework that describes the activities performed at each stage of asoftware development project.
Waterfall ModelRequirements – 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
Waterfall ModelTest – 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
Waterfall StrengthsD.Balaganesh LINCOLN UNIVERSITYCOLLGE7Easy to understand, easy to useProvides structure to inexperienced staffMilestones are well understoodSets requirements stabilityGood for management control (plan, staff, track)
Waterfall DeficienciesD.Balaganesh LINCOLN UNIVERSITYCOLLGE8All requirements must be known upfrontDeliverables created for each phase are considered frozen –inhibits flexibilityDoes not reflect problem-solving nature of softwaredevelopment – iterations of phasesIntegration is one big bang at the endLittle opportunity for customer to preview the system (untilit may be too late)
When to use the Waterfall ModelD.Balaganesh LINCOLN UNIVERSITYCOLLGE9Requirements are very well knownWhen it is possible to produce a stable designE.g. a new version of an existing productE.g. porting an existing product to a new platform.
Spiral SDLC ModelAdds risk analysis, and 4glRAD prototyping to thewaterfall modelEach cycle involves thesame sequence of steps asthe waterfall process modelD.Balaganesh LINCOLNUNIVERSITY COLLGE 10
Spiral QuadrantDetermine objectives, alternatives and constraintsD.Balaganesh LINCOLN UNIVERSITYCOLLGE11Objectives: functionality, performance, hardware/software interface,critical success factors, etc.Alternatives: build, reuse, buy, sub-contract, etc.Constraints: cost, schedule, man-power, experience etc.
Spiral QuadrantEvaluate alternatives, identify and resolve risksD.Balaganesh LINCOLN UNIVERSITYCOLLGE12Study alternatives relative to objectives and constraintsIdentify risks (lack of experience, new technology, tightschedules, etc.)Resolve risks
Spiral QuadrantDevelop next-level productD.Balaganesh LINCOLN UNIVERSITYCOLLGE13Typical activites:Create a designReview designDevelop codeInspect codeTest product
Spiral QuadrantPlan next phaseD.Balaganesh LINCOLN UNIVERSITYCOLLGE14Typical activitiesDevelop project planDevelop a test planDevelop an installation plan
Spiral Model StrengthsD.Balaganesh LINCOLN UNIVERSITYCOLLGE15Provides early indication of insurmountable risks,without much costUsers see the system early because of rapid prototypingtoolsCritical high-risk functions are developed firstUsers can be closely tied to all lifecycle stepsEarly and frequent feedback from users
Spiral Model WeaknessesD.Balaganesh LINCOLN UNIVERSITYCOLLGE16Time spent for evaluating risks too large for small or low-risk projectsTime spent planning, resetting objectives, doing riskanalysis and prototyping may be excessiveThe model is complexRisk assessment expertise is requiredSpiral may continue indefinitelyDevelopers must be reassigned during non-developmentphase activities
When to use Spiral ModelD.Balaganesh LINCOLN UNIVERSITYCOLLGE17When creation of a prototype is appropriateWhen costs and risk evaluation is importantFor medium to high-risk projectsUsers are unsure of their needsRequirements are complexNew product lineSignificant changes are expected
Tailored SDLC ModelsD.Balaganesh LINCOLN UNIVERSITYCOLLGE18No single model fits all projectsIf 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 itIf project should be delivered in increments but there areserious reliability issues – combine incremental model with theV-shaped modelEach team must pick or customize a SDLC model to fitits project
The Waterfall ModelD.Balaganesh Lincoln university College19Communicat ionPlanningModelingConst ruct ionDeploymentanalysisdesigncodet estproject init iat ionrequirement gat hering estimatingschedulingtrackingdeliverysupportf eedback
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
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
Evolutionary Models: PrototypingD.Balaganesh Lincoln university College22Communicat ionQuick planConst ruct ionofprot ot ypeMode lingQuick de signDelivery& FeedbackDeploymentcommunicationQuickplanModelingQuick designConstructionof prototypeDeploymentdelivery &feedback
Component Assembly ModelD.Balaganesh Lincoln university College23IdentifycandidatecomponentsLook upcomponentsin libraryAvailable?ExtractcomponentsBuildcomponentsConstructSystemyesno
Component AssemblyCharacteristicsD.Balaganesh Lincoln university College24Use of object-oriented technologyComponents - classes that encapsulate both data andalgorithmsComponents developed to be reusableParadigm similar to spiral model, but engineering activityinvolves componentsSystem produced by assembling the correct components
Fourth Generation Techniques(4GT)D.Balaganesh Lincoln university College25"Design"StrategyTestingRequirementsgatheringImplementationusing 4GL
4GT CharacteristicsD.Balaganesh Lincoln university College26Use of software tools that allow software engineer to specifys/w characteristics at higher levelThe tools generate codes based on specificationMore time in design and testing - increase productivityTools may not be easy to use, codes generated may not beefficient
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
Evolutionary Models: ConcurrentD.Balaganesh Lincoln university College28Under reviewBaselinedDoneUnderrevisionAwait ingchangesUnderdevelopmentnoneModeling act ivit yrepresents the stateof a software engineeringactivity or task
Still Other Process ModelsD.Balaganesh Lincoln university College29Component based development—the process to apply whenreuse is a development objectiveFormal methods—emphasizes the mathematical specification ofrequirementsAOSD—provides a process and methodological approach fordefining, specifying, designing, and constructing aspectsUnified Process—a “use-case driven, architecture-centric,iterative and incremental” software process closely aligned withthe Unified Modeling Language (UML)
ConclusionD.Balaganesh Lincoln university College30The paradigm used for development of software depends on anumber of factorsPeople - staff & usersSoftware productTools availableEnvironmentExisting models makes development process clearer, but theycan be evolved to become new paradigms
The Unified Process (UP)D.Balaganesh Lincoln university College31inceptioninceptionsoft ware incrementReleaseIncept ionElaborat ionconst ruct iont ransit ionproduct ioninceptionelaboration
UP PhasesD.Balaganesh Lincoln university College32Inception Elaboration Construction Transition ProductionUP PhasesWorkflowsRequirementsAnalysisDesignImplementationTestIterations #1 #2 #n-1 #nSupport
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
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.