1 / 34

SOFTWARE DEVELOPMENT PROCESS

310414 SOFTWARE ENGINEERING. SOFTWARE DEVELOPMENT PROCESS. 12. SOFTWARE DEVELOPMENT PROCESS OUTLINE. Overview of Software Development Processes code-and-fix waterfall prototyping fourth generation spiral phased U nified Software Development P rocess (UP) life cycle

ceiland
Télécharger la présentation

SOFTWARE DEVELOPMENT PROCESS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 310414SOFTWARE ENGINEERING SOFTWARE DEVELOPMENT PROCESS

  2. 12 SOFTWARE DEVELOPMENT PROCESS OUTLINE • Overview of Software Development Processes • code-and-fix • waterfall • prototyping • fourth generation • spiral • phased • Unified Software Development Process (UP) • life cycle • use-case and risk driven • architecture-centric • iterative and incremental

  3. Application Domain 12.1 SOFTWARE DEVELOPMENT OVERVIEW Process set of activities (workflows) template user requirements Project Product result • set of artifacts • models • code • manuals • . • . • . participate customers users software engineers . . . People

  4. WHY IS PROCESS IMPORTANT IN SOFTWARE DEVELOPMENT? • Allows division of labour • easier for each team member to know what to do • Promotes teamwork/individual work/communication • understand what others are doing (over time, among projects, etc.) • Eases project management • supervisors/managers can understand what is happening • Allows expertise reuse/reassignment • transfer among projects more easily (developers, managers, etc.) • Eases training • can be standardized (e.g., courses) • Promotes productivity/better development • development becomes repeatable (e.g., schedule/cost estimates)

  5. SOFTWARE DEVELOPMENT PROCESS A MANAGEMENT VIEW AN ENGINEERING VIEW • definition phase focus is on WHAT • project planning • requirements gathering • analysis • development phasefocus is on HOW • design – testing • coding – deployment • maintenance phasefocus is on CHANGE • bug fixes – adaptation • enhancements • plusdeliverables, reviews, change control, . . . • methods (activities) • provide technical “how to's” for building software • methodology (workflow) • sequence in which methods will be applied • deliverables required • controls needed to ensure quality and coordinate change • milestones to assess progress • tools (support) • provide automated or semi-automated support for methods

  6. CODE-AND-FIX SOFTWARE DEVELOPMENT PROCESS • process: write code, fix errors, enhance functionality • many changes code structure becomes messy, hard to fix • not suitable for large system development because: • turnover of personnel • difficult to fix code • user requirements can easily be unmatched • development becomes: • unpredictable • uncontrollable • over schedule, over budget, low quality • more structured software development process needed

  7. 12.4.1 WATERFALL SOFTWARE DEVELOPMENT PROCESS • plus: reviews (correctness, standards), deliverables (documentation, code), training material, . . . Analysis produces a requirements specification document Design produces a design specification document Coding produces an implementedcollection of modules Testing produces a testedassembly of modules Maintenance keeps the system working and up-to-date

  8. Gather Requirements & Refine Engineer Product Quick Design Refine Prototype Build Prototype Customer Evaluation of Prototype 12.4.4; 12.4.5 PROTOTYPING SOFTWARE DEVELOPMENT PROCESS Start • basically a code-and-fix process BUT ... • useful when requirements are vague or unknown • explore user interface • explore functionality needed • incremental development and delivery What to do with the final prototype? Stop

  9. FOURTH GENERATION (4G) SOFTWARE DEVELOPMENT PROCESS • 4G tools: • database query language • report generator • screen painter • charting/graphing tools • spreadsheet • application generator Requirements gathering “Design” strategy Implementation using 4G tools Testing

  10. 12.4.3 SPIRAL SOFTWARE DEVELOPMENT PROCESS Planning Risk analysis Go, no-go decision Toward a completed system Customer evaluation Engineering

  11. SPIRAL PROCESS — RISKS RISK anything that endangers or eliminates success for a project • Technical risks • – building the right system • – system architecture • – new technologies • – performance • Non-technical risks • – right expertise • – training • – schedule • – approvals • Dealing with risks • – avoid • – confine • – mitigate • – monitor GOAL: deal with biggest risks as early as possible

  12. QUESTION? The greatest risk that you have to deal with in your course project is: 1) not knowing how to work together as a team. 2) not knowing how to use Visual Basic. 3) not knowing how to use Microsoft Access. 4) falling asleep during the lecture. 5) not knowing the exact requirements for the system. 6) not having enough time to finish the project.

  13. PHASED SOFTWARE DEVELOPMENT PROCESS Build release 1 Build release 2 Build release 3 Developers Time Users Use release 1 Use release 2 Use release 3

  14. PHASED PROCESS — INCREMENTS & ITERATIONS incremental development –> partial system; full functionality iterative development –> full system; partial functionality

  15. CASE STUDY: A BUDGET CONTROL SYSTEM Problem: Build a software system for a small, high-tech software consulting and development company that monitors whether the financial transactions involved in the various software projects are proceeding according to the original budgets. • take corrective action early if not on track Scenario: The budget control activity often needs to be customized to the particular activities of an organization. While the budget control activity is related to other administrative activities, (e.g., payroll processing, income and expense monitoring, etc.), unlike these, budget control is based both on objective data, such as time and costs, and on subjective data, such as estimates of the value of the "work in progress". Since staff may be involved in several projects simultaneously, and there is no log about their contribution to each project, it is hard to assign costs to each project.

  16. CASE STUDY: A BUDGET CONTROL SYSTEM Initial findings • Real problem is not budget control per se, but understanding what it is with respect to this company. • The current administrative system is not suitable for providing the data required by budget control. • Difficulties of developing a budget control system are related to: • unusual nature of the activities of the company (not standard) • lack of standard production rules • need to re-schedule and re-budget most activities • personnel turnover • a precise statement of requirements is not possible

  17. QUESTION Which of the following software development processes, or combinations of processes, would you use to develop the Budget Control System? Why? • code-and-fix • waterfall • prototyping • fourth generation • spiral • phased

  18. SOFTWARE DEVELOPMENT PROCESS —BEST PRACTICES Incorporatingbest practices leads to good/appropriate methodologies and tools for software engineering • abstraction and generality • allows us to concentrate on important aspects and to possibly reuse software • rigor and formality • allows us to repeat what we have done and to produce better quality software • separation of concerns and modularity • allows us to divide responsibilities/work and to work on parts independently • risk assessment • allows us to deal with project threatening issues first • anticipation of change • allows us to prepare for maintenance • incremental development • allows us to evolve to the desired solution

  19. 12.4.6 UNIFIED SOFTWARE DEVELOPMENT PROCESS (UP) Selects from best practices to: • provide a generic process framework • instantiate/specialize for specific application areas, organizations, project sizes, etc. • define a set of activities (workflows) • transforms users’ requirements into a software system • define a set of models • from abstract (user-level) to concrete (code) • allow component-based development • software components interconnected via well-defined interfaces • use-case and risk driven • architecture-centric • iterative and incremental

  20. Elaboration Inception Construction Transition UNIFIED PROCESS — LIFE CYCLE Phases Core Workflows Requirements Analysis Design Implementation Testing

  21. UNIFIED PROCESS — USE-CASE DRIVEN actor:represents the users use case: a piece of functionality required by an actor use-case model: the complete system functionality (all use cases) • use-case model represents all system user functionality (functions that add value for the users) • use-case model is used to reach agreement with the customer on the system’s required functionality (it represents a contract between customer and developer) • use cases drive the development process (we transform the use case model into analysis,design and implementation models) • supports seamless traceability between models

  22. Withdraw money Deposit money Bank Customer Transfer between accounts UNIFIED PROCESS EXAMPLE — USE-CASE MODEL A bank customer uses an ATM to withdraw and deposit moneyfrom and to accounts and to transfer money between accounts. Analysis model Design model Implementation model Deployment model Use-case model Test model

  23. WHAT HOW UNIFIED PROCESS — ARCHITECTURE-CENTRIC architecture: the strategic decisions about a system that are applied consistently and pervasively throughout the system • represents the mostsignificantstatic and dynamic aspects of the system (subsystems, interfaces, dependencies, etc.) • provides different views of the system • describes the foundation of the system • key use cases (normally 5-10%) determine the architecture • use cases describe the function of the system • architecture describes the form of the system GOAL –> a stable architecture early in the development

  24. DETERMINING ARCHITECTURE Constraints & Enablers System software Middleware Legacy systems Standards & policies Non-functional requirements Distribution needs Use cases drive guides Architecture Experience • previous architecture • architecture patterns --> object broker, client/server, layers, etc. architecture baseline: a skeleton of the system with all critical parts, but with few software “muscles”

  25. Withdraw money Deposit money Bank Customer Transfer between accounts ARCHITECTURE — USE-CASE MODEL A bank customer uses an ATM to withdraw and deposit moneyfrom and to accounts and to transfer money between accounts.

  26. Withdraw money Withdrawal Account Dispenser Cashier Interface Bank Customer Bank Customer ARCHITECTURE — ANALYSIS MODEL (CLASSES)

  27. «package» ATM Interface «package» Transaction Management «package» Account Management Bank Customer ARCHITECTURE — ANALYSIS MODEL (PACKAGES)

  28. Bank Customer ARCHITECTURE — DESIGN MODEL (CLASSES) Card Reader Display Key Pad Client Manager Transaction Manager Account Manager Withdrawal Account Dispenser Feeder Cash Counter Dispenser Sensor Persistent Class

  29. «subsystem» ATM Interface «subsystem» Transaction Management «subsystem» Account Management Bank Customer ARCHITECTURE — DESIGN MODEL (SUBSYSTEMS) dispensing withdrawal transactions

  30. «executable» client.exe «file» client.c «file» dispenser.c ARCHITECTURE — IMPLEMENTATION MODEL Design Model Implementation Model Client Manager «resides» «compilation» Dispenser Feeder «resides» «compilation» Dispenser Sensor «resides» Cash Counter «resides»

  31. ATM Client internet ATM Data Server ATM Application Server Bank Customer intranet ARCHITECTURE — DEPLOYMENT MODEL

  32. UNIFIED PROCESS — ITERATIVE & INCREMENTAL iteration: a step through the workflowsincrement: growth in the product • each increment establishes a new baseline for the system • iterations/increments must be controlled to be effective • developing the system in small steps allows us to: • mitigate risks – plan better • develop a robust architecture – integrate subsystems more easily • get feedback – attain early learning • How to select what to put in an iteration? 1. use cases that extend product usability 2. highest risk use cases

  33. UNIFIED PROCESS — MILESTONES milestone: a management decision point in a project that determines whether to authorize movement to the next iteration/phase Inception phase — agreement among customers/developers on the system’s life cycle objectives Elaboration phase — agreement on the viability of the life cycle architecture, business case and project plan Construction phase — agreement on the acceptability of the software product both operationally and in terms of cost Transition phase — final agreement on the acceptability of the software product

  34. Elaboration Inception Construction Transition iter. #1 iter. #2 iter. #n-1 — — — — — major milestone UNIFIED PROCESS — LIFE CYCLE (revisited) Phases Core Workflows Requirements Analysis Design Iteration Implementation Testing iter. #n increment

More Related