BIS 08a - Application Development - II Version 2


Published on

Application Development Process. Part of the slide deck that accompanies my text book, Business Information Systems

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The UML provides a single, common modeling language that is useable across many methods, across the entire lifecycle, and across many different implementation technologies. It maps the artifacts between business engineering, requirements capture and analysis, design, implementation, and test. It defines an expressive and consistent notation that can point out omissions and inconsistencies. It scales to support very small to very large systems development. If facilitates effective communications with all members of the development team. We are beginning the transition from the UML to the RUP. The students are not expected to be able to read this slide. The point is just to summarize all of the UML diagrams used for visual modeling. You might point out that learning the UML and all of its diagrams is not enough for a developer to be successful. It is similar to learning a natural language like English by reading the dictionary. You might know all the words and even the syntax, but you wouldn’t be able to effectively communicate. So the UML is a crucial first step as it gives us a common language with which to communicate. But a process is needed to understand how to apply the UML to ensure successful development efforts. That’s why we developed the RUP. Activity diagrams are not shown on the slide. Activity diagrams can be used to model workflows in business process engineering.
  • The important point to get across is that use cases permeate all parts of RUP and are a key mechanism in accomplishing the Managing Requirements best practice.
  • BIS 08a - Application Development - II Version 2

    1. 1. Business Information SystemsApplication Development IIThe Development Process Prithwis Mukerjee, Ph.D.
    2. 2. Building Software Software Development Life Cycle Iterative Software Development The Unified Process Prithwis Mukerjee 2
    3. 3. What is a process ? A series of steps that specify the way  Clients  Analysts  Designers  Programmers  Would work together to create a new system A process defines Who is doing What, When and How to reach a certain goal.  In software engineering the goal is to build a software product or to enhance an existing one Various Processes exist  SDLC Process / Waterfall Method  Unified Process / Unified Modeling Language Prithwis Mukerjee 3
    4. 4. System Development Life CycleMethodologyComponent Functional Technical Estimate Develop Deliver Test Support Design Design Communication & Coordination (all teams) Functional Functional Support USER Driven Specification Specification Test  Client Sign Off  Client  Client Review Review Code Code Bundle // Bundle Demo Demo Technical   Code Review Review Complexity Complexity Unit Test Unit Test Unit Test Unit Test Program Program Pre- Pre- Support Programmer Driven Determination Determination Plan Plan Results Results Review Review Production Production (optional) // Estimate Estimate Checklist Checklist Support Support Technical Program Legend Technical Program Specification Specification Source Code Source Code Task With Deliverable  Technical Task Without Deliverable Design Optional Service Area Walkthrough Prithwis  Process Checkpoint Mukerjee 4
    5. 5. The WaterFall Method – A simplified view Analysis Users define what they want from the system Programmers re-define what they Design believe the users want in a more structured manner Actual program is built using an appropriate computer Codinglanguage like C, Java, VisualBasic Application is tested and then Test / Deploy deployed in the end users machine Prithwis Mukerjee 5
    6. 6. The WaterFall Method – Deliverables Analysis Requirements Analysis Document written in simple English language Systems Specifications written in Design terms of e.g. TABLES, COLUMNS, METHODS, FUNCTIONS Programs written in an appropriate language and tested individually. CodingUnit Test Report for each program All programs tested together to ensure compatibility and consistency Test / Deploy Integration Test Report Prithwis Mukerjee 6
    7. 7. Waterfall Process Assumptions Requirements are known up front before design  In reality, users do not know what they want  They certainly cannot visualise what the final thing will look like Requirements rarely change  They always will, however much you hate it Design can be conducted in a purely abstract space, or trial rarely leads to error The technology will all fit nicely into place when the time comes (the apocalypse) Prithwis Mukerjee 7
    8. 8. Waterfall Process Limitations Big Bang Delivery Theory The proof of the concept is relegated to the very end of a long singular cycle. Before final integration, only documents have been produced. Late deployment hides many lurking risks:  technological (well, I thought they would work together...)  conceptual (well, I thought thats what they wanted...)  personnel (took so long, half the team left)  User doesnt get to see anything real until the very end, and they always hate it.  System Testing doesnt get involved until later in the process. Prithwis Mukerjee 8
    9. 9. What did the customer really want ? Prithwis Mukerjee 9
    10. 10. An Iterative Development Process... Recognizes the reality of changing requirements  Caspers Jones’s research on 8000 projects  40% of final requirements arrived after the analysis phase, after development had already begun Promotes early risk mitigation, by breaking down the system into mini-projects and focusing on the riskier elements first  Allows you to “plan a little, design a little, and code a little” Encourages all participants, including testers, integrators to be involved earlier on  Allows the process itself to modulate with each iteration, allowing you to correct errors sooner and put into practice lessons learned in the prior iteration Focuses on component architectures, not final big bang 10 Prithwis Mukerjee
    11. 11. An Incremental Development Process... Allows for software to evolve, not be produced in one huge effort  Allows software to improve, by giving enough time to the evolutionary process itself Forces attention on stability, for only a stable foundation can support multiple additions  Allows the system (a small subset of it) to actually run much sooner than with other processes Allows interim progress to continue through the stubbing of functionality Allows for the management of risk, by exposing problems earlier on in the development process Prithwis Mukerjee 11
    12. 12. Goals and Features of Each Iteration The primary goal of each iteration is to slowly chip away at the risk facing the project, namely:  performance risks  integration risks (different vendors, tools, etc.)  conceptual risks (ferret out analysis and design flaws) Perform a “mini-waterfall” project that ends with a delivery of something tangible in code, available for scrutiny by the interested parties, which produces validation or correctives  The result of a single iteration is an increment--an incremental improvement of the system, yielding an evolutionary approach Prithwis Mukerjee 12
    13. 13. Incremental Model Release 1 Design Coding Test Deployment Requirements Release 2 Design Coding Test Deployment Release 3 Design Coding Test Deployment Non-incremental, e.g. Waterfall, rapid prototyping models  Operational quality complete product at end Incremental model  Operational quality portion of product within weeks  Each release adds more functionality, i.e., a new increment Prithwis Mukerjee 13
    14. 14. Evolutionary ModelVersion 1Requirements Design Coding Test Deployment Version 1 Requirements Design Coding Test Deployment Version 1 Feedback Requirements Design Coding Test Deployment Advantages  Constant customer involvement and validation  Allows for good risk management Disadvantages  Build-and-fix danger  Contradiction in terms New Mukerjee versions implement new and evolving requirements14 Prithwis
    15. 15. Spiral model Determine objectives Evaluate alternatives alternatives and identify, resolve risks constraints Risk analysis Risk analysis Risk analysis Opera- Prototype 3 tional Prototype 2 protoype Risk REVIEW anal sis Proto- y type 1 Requirements plan Simulations, models, benchmarks Life-cycle plan Concept of Operation S/W requirements Product design Detailed Requirem ent design Development plan validation Code Design Unit test Integration and test plan V&V Integration Plan next phase test Acceptance Service test Develop, verify next-level productRadial dimension: cumulative cost to dateAngular dimension: progress through the spiralIf all risks cannot be resolved, the project is immediately terminated Prithwis Mukerjee 15
    16. 16. The “Unified Process” Unified Process (UP) is a methodology proposed by three amigos: Booch, Jacobson, Rumbaugh  They are also the co-developers of the Unified Modeling Language (UML). They formed a company called Rational which was bought over by IBM  Non Commercial and Free piece of knowledge Rational Unified Process  The proprietory process, based on the Unified Process, along with a suite of tools that allow one to use the process effectively  Commercial Product Prithwis Mukerjee 16
    17. 17. What is UML Is a language.  It is not simply a notation for drawing diagrams, but a complete language for capturing knowledge(semantics) about a subject and expressing knowledge(syntax) regarding the subject for the purpose of communication. Applies to modeling and systems.  Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge. It is the result of unifying the information systems and technology industry’s best engineering practices (principals, techniques, methods and tools). Prithwis Mukerjee 17
    18. 18. UML – Consists of a set of Artefacts S St a at e e tt tte DDi ai agSgSCraaalaamse s r t mt s UUs se e CCa as se e DDi ai ag gr ral amm s s C as DDi ai ag gr ra amm s s DDUaiUUgsgsreraeCmC assassese e i a e aCm s a S St a at e e t t e UU s se e CC a as se e DD i aiUagsgrera ammas ss e C DDi ai agSgOtraabatjmee cs t S t mt s r DDUaiUagsgrec Ctmimassissteye i s Ae ra aCav DD i ai ag gr ra amm s s DDi ai agO rab ame c st ggrar jamm ss DDi ai aA grc rataimvmistsy g DDi ai a g r a m s DDi ai ag gr ra amm s s S Sc ce en na ar ri o o S St a at e e SaSc cer ea nm arisri o o DDi i Sg g qnauame nsi c e S tStaatat e e DDi ai ag gr Sr tatmam tse t DDaSi eagrgq rauamem n sc e ia e r s r m ts s DDi ai ag gS rataa m e s DD i ai ag gr ra amm s s M odel DDi ai ag gr ra amm s s S Sc ce en na ar ri o oi C Co ommp po on ne en nt t DDiSaioaclcleraerabnmoar sri so ot i o n S g g na am r a DCiCaoi aomgmar am mnsne en nt t po CD ioa lgl ar b m risa t i o n DDe ep pl o oy ymm e en nt t CC ogi ommrppaopm sosn ne en nt t D D ar g o CD i a g ra ao m s l D ia g r a m s DDi ai ag gr ra amm s s DDi ai ag gr ra amm DDi ai ag gr ra amm s s Prithwis Mukerjee 18
    19. 19. Unified Process : 4 Phases Inception Construction  Business case  Iterative implementation of  Scope lower risk elements  Vague estimates  Preparation for deployment  Continue or stop? Transition Elaboration  Beta tests  Identification of most  Deployment requirements  Iterative implementation of the core architecture  resolution of high risks Inception Elaboration Construction Transition time Prithwis Mukerjee 19
    20. 20. Iterative and Incremental Development development is organized into a series of iterations  short fixed-length mini-projects (2 to 6 weeks)  timeboxed (i.e. fixed length iterations)  shift tasks to future iterations if necessary ...  an iteration represents a complete development cycle  incl. requirements,  the outcome of each iteration: a tested, integrated and executable system Inception Elaboration Construction Transition Preliminary Iter. #1 Iter. #2 Iteration Milestone Release Final production Prithwis release Mukerjee 20
    21. 21. 1. Inception Phase Obtain buy-in from all interested parties Capture initial requirements Analyse Cost and Benefits Analyse Initial Risks Define Scope of Project Define candidate architecture  Language ? RDBMS ? Tiers ? Develop a disposable prototype  Look and Feel of the application Prithwis Mukerjee 21
    22. 22. 2. Elaboration Phase Define System Requirements  Develop USE CASE MODELS  Actors  USE CASE  Scenarios  Use Case Diagrams  Use Case Descriptions  Develop Class diagrams Define Glossary of terms Refine Risk Assesment Revised Architecture Document Prithwis Mukerjee 22
    23. 23. 3. Construction Phase From paper documents to computer programs  Cumulative increase in functionality  Increasing depth of implementation  Stubs fleshed out  Implementation of “bells and whistles”   Increasing severity of testing  More and more complex test cases  implement all details, not only those of central architectural value Analysis continues, but design and coding predominate Prithwis Mukerjee 23
    24. 24. 4. Transition Phase Transfer of the system to the user community Includes manufacturing, shipping, installation, training, technical support and maintenance Development team begins to shrink Control is moved to maintenance team Alpha, Beta, and final releases Software updates Integration with existing systems (legacy, existing versions, etc.) Prithwis Mukerjee 24
    25. 25. Unified Process Disciplines PhasesProcess Disciplines Inception Elaboration Construction Transition Business Modeling Requirements Design Implementation Test DeploymentSupporting Disciplines Configuration Mgmt Management Environment Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iterations Prithwis Mukerjee 25
    26. 26. Use Case Model : Actors Actors will interact with the system Product  Input Information Manager  Request Information  Who could be  Distinct individuals  Same individual with Salesman multiple roles  Other computer systems Production Planning System Financial Prithwis System Mukerjee 26
    27. 27. Use Case Models Define the tasks that the Actors will pursue Define Product Product  for example Manager  Define a Product  Define a new Customer Define Customer  Create an Order  List of all Outstanding Orders Salesman  List of all fulfilled Orders Create Order Create USE CASE diagram  UML syntax  Stick figures - actors Update Order  Ovals – use cases  System boundary  No control on anything Display Prithwis outside the system Outstanding Mukerjee Orders 27
    28. 28. Use Case Diagrams Use Case Diagrams describe the functionality of a system and users of the system. These diagrams contain the following elements:  Actors, which represent users of a system, including human users and other systems.  Use Cases, which represent functionality or services provided by a system to users. Prithwis Mukerjee 28
    29. 29. Scenarios A USE CASE could consist of a number of scenarios  A USE CASE specifies a goal  Create ORDER, Create Customer  A SCENARIO represents a particular outcome when attempting to reach the goal.  Create Order  Old customer, good credit rating  New customer, no credit rating  Old customer, bad credit rating  The action to be followed in each case will be different In a formal development process, each scenario would have its own documentation describing in detail all the events in the scenario Prithwis Mukerjee 29
    30. 30. Use Case Descriptions Detailed Description of what the USE CASE means  The USE CASE diagram gives the big picture but does not provide detailed description of what is happening Various formats are possible  Paragraph of text  Two Column approach  First column : Actor action  Second column : System action  More complexity  Pre-condition  Post-condition  Sequence of steps  Activity Diagram or Flowchart  Sequence Diagram Prithwis Mukerjee 30
    31. 31. Activity Diagram Display Order Entry Screen Does NO Customer exist ? Define Customer Order value NO Display within Error Message credit ? Add Order Prithwis Record Mukerjee 31
    32. 32. From Use Cases to Classes “Nouns” in the Use Cases Class Diagram is the are candidates for connection between  Classes  Object Oriented  Order, Customer Programming techniques of  Attributes the Unified Process and  Order number, customer id  Data Modelling techniques that result in Entities and “Verbs” in the Use Cases Attributes in Third Normal are candidates for form  Methods Identification of Classes, Attributes, Methods is an iterative process Prithwis Mukerjee 32
    33. 33. Class Diagrams ORDER CUSTOMER Order ID N 1 Customer ID Order Date Customer Name Customer ID Customer Address Order Value Customer Credit Limit Receive, Update, Bill 1 Create, Update, CreditCheck, ... ORDER ITEM N PRODUCT Order ID Product ID Item ID Product Desc Product ID N 1 Product unit price Item quantity Create, SetPrice Item Deliver Date Create, Deliver Optional, May Have Prithwis Mandatory, Must Have Mukerjee 33
    34. 34. Class Diagrams Class Diagrams describe the static structure of a system, or how it is structured rather than how it behaves. These diagrams contain the following elements.  Classes, which represent entities with common characteristics or features. These features include attributes, operations and associations.  Associations, which represent relationships that relate two or more other classes where the relationships have common characteristics or features. These attributes and operations. Prithwis Mukerjee 34
    35. 35. Sequence Diagram :MainSalesman Screen Start Challenge : Order Entry Screen ID/PW New Order Order-Item New : Order Item Screen New Get Data New : Order Item Screen New Get Data New X Prithwis X Mukerjee 35
    36. 36. Sequence Diagrams Sequence Diagrams describe interactions among classes. These diagrams focus on classes and the messages they exchange to accomplish some desired behavior. Sequence diagrams contain the following elements:  Class roles, which represent roles that objects may play within the interaction.  Lifelines, which represent the existence of an object over a period of time.  Activations, which represent the time during which an object is performing an operation.  Messages, which represent communication between objects. Prithwis Mukerjee 36
    37. 37. UML Diagrams Are Key System Artifacts Use-Case Class Diagram State Diagram Diagram add file D o c u m e n t L is t F il e M g r Do cu m e nt add( ) n am e : in t fe tc h D o c ( ) d e lete( ) d o c id : i n t s o rt B y N am e ( ) n u m F ield : in t Writing add file [ numberOffile==MAX ] / g e t( ) flag OFF open( ) r e a d () f il l t h e c lo s e ( ) c o d e .. F i le L is t re ad ( ) Openning Use Case 1 s o r t F il e L is t ( ) f Lis t c re a t e ( ) f ill D o c u m e n t ( ) ad d ( ) d e le t e ( ) 1 close file Actor A Actor B close file Closing Reading Use Case 2 re p <<entity>> F il e R e p o s it o r y ( f r o m P e r s is t e n c e ) rea d ( ) G r p F i le Customer name na m e : ch ar * = 0 re a d ( ) Deployment addr re a d D o c ( ) Domain op en ( ) re a d F il e ( ) c r e a te ( ) receive() f il lF il e ( ) Use Case 3 withdraw() fetch() Expert send() Diagram Class UI MF C DocumentApp ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸· ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ ¨ ­ À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® ­ À©µµ¿ì NT: ÀÀ¿ë¼­¹ö ­ À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼­¹ö ¹× µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö ­ IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö RogueWave Repository DocumentList Windows 95 Window95 9: sortByName ( ) Persistence Windows95 global FileManager ¹®¼­°ü¸® Ŭ¶óÀ̾ðÆ®.EXE ¹®¼­° ü¸® ¾ÖÇø´ mainWnd : MainWnd Windows Package NT 1: Doc view request ( ) Document L Solaris 2: fetchDoc( ) ¹®¼­°ü¸® ¿£Áø.EXE 4: create ( ) gFile : GrpFile Alpha Diagram 8: fillFile ( ) UNIX ÀÀ¿ë¼­¹ö.EXE Windows NT user : »ç¿ëÀÚ GraphicFileUser Interface IBM fileMgr : FileMgr File Mainframe 3: create ( ) FileList 6: fillDocument ( )Definition µ¥ÀÌŸº£À̽º¼­¹ö 7: readFile ( ) 5: readDoc ( ) document : Document repository : Repository Forward Engineering(Code Generation) Collaboration Diagram Component and Diagram Reverse Engineering mainWnd fileMgr : document : gFile repository user FileMgr Document Source Code edit, compile, debug, link ƯÁ¤¹®¼ ´ëÇÑ º¸±â¸¦ ­¿¡ 1: D view request ( ) oc »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù. 2: fetchDoc( ) 3: create ( ) 4: creat e ( ) 5: readDoc ( ) È­ÀÏ°ü¸®ÀÚ´Â ÀÐ ¾î¿Â 6: fillDocument ( ) ¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­ °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù. 7: readFile ( ) 8: fillFile ( ) È­¸é °´Ã¼´Â ÀоîµéÀÎ 9: sortByName ( ) ° ´Ã¼µ ´ëÇØ À̸§º°·Î é¿¡ Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡ º¸¿©ÁØ´Ù. Sequence Diagram Executable System 37
    38. 38. Benefits of a Use-Case Driven Process Use cases are concise, simple, and understandable by a wide range of stakeholders  End users, developers and acquirers understand functional requirements of the system Use cases drive numerous activities in the process:  Creation and validation of the design model  Definition of test cases and procedures of the test model  Planning of iterations  Creation of user documentation  System deployment Use cases help synchronize the content of different models 38
    39. 39. Summary: Unified Process The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of a software-intensive system A software development process defines Who is doing What, When and How in building a software product The Rational Unified Process has four phases: Inception, Elaboration, Construction and Transition Each phase ends at a major milestone and contains one or more iterations An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release Rational Unified Process is a commercial version of 39