Transcription
ObjectiveszzSoftware Processeszzz Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 1To introduce software process modelsTo describe three generic process modelsand when they may be usedTo describe outline process models forrequirements engineering, softwaredevelopment, testing and evolutionTo explain the Rational Unified ProcessmodelTo introduce CASE technology to supportsoftware process activities Ian Sommerville 2006Topics coveredzzzzzzA structured set of activities required to develop asoftware system zSoftware Engineering, 8th edition. Chapter 4Slide 3Specification;Design;Validation;Evolution.A software process model is an abstractrepresentation of a process. It presents adescription of a process from some particularperspective. Ian Sommerville 2006Slide 4The waterfall model zSoftware Engineering, 8th edition. Chapter 4Waterfall modelGeneric software process modelszSlide 2The software processSoftware process modelsProcess iterationProcess activitiesThe Rational Unified ProcessComputer-aided software engineering Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Separate and distinct phases of specification anddevelopment.Evolutionary development Specification, development and validation areinterleaved.zComponent-based software engineeringzThere are many variants of these models e.g.formal development where a waterfall-like processis used but the specification is a formalspecification that is refined through several stagesto an implementable design. The system is assembled from existing components. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 5 Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 6
Waterfall model problemsWaterfall model phaseszzzzzzRequirements analysis and definitionSystem and software designImplementation and unit testingIntegration and system testingOperation and maintenanceThe main drawback of the waterfall model isthe difficulty of accommodating change afterthe process is underway. One phase has tobe complete before moving onto the nextphase. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 7zzzz Ian Sommerville 2006Evolutionary developmentzEvolutionary developmentObjective is to work with customers and toevolve a final system from an initial outlinespecification. Should start with well-understoodrequirements and add new features asproposed by the customer.Objective is to understand the systemrequirements. Should start with poorlyunderstood requirements to clarify what is reallyneeded. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 9 Ian Sommerville 2006Problems zLack of process visibility;Systems are often poorly structured;Special skills (e.g. in languages for rapidprototyping) may be required.z For small or medium-size interactive systems;For parts of large systems (e.g. the userinterface);For short-lifetime systems. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 10Slide 11Based on systematic reuse where systemsare integrated from existing components orCOTS (Commercial-off-the-shelf) systems.Process stages Applicability Software Engineering, 8th edition. Chapter 4Component-based softwareengineeringEvolutionary developmentzSlide 8Throw-away prototyping zSoftware Engineering, 8th edition. Chapter 4Exploratory development zInflexible partitioning of the project into distinctstages makes it difficult to respond to changingcustomer requirements.Therefore, this model is only appropriate when therequirements are well-understood and changeswill be fairly limited during the design process.Few business systems have stable requirements.The waterfall model is mostly used for largesystems engineering projects where a system isdeveloped at several sites.zComponent analysis;Requirements modification;System design with reuse;Development and integration.This approach is becoming increasinglyused as component standards haveemerged. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 12
Reuse-oriented developmentProcess iterationzzzSystem requirements ALWAYS evolve in thecourse of a project so process iterationwhere earlier stages are reworked is alwayspart of the process for large systems.Iteration can be applied to any of the genericprocess models.Two (related) approaches Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 13Incremental delivery;Spiral development. Ian Sommerville 2006Incremental deliverySoftware Engineering, 8th edition. Chapter 4Slide 14Incremental developmentRather than deliver the system as a singledelivery, the development and delivery is brokendown into increments with each incrementdelivering part of the required functionality.User requirements are prioritised and the highestpriority requirements are included in earlyincrements.Once the development of an increment is started,the requirements are frozen though requirementsfor later increments can continue to evolve.zzz Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 15 Ian Sommerville 2006Incremental developmentadvantageszzzzSoftware Engineering, 8th edition. Chapter 4Slide 16Extreme programmingCustomer value can be delivered with eachincrement so system functionality isavailable earlier.Early increments act as a prototype to helpelicit requirements for later increments.Lower risk of overall project failure.The highest priority system services tend toreceive the most testing. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 17zzzAn approach to development based on thedevelopment and delivery of very smallincrements of functionality.Relies on constant code improvement, userinvolvement in the development team andpairwise programming.Covered in Chapter 17 Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 18
Spiral developmentzzzzSpiral model of the software processProcess is represented as a spiral ratherthan as a sequence of activities withbacktracking.Each loop in the spiral represents a phase inthe process.No fixed phases such as specification ordesign - loops in the spiral are chosendepending on what is required.Risks are explicitly assessed and resolvedthroughout the process. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 19 Ian Sommerville 2006Spiral model sectorszzzRisks are assessed and activities put in place toreduce the key risks.Development and validation zzSpecific objectives for the phase are identified.Risk assessment and reduction zzSoftware specificationSoftware design and implementationSoftware validationSoftware evolutionA development model for the system is chosenwhich can be any of the generic models.The project is reviewed and the next phase of thespiral is planned. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 21Software specificationzzPlanning zSlide 20Process activitiesObjective setting Software Engineering, 8th edition. Chapter 4 Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 22The requirements engineering processThe process of establishing what servicesare required and the constraints on thesystem’s operation and development.Requirements engineering process Feasibility study;Requirements elicitation and analysis;Requirements specification;Requirements validation. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 23 Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 24
Design process activitiesSoftware design and implementationzzThe process of converting the systemspecification into an executable system.Software design zImplementation zDesign a software structure that realises thespecification;zzzzzTranslate this structure into an executableprogram;zArchitectural designAbstract specificationInterface designComponent designData structure designAlgorithm designThe activities of design and implementationare closely related and may be inter-leaved. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 25 Ian Sommerville 2006The software design processzzSystematic approaches to developing asoftware design.The design is usually documented as a setof graphical models.Possible models Software Engineering, 8th edition. Chapter 4Slide 27Programming and debuggingzzzSlide 26Structured methodsz Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Object model;Sequence model;State transition model;Structural model;Data-flow model. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 28The debugging processTranslating a design into a program andremoving errors from that program.Programming is a personal activity - there isno generic programming process.Programmers carry out some programtesting to discover faults in the program andremove these faults in the debuggingprocess. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 29 Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 30
Software validationThe testing processVerification and validation (V & V) isintended to show that a system conforms toits specification and meets the requirementsof the system customer.Involves checking and review processes andsystem testing.System testing involves executing thesystem with test cases that are derived fromthe specification of the real data to beprocessed by the system.zzz Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 31 Ian Sommerville 2006Testing stagesSoftware Engineering, 8th edition. Chapter 4Slide 32Testing phasesComponent or unit testingz Individual components are testedindependently;Components may be functions or objects orcoherent groupings of these entities.System testingz Testing of the system as a whole. Testing ofemergent properties is particularly important.Acceptance testingz Testing with customer data to check that thesystem meets the customer’s needs. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 33 Ian Sommerville 2006Software evolutionzzzSoftware Engineering, 8th edition. Chapter 4Slide 34System evolutionSoftware is inherently flexible and canchange.As requirements change through changingbusiness circumstances, the software thatsupports the business must also evolve andchange.Although there has been a demarcationbetween development and evolution(maintenance) this is increasingly irrelevantas fewer and fewer systems are completelynew. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 35 Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 36
The Rational Unified ProcesszzRUP phase modelA modern process model derived from thework on the UML and associated process.Normally described from 3 perspectives A dynamic perspective that shows phases overtime;A static perspective that shows processactivities;A practive perspective that suggests goodpractice. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 37 Ian Sommerville 2006RUP phaseszzzzzDevelop an understanding of the problemdomain and the system architecture.zzConstruction zzEstablish the business case for the system.Elaboration Slide 38RUP good practiceInception Software Engineering, 8th edition. Chapter 4System design, programming and testing.zDevelop software iterativelyManage requirementsUse component-based architecturesVisually model softwareVerify software qualityControl changes to softwareTransition Deploy the system in its operating environment. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 39 Ian Sommerville 2006DescriptionBusiness modellingThe business processes are modelled using business use cases.RequirementsActors who interact with the system are identified and use cases aredeveloped to model the system requirements.Analysis and designA design model is created and documented using architecturalmodels, component models, object models and sequence mod els.ImplementationThe components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from designmodels helps accelerate this process.TestTesting is an iterative process that is carried out in conjunction withimplementation. System testing follows the completion of theimplementation.DeploymentA product release is created, distributed to users and installed in theirworkplace.Configuration andchange managementThis supporting workflow managed changes to the system (seeChapter 29).Project managementThis supporting workflow manages the system development (seeChapter 5).EnvironmentThis workflow is concerned with making appropriate software toolsavailable to the software development team. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 40Computer-aided softwareengineeringStatic workflowsWorkflowSoftware Engineering, 8th edition. Chapter 4zzComputer-aided software engineering (CASE) issoftware to support software development andevolution processes.Activity automation Slide 41Graphical editors for system model development;Data dictionary to manage design entities;Graphical UI builder for user interface construction;Debuggers to support program fault finding;Automated translators to generate new versions of aprogram. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 42
Case technologyCASE classificationCase technology has led to significantimprovements in the software process.However, these are not the order ofmagnitude improvements that were oncepredictedz Software engineering requires creative thought- this is not readily automated;Software engineering is a team activity and, forlarge projects, much time is spent in teaminteractions. CASE technology does not reallysupport these. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 43Functional tool classificationTool typeExamplesPlanning toolsPERT tools, estimation tools, spreadsheetsEditing toolsText editors, diagram editors, word processorsChange management toolsRequirements traceability tools, change control systemsConfiguration management toolsVersion management systems, system building toolsPrototyping toolsVery high-level languages, user interface generatorsMethod-support toolsDesign editors, data dictionaries, code generatorsLanguage-processing toolsCompilers, interpretersProgram analysis toolsCross reference generators, static analysers, dynamic analysersTesting toolsTest data generators, file comparatorsDebugging toolsInteractive debugging systemsDocumentation toolsPage layout programs, image editorsRe-engineering toolsCross-reference systems, program re-structuring systems Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 45CASE integrationz zProcess perspective zTools are classified according to their specificfunction.Tools are classified according to process activitiesthat are supported.Integration perspective Tools are classified according to their organisationinto integrated units. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 44Activity-based tool classification Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 46Tools, workbenches, environmentsSupport individual process tasks such as designconsistency checking, text editing, etc.Workbenches zzClassification helps us understand the differenttypes of CASE tools and their support for processactivities.Functional perspectiveTools zzSupport a process phase such as specificationor design, Normally include a number ofintegrated tools.Environments Support all or a substantial part of an entiresoftware process. Normally include severalintegrated workbenches. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 47 Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 48
Key pointszzzzzKey pointsSoftware processes are the activities involved inproducing and evolving a software system.Software process models are abstractrepresentations of these processes.General activities are specification, design andimplementation, validation and evolution.Generic process models describe the organisationof software processes. Examples include thewaterfall model, evolutionary development andcomponent-based software engineering.Iterative process models describe the softwareprocess as a cycle of activities. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 49zzzzzzRequirements engineering is the process ofdeveloping a software specification.Design and implementation processes transformthe specification to an executable program.Validation involves checking that the systemmeets to its specification and user needs.Evolution is concerned with modifying the systemafter it is in use.The Rational Unified Process is a generic processmodel that separates activities from phases.CASE technology supports software processactivities. Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4Slide 50
Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 7 Waterfall model phases z Requirements analysis and definition z System and software design z Implementation and unit testing z Integration and system testing z Operation and maintenance z The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway.
