310414 SOFTWARE ENGINEERING SOFTWARE DEVELOPMENT PROCESS 310414 SOFTWARE

310414 SOFTWARE ENGINEERING SOFTWARE DEVELOPMENT PROCESS 310414 SOFTWARE DEVELOPMENT 1

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

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

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

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 – – coding – deployment – provide technical “how to's” for building software maintenance phase focus is on CHANGE plus deliverables, reviews, change control, . . . 310414 methodology (workflow) – sequence in which methods will be applied – deliverables required – controls needed to ensure quality and coordinate change – milestones to assess progress testing – bug fixes – adaptation – enhancements methods (activities) tools (support) – provide automated or semiautomated support for methods SOFTWARE DEVELOPMENT 5

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 310414 SOFTWARE DEVELOPMENT 6

12. 4. 1 WATERFALL SOFTWARE DEVELOPMENT PROCESS Analysis produces a requirements specification document Design produces a design specification document Coding produces an implemented collection of modules Testing produces a tested assembly of modules Maintenance plus: reviews (correctness, standards), deliverables (documentation, code), training material, . . . 310414 keeps the system working and up-to-date SOFTWARE DEVELOPMENT 7

12. 4. 4; 12. 4. 5 PROTOTYPING SOFTWARE DEVELOPMENT PROCESS Start Stop Gather Requirements & Refine Engineer Product Quick Design Refine Prototype Build Prototype Customer Evaluation of Prototype 310414 basically a code-andfix 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? SOFTWARE DEVELOPMENT 9

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

12. 4. 3 SPIRAL SOFTWARE DEVELOPMENT PROCESS Planning Risk analysis Go, no-go decision Toward a completed system Customer evaluation 310414 Engineering SOFTWARE DEVELOPMENT 12

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

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. 310414 SOFTWARE DEVELOPMENT 14

Users Developers PHASED SOFTWARE DEVELOPMENT PROCESS 310414 Build release 1 Build release 2 Build release 3 Time Use release 1 Use release 2 Use release 3 SOFTWARE DEVELOPMENT 16

PHASED PROCESS — INCREMENTS & ITERATIONS incremental development –> partial system; full functionality iterative development –> full system; partial functionality 310414 SOFTWARE DEVELOPMENT 17

CASE STUDY: A BUDGET CONTROL SYSTEM Problem: whether Build a software system for a small, high-tech software consulting and development company that monitors 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. 310414 SOFTWARE DEVELOPMENT 19

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 310414 SOFTWARE DEVELOPMENT 20

QUESTION Which of the following software development processes, or combinations of processes, would you use to develop the Budget Control System? Why? – – – 310414 code-and-fix waterfall prototyping fourth generation spiral phased SOFTWARE DEVELOPMENT 21

SOFTWARE DEVELOPMENT PROCESS — BEST PRACTICES Incorporating best 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 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 â allows us to divide responsibilities/work and to work on parts independently 310414 SOFTWARE DEVELOPMENT 22

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) define a set of models allow component-based development è transforms users’ requirements into a software system è from abstract (user-level) to concrete (code) è software components interconnected via well-defined interfaces è use-case and risk driven è architecture-centric è iterative and incremental 310414 SOFTWARE DEVELOPMENT 23

UNIFIED PROCESS — LIFE CYCLE Core Workflows Phases Inception Elaboration Construction Transition Requirements Analysis Design Implementation Testing 310414 SOFTWARE DEVELOPMENT 24

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 310414 SOFTWARE DEVELOPMENT 27

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

UNIFIED PROCESS — ARCHITECTURE-CENTRIC architecture: applied the strategic decisions about a system that are consistently and pervasively throughout the system represents the most significant static 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 WHAT è architecture describes the form of the system HOW GOAL –> a stable architecture early in the development 310414 SOFTWARE DEVELOPMENT 29

DETERMINING ARCHITECTURE Use cases drive guides Architecture Constraints & Enablers System software Middleware Legacy systems Standards & policies Non-functional requirements Experience Distribution needs • 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” 310414 SOFTWARE DEVELOPMENT 30

ARCHITECTURE — USE-CASE MODEL A bank customer uses an ATM to withdraw and deposit money from and to accounts and to transfer money between accounts. Withdraw money Bank Customer Deposit money Transfer between accounts 310414 SOFTWARE DEVELOPMENT 31

ARCHITECTURE — ANALYSIS MODEL (CLASSES) Bank Customer Withdraw money Dispenser Bank Customer Withdrawal Account Cashier Interface 310414 SOFTWARE DEVELOPMENT 32

ARCHITECTURE — ANALYSIS MODEL (PACKAGES) «package» Bank Customer 310414 ATM Interface «package» Account Management Transaction Management SOFTWARE DEVELOPMENT 33

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

ARCHITECTURE — DESIGN MODEL (SUBSYSTEMS) «subsystem» ATM Interface Bank Customer dispensing «subsystem» Account Management Transaction Management withdrawal transactions 310414 SOFTWARE DEVELOPMENT 35

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

ARCHITECTURE — DEPLOYMENT MODEL ATM Client Bank Customer internet ATM Data Server 310414 intranet ATM Application Server SOFTWARE DEVELOPMENT 37

UNIFIED PROCESS — ITERATIVE & INCREMENTAL iteration: a step through the workflows increment: 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 – develop a robust architecture – get feedback – plan better – integrate subsystems more easily – attain early learning è How to select what to put in an iteration? 1. use cases that extend product usability 2. highest risk use cases 310414 SOFTWARE DEVELOPMENT 38

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 310414 SOFTWARE DEVELOPMENT 39

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