Software engineering 1

907 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
907
On SlideShare
0
From Embeds
0
Number of Embeds
356
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Software engineering 1

  1. 1. 1What is software?• Computer programs and associateddocumentation• Software products may be developed for aparticular customer or may be developed fora general market• Software products may be– Generic - developed to be sold to a range ofdifferent customers– Bespoke (custom) - developed for a singlecustomer according to their specification
  2. 2. 2What is software engineering?• Software engineering is an engineeringdiscipline which is concerned with all aspectsof software production• Software engineers should adopt asystematic and organised approach to theirwork and use appropriate tools andtechniques depending on the problem to besolved, the development constraints and theresources available
  3. 3. 3What is a software process?• A set of activities whose goal is thedevelopment or evolution of software• Generic activities in all software processesare:– Specification - what the system should do and itsdevelopment constraints– Development - production of the software system– Validation - checking that the software is what thecustomer wants– Evolution - changing the software in response tochanging demands
  4. 4. 4What is a software processmodel?• A simplified representation of a software process, presentedfrom a specific perspective• Examples of process perspectives are– Workflow perspective - sequence of activities– Data-flow perspective - information flow– Role/action perspective - who does what• Generic process models– Waterfall– Evolutionary development– Formal transformation– Integration from reusable components
  5. 5. 5What are softwareengineering methods?• Structured approaches to software developmentwhich include system models, notations, rules,design advice and process guidance• Model descriptions– Descriptions of graphical models which should beproduced• Rules– Constraints applied to system models• Recommendations– Advice on good design practice• Process guidance– What activities to follow
  6. 6. 6What are the attributes of goodsoftware?• The software should deliver the required functionality andperformance to the user and should be maintainable,dependable and usable• Maintainability– Software must evolve to meet changing needs• Dependability– Software must be trustworthy• Efficiency– Software should not make wasteful use of system resources• Usability– Software must be usable by the users for which it wasdesigned
  7. 7. 7What are the key challenges facingsoftware engineering?• Coping with legacy systems, coping with increasingdiversity and coping with demands for reduceddelivery times• Legacy systems– Old, valuable systems must be maintained andupdated• Heterogeneity– Systems are distributed and include a mix ofhardware and software• Delivery– There is increasing pressure for faster delivery ofsoftware
  8. 8. 8The software process• A structured set of activities required todevelop asoftware system– Specification– Design– Validation– Evolution• A software process model is an abstractrepresentation of a process. It presents adescription of a process from some particularperspective
  9. 9. 9Generic software processmodels• The waterfall model– Separate and distinct phases of specification anddevelopment• Evolutionary development– Specification and development are interleaved• Formal systems development– A mathematical system model is formallytransformed to an implementation• Reuse-based development– The system is assembled from existingcomponents
  10. 10. 10Waterfall modelRequirementsdefinitionSystem andsoftware designImplementationand unit testingIntegration andsystem testingOperation andmaintenance
  11. 11. 11Waterfall model phases• Requirements analysis and definition• System and software design• Implementation and unit testing• Integration and system testing• Operation and maintenance• The drawback of the waterfall model isthe difficulty of accommodating changeafter the process is underway
  12. 12. 12Waterfall model problems• Inflexible partitioning of the project intodistinct stages• This makes it difficult to respond tochanging customer requirements• Therefore, this model is onlyappropriate when the requirements arewell-understood
  13. 13. 13Evolutionary development• Exploratory development– Objective is to work with customers and toevolve a final system from an initial outlinespecification. Should start with well-understood requirements• Throw-away prototyping– Objective is to understand the systemrequirements. Should start with poorlyunderstood requirements
  14. 14. 14Evolutionary developmentValidationFinalversionDevelopmentIntermediateversionsSpecificationInitialversionOutlinedescriptionConcurrentactivities
  15. 15. 15Evolutionary development• Problems– Lack of process visibility– Systems are often poorly structured– Special skills (e.G. In languages for rapidprototyping) may be required• Applicability– For small or medium-size interactive systems– For parts of large systems (e.G. The userinterface)– For short-lifetime systems
  16. 16. 16Formal systems development• Based on the transformation of amathematical specification through differentrepresentations to an executable program• Transformations are ‘correctness-preserving’so it is straightforward to show that theprogram conforms to its specification• Embodied in the ‘Cleanroom’ approach tosoftware development
  17. 17. 17Use of formal methods• Formal methods have limited practicalapplicability• Their principal benefits are in reducingthe number of errors in systems so theirmain area of applicability is criticalsystems• In this area, the use of formal methodsis most likely to be cost-effective
  18. 18. 18Formal systems developmentRequirementsdefinitionFormalspecificationFormaltransformationIntegration andsystem testing
  19. 19. 19Use of formal specification• Formal specification involves investing moreeffort in the early phases of softwaredevelopment• This reduces requirements errors as it forcesa detailed analysis of the requirements• Incompleteness and inconsistencies can bediscovered and resolved• Hence, savings as made as the amount ofrework due to requirements problems isreduced
  20. 20. 20List specificationHead (Create) = Undefined exception (emptylist)Head (Cons (L, v)) = if L = Create then v else Head (L)Length (Create) = 0Length (Cons (L, v)) = Length (L) + 1Tail (Create ) = CreateTail (Cons (L, v)) = if L = Create then Create else Cons (Tail (L), v)sort Listimports INTEGERDefines a list where elements are added at the end and remo vedfrom the front.The oper ations are Create, which brings an emptylistinto existence, Cons, which creates a newlist with an added member ,Length, which evaluates the list size, Head, which evaluates the frontelement of the list, and Tail, which creates a list byremoving the head from itsinput list. Undefined represents an undefined value of type Elem.Create → ListCons (List, Elem) → ListHead (List) → ElemLength (List) → IntegerTail (List) → ListLIST ( Elem )
  21. 21. 21Formal transformationsR2FormalspecificationR3ExecutableprogramP2 P3 P4T1 T2 T3 T4Proofs of transformation correctnessFormal transformationsR1P1
  22. 22. 22Formal systems development• Problems– Need for specialised skills and training toapply the technique– Difficult to formally specify some aspects ofthe system such as the user interface• Applicability– Critical systems especially those where asafety or security case must be madebefore the system is put into operation
  23. 23. 23Reuse-oriented development• Based on systematic reuse where systemsare integrated from existing components orCOTS (Commercial-off-the-shelf) systems• Process stages– Component analysis– Requirements modification– System design with reuse– Development and integration• This approach is becoming more importantbut still limited experience with it
  24. 24. 24Reuse-oriented developmentRequirementsspecificationComponentanalysisDevelopmentand integrationSystem designwith reuseRequirementsmodificationSystemvalidation
  25. 25. 25Process iteration• System requirements ALWAYS evolve in thecourse of a project so process iteration whereearlier stages are reworked is always part ofthe process for large systems• Iteration can be applied to any of the genericprocess models• Two (related) approaches– Incremental development– Spiral development
  26. 26. 26Incremental development• Rather than deliver the system as a singledelivery, the development and delivery isbroken down into increments with eachincrement delivering part of the requiredfunctionality• User requirements are prioritised and thehighest priority requirements are included inearly increments• Once the development of an increment isstarted, the requirements are frozen thoughrequirements for later increments cancontinue to evolve
  27. 27. 27Incremental developmentValidateincrementDevelop systemincrementDesign systemarchitectureIntegrateincrementValidatesystemDefine outlinerequirementsAssign requirementsto incrementsSystem incompleteFinalsystem
  28. 28. 28Incremental developmentadvantages• Customer value can be delivered with eachincrement so system functionality is availableearlier• 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
  29. 29. 29Extreme programming• New approach to development basedon the development and delivery of verysmall increments of functionality• Relies on constant code improvement,user involvement in the developmentteam and pairwise programming
  30. 30. 30Spiral development• Process is represented as a spiral rather thanas a sequence of activities with backtracking.• 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.
  31. 31. 31Spiral model of the softwareprocessRiskanalysisRiskanalysisRiskanalysisRiskanalysis Proto-type 1Prototype 2Prototype 3Opera-tionalprotoypeConcept ofOperationSimulations, models, benchmarksS/WrequirementsRequirementvalidationDesignV&VProductdesign DetaileddesignCodeUnit testIntegrationtestAcceptancetestService Develop, verifynext-level productEvaluate alternativesidentify, resolve risksDetermine objectivesalternatives andconstraintsPlan next phaseIntegrationand test planDevelopmentplanRequirements planLife-cycle planREVIEW
  32. 32. 32Spiral model sectors• Objective setting– Specific objectives for the phase are identified• Risk assessment and reduction– Risks are assessed and activities put in place toreduce the key risks• Development and validation– A development model for the system is chosenwhich can be any of the generic models• Planning– The project is reviewed and the next phase of thespiral is planned
  33. 33. 33Software specification• The process of establishing what services arerequired and the constraints on the system’soperation and development• Requirements engineering process– Feasibility study– Requirements elicitation and analysis– Requirements specification– Requirements validation
  34. 34. 34The requirements engineeringprocessFeasibilitystudyRequirementselicitation andanalysisRequirementsspecificationRequirementsvalidationFeasibilityreportSystemmodelsUser and systemrequirementsRequirementsdocument
  35. 35. 35Design process activities• Architectural design• Abstract specification• Interface design• Component design• Data structure design• Algorithm design
  36. 36. 36The software design processArchitecturaldesignAbstractspecificationInterfacedesignComponentdesignDatastructuredesignAlgorithmdesignSystemarchitectureSoftwarespecificationInterfacespecificationComponentspecificationDatastructurespecificationAlgorithmspecificationRequirementsspecificationDesign activitiesDesign products
  37. 37. 37Design methods• Systematic approaches to developing asoftware design• The design is usually documented as a set ofgraphical models• Possible models– Data-flow model– Entity-relation-attribute model– Structural model– Object models
  38. 38. 38Programming and debugging• Translating a design into a program andremoving errors from that program• Programming is a personal activity - there isno generic programming process• Programmers carry out some program testingto discover faults in the program and removethese faults in the debugging process
  39. 39. 39The debugging processLocateerrorDesignerror repairRepairerrorRe-testprogram
  40. 40. 40Software validation• Verification and validation is intended to showthat a system conforms to its specificationand meets the requirements of the systemcustomer• Involves checking and review processes andsystem testing• System testing involves executing the systemwith test cases that are derived from thespecification of the real data to be processedby the system
  41. 41. 41The testing processSub-systemtestingModuletestingUnittestingSystemtestingAcceptancetestingComponenttestingIntegration testing Usertesting
  42. 42. 42Testing stages• Unit testing– Individual components are tested• Module testing– Related collections of dependent components aretested• Sub-system testing– Modules are integrated into sub-systems andtested. The focus here should be on interfacetesting• System testing– Testing of the system as a whole. Testing ofemergent properties• Acceptance testing
  43. 43. 43Testing phasesRequirementsspecificationSystemspecificationSystemdesignDetaileddesignModule andunit codeand tessSub-systemintegrationtest planSystemintegrationtest planAcceptancetest planServiceAcceptancetestSystemintegration testSub-systemintegration test
  44. 44. 44Software evolution• Software 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
  45. 45. 45System evolutionAssess existingsystemsDefine systemrequirementsPropose systemchangesModifysystemsNewsystemExistingsystems
  46. 46. 46Automated process support(CASE)• Computer-aided software engineering(CASE) is software to support softwaredevelopment and evolution processes• Activity automation– Graphical 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 ofa program
  47. 47. 47Case technology• Case technology has led to significantimprovements in the software process thoughnot the order of magnitude improvements thatwere once predicted– Software engineering requires creative thought -this is not readily automatable– Software engineering is a team activity and, forlarge projects, much time is spent in teaminteractions. CASE technology does not reallysupport these
  48. 48. 48CASE classification• Classification helps us understand thedifferent types of CASE tools and theirsupport for process activities• Functional perspective– Tools are classified according to their specificfunction• Process perspective– Tools are classified according to process activitiesthat are supported• Integration perspective– Tools are classified according to their organisationinto integrated units
  49. 49. 49Functional tool classification
  50. 50. 50Reengineering toolsTesting toolsDebugging toolsProgram analysis toolsLanguage-processingtoolsMethod support toolsPrototyping toolsConfigurationmanagement toolsChange management toolsDocumentation toolsEditing toolsPlanning toolsSpecification Design Implementation VerificationandValidationActivity-based classification
  51. 51. 51CASE integration• Tools– Support individual process tasks such as designconsistency checking, text editing, etc.• Workbenches– Support a process phase such as specification ordesign, Normally include a number of integratedtools• Environments– Support all or a substantial part of an entiresoftware process. Normally include severalintegrated workbenches
  52. 52. 52Tools, workbenches,environmentsSingle-methodworkbenchesGeneral-purposeworkbenchesMulti-methodworkbenchesLanguage-specificworkbenchesProgramming TestingAnalysis anddesignIntegratedenvironmentsProcess-centredenvironmentsFilecomparatorsCompilersEditorsEnvironmentsWorkbenchesToolsCASEtechnology

×