BIS09 Application Development - III

1,144
-1

Published on

Course Materials for MBA course on Business Information Systems

Published in: Education, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,144
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
71
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

BIS09 Application Development - III

  1. 1. Business Information Systems Application Development III The Unified Process Prithwis Mukerjee, Ph.D.
  2. 2. Incremental Model <ul><li>Non-incremental, e.g. Waterfall, rapid prototyping models </li></ul><ul><ul><li>Operational quality complete product at end </li></ul></ul><ul><li>Incremental model </li></ul><ul><ul><li>Operational quality portion of product within weeks </li></ul></ul><ul><ul><li>Each release adds more functionality, i.e., a new increment </li></ul></ul>Requirements Release 1 Release 2 Release 3 Design Coding Test Deployment Design Coding Test Deployment Design Coding Test Deployment
  3. 3. Evolutionary Model <ul><li>Advantages </li></ul><ul><ul><li>Constant customer involvement and validation </li></ul></ul><ul><ul><li>Allows for good risk management </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Build-and-fix danger </li></ul></ul><ul><ul><li>Contradiction in terms </li></ul></ul><ul><li>New versions implement new and evolving requirements </li></ul>Feedback Version 1 Version 1 Version 1 Design Coding Test Deployment Requirements Design Coding Test Deployment Requirements Design Coding Test Deployment Requirements
  4. 4. Spiral model <ul><ul><li>Radial dimension: cumulative cost to date </li></ul></ul><ul><ul><li>Angular dimension: progress through the spiral </li></ul></ul><ul><ul><li>If all risks cannot be resolved, the project is immediately terminated </li></ul></ul>
  5. 5. What is a process ? <ul><li>A series of steps that specify the way </li></ul><ul><ul><li>Clients </li></ul></ul><ul><ul><li>Analysts </li></ul></ul><ul><ul><li>Designers </li></ul></ul><ul><ul><li>Programmers </li></ul></ul><ul><ul><li>Would work together to create a new system </li></ul></ul><ul><li>A process defines Who is doing What , When and How to reach a certain goal. </li></ul><ul><ul><li>In software engineering the goal is to build a software product or to enhance an existing one </li></ul></ul><ul><li>Various Processes exist </li></ul><ul><ul><li>SDLC Process / Waterfall Method </li></ul></ul><ul><ul><li>Unified Process / Unified Modeling Language </li></ul></ul>
  6. 6. The “Unified Process” <ul><li>Unified Process (UP) is a methodology proposed by three amigos: Booch, Jacobson, Rumbaugh </li></ul><ul><ul><li>They are also the co-developers of the Unified Modeling Language (UML). They formed a company called Rational which was bought over by IBM </li></ul></ul><ul><ul><li>Non Commercial and Free piece of knowledge </li></ul></ul><ul><li>Rational Unified Process </li></ul><ul><ul><li>The proprietory process, based on the Unified Process, along with a suite of tools that allow one to use the process effectively </li></ul></ul><ul><ul><li>Commercial Product </li></ul></ul>
  7. 7. What is UML <ul><li>Is a language. </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Applies to modeling and systems. </li></ul><ul><ul><li>Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge. </li></ul></ul><ul><li>It is the result of unifying the information systems and technology industry’s best engineering practices (principals, techniques, methods and tools). </li></ul>
  8. 8. UML – Consists of a set of Artefacts
  9. 9. Unified Process : 4 Phases <ul><li>Inception </li></ul><ul><ul><li>Business case </li></ul></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Vague estimates </li></ul></ul><ul><ul><li>Continue or stop? </li></ul></ul><ul><li>Elaboration </li></ul><ul><ul><li>Identification of most requirements </li></ul></ul><ul><ul><li>Iterative implementation of the core architecture </li></ul></ul><ul><ul><li>resolution of high risks </li></ul></ul><ul><li>Construction </li></ul><ul><ul><li>Iterative implementation of lower risk elements </li></ul></ul><ul><ul><li>Preparation for deployment </li></ul></ul><ul><li>Transition </li></ul><ul><ul><li>Beta tests </li></ul></ul><ul><ul><li>Deployment </li></ul></ul>Inception Elaboration Construction Transition time
  10. 10. Iterative and Incremental Development <ul><li>development is organized into a series of iterations </li></ul><ul><ul><li>short fixed-length mini-projects (2 to 6 weeks) </li></ul></ul><ul><ul><li>timeboxed (i.e. fixed length iterations) </li></ul></ul><ul><ul><ul><li>shift tasks to future iterations if necessary ... </li></ul></ul></ul><ul><ul><ul><li>an iteration represents a complete development cycle </li></ul></ul></ul><ul><ul><ul><ul><li>incl. requirements, </li></ul></ul></ul></ul><ul><ul><li>the outcome of each iteration: a tested, integrated and executable system </li></ul></ul>Preliminary Iteration Iter. #1 Iter. #2 Inception Elaboration Construction Transition Milestone Release Final production release
  11. 11. 1. Inception Phase <ul><li>Obtain buy-in from all interested parties </li></ul><ul><li>Capture initial requirements </li></ul><ul><li>Analyse Cost and Benefits </li></ul><ul><li>Analyse Initial Risks </li></ul><ul><li>Define Scope of Project </li></ul><ul><li>Define candidate architecture </li></ul><ul><ul><li>Language ? RDBMS ? Tiers ? </li></ul></ul><ul><li>Develop a disposable prototype </li></ul><ul><ul><li>Look and Feel of the application </li></ul></ul>
  12. 12. 2. Elaboration Phase <ul><li>Define System Requirements </li></ul><ul><ul><li>Develop USE CASE MODELS </li></ul></ul><ul><ul><ul><li>Actors </li></ul></ul></ul><ul><ul><ul><li>USE CASE </li></ul></ul></ul><ul><ul><ul><li>Scenarios </li></ul></ul></ul><ul><ul><ul><li>Use Case Diagrams </li></ul></ul></ul><ul><ul><ul><li>Use Case Descriptions </li></ul></ul></ul><ul><ul><ul><li>Develop Class diagrams </li></ul></ul></ul><ul><li>Define Glossary of terms </li></ul><ul><li>Refine Risk Assesment </li></ul><ul><li>Revised Architecture Document </li></ul>
  13. 13. 3. Construction Phase <ul><li>From paper documents to computer programs </li></ul><ul><ul><li>Cumulative increase in functionality </li></ul></ul><ul><ul><li>Increasing depth of implementation </li></ul></ul><ul><ul><ul><li>Stubs fleshed out </li></ul></ul></ul><ul><ul><ul><li>Implementation of “bells and whistles” </li></ul></ul></ul><ul><ul><li>Increasing severity of testing </li></ul></ul><ul><ul><ul><li>More and more complex test cases </li></ul></ul></ul><ul><ul><li>implement all details, not only those of central architectural value </li></ul></ul><ul><li>Analysis continues, but design and coding predominate </li></ul>
  14. 14. 4. Transition Phase <ul><li>Transfer of the system to the user community </li></ul><ul><li>Includes manufacturing, shipping, installation, training, technical support and maintenance </li></ul><ul><li>Development team begins to shrink </li></ul><ul><li>Control is moved to maintenance team </li></ul><ul><li>Alpha, Beta, and final releases </li></ul><ul><li>Software updates </li></ul><ul><li>Integration with existing systems (legacy, existing versions, etc.) </li></ul>
  15. 15. Unified Process Disciplines Management Environment Business Modeling Implementation Test Design Preliminary Iteration(s) Iter. #1 Phases Process Disciplines Iterations Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements Elaboration Transition Inception Construction Supporting Disciplines
  16. 16. Use Case Model : Actors <ul><li>Actors will interact with the system </li></ul><ul><ul><li>Input Information </li></ul></ul><ul><ul><li>Request Information </li></ul></ul><ul><ul><li>Who could be </li></ul></ul><ul><ul><ul><li>Distinct individuals </li></ul></ul></ul><ul><ul><ul><li>Same individual with multiple roles </li></ul></ul></ul><ul><ul><ul><li>Other computer systems </li></ul></ul></ul>Product Manager Salesman Production Planning System Financial System
  17. 17. Use Case Models <ul><li>Define the tasks that the Actors will pursue </li></ul><ul><ul><li>for example </li></ul></ul><ul><ul><ul><li>Define a Product </li></ul></ul></ul><ul><ul><ul><li>Define a new Customer </li></ul></ul></ul><ul><ul><ul><li>Create an Order </li></ul></ul></ul><ul><ul><ul><li>List of all Outstanding Orders </li></ul></ul></ul><ul><ul><ul><li>List of all fulfilled Orders </li></ul></ul></ul><ul><li>Create USE CASE diagram </li></ul><ul><ul><li>UML syntax </li></ul></ul><ul><ul><ul><li>Stick figures - actors </li></ul></ul></ul><ul><ul><ul><li>Ovals – use cases </li></ul></ul></ul><ul><ul><ul><li>System boundary </li></ul></ul></ul><ul><ul><ul><ul><li>No control on anything outside the system </li></ul></ul></ul></ul>Product Manager Salesman Define Customer Define Product Create Order Display Outstanding Orders Update Order
  18. 18. Use Case Diagrams <ul><li>Use Case Diagrams describe the functionality of a system and users of the system. These diagrams contain the following elements: </li></ul><ul><ul><li>Actors, which represent users of a system, including human users and other systems. </li></ul></ul><ul><ul><li>Use Cases, which represent functionality or services provided by a system to users. </li></ul></ul>
  19. 19. Scenarios <ul><li>A USE CASE could consist of a number of scenarios </li></ul><ul><ul><li>A USE CASE specifies a goal </li></ul></ul><ul><ul><ul><li>Create ORDER, Create Customer </li></ul></ul></ul><ul><ul><li>A SCENARIO represents a particular outcome when attempting to reach the goal. </li></ul></ul><ul><ul><ul><li>Create Order </li></ul></ul></ul><ul><ul><ul><ul><li>Old customer, good credit rating </li></ul></ul></ul></ul><ul><ul><ul><ul><li>New customer, no credit rating </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Old customer, bad credit rating </li></ul></ul></ul></ul><ul><ul><ul><li>The action to be followed in each case will be different </li></ul></ul></ul><ul><li>In a formal development process, each scenario would have its own documentation describing in detail all the events in the scenario </li></ul>
  20. 20. Use Case Descriptions <ul><li>Detailed Description of what the USE CASE means </li></ul><ul><ul><li>The USE CASE diagram gives the big picture but does not provide detailed description of what is happening </li></ul></ul><ul><li>Various formats are possible </li></ul><ul><ul><li>Paragraph of text </li></ul></ul><ul><ul><li>Two Column approach </li></ul></ul><ul><ul><ul><li>First column : Actor action </li></ul></ul></ul><ul><ul><ul><li>Second column : System action </li></ul></ul></ul><ul><ul><li>More complexity </li></ul></ul><ul><ul><ul><li>Pre-condition </li></ul></ul></ul><ul><ul><ul><li>Post-condition </li></ul></ul></ul><ul><ul><ul><li>Sequence of steps </li></ul></ul></ul><ul><ul><li>Activity Diagram or Flowchart </li></ul></ul><ul><ul><li>Sequence Diagram </li></ul></ul>
  21. 21. Activity Diagram Define Customer NO NO Display Order Entry Screen Does Customer exist ? Order value within credit ? Add Order Record Display Error Message
  22. 22. From Use Cases to Classes <ul><li>“Nouns” in the Use Cases are candidates for </li></ul><ul><ul><li>Classes </li></ul></ul><ul><ul><ul><li>Order, Customer </li></ul></ul></ul><ul><ul><li>Attributes </li></ul></ul><ul><ul><ul><li>Order number, customer id </li></ul></ul></ul><ul><li>“Verbs” in the Use Cases are candidates for </li></ul><ul><ul><li>Methods </li></ul></ul><ul><li>Identification of Classes, Attributes, Methods is an iterative process </li></ul><ul><li>Class Diagram is the connection between </li></ul><ul><ul><li>Object Oriented Programming techniques of the Unified Process and </li></ul></ul><ul><ul><li>Data Modelling techniques that result in Entities and Attributes in Third Normal form </li></ul></ul>
  23. 23. Class Diagrams ORDER CUSTOMER ORDER ITEM PRODUCT Receive, Update, Bill Create, Deliver Create, Update, CreditCheck, ... Create, SetPrice Mandatory, Must Have Optional, May Have N 1 N 1 N 1
  24. 24. Class Diagrams <ul><li>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. </li></ul><ul><ul><li>Classes, which represent entities with common characteristics or features. These features include attributes, operations and associations. </li></ul></ul><ul><ul><li>Associations, which represent relationships that relate two or more other classes where the relationships have common characteristics or features. These attributes and operations. </li></ul></ul>
  25. 25. Sequence Diagram Salesman :Main Screen : Order Entry Screen : Order Item Screen Order Order-Item New New Get Data New : Order Item Screen New Get Data New X New Start Challenge ID/PW X
  26. 26. Sequence Diagrams <ul><li>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: </li></ul><ul><ul><li>Class roles, which represent roles that objects may play within the interaction. </li></ul></ul><ul><ul><li>Lifelines, which represent the existence of an object over a period of time. </li></ul></ul><ul><ul><li>Activations, which represent the time during which an object is performing an operation. </li></ul></ul><ul><ul><li>Messages, which represent communication between objects. </li></ul></ul>
  27. 27. UML Diagrams Are Key System Artifacts Actor A Use Case 1 Use Case 2 Actor B Forward Engineering(Code Generation) and Reverse Engineering Executable System User Interface Definition Use Case 3 Source Code edit, compile, debug, link Use-Case Diagram Class Diagram Collaboration Diagram Sequence Diagram Component Diagram State Diagram Package Diagram Deployment Diagram Class Document FileManager GraphicFile File Repository DocumentList FileList Customer name addr withdraw() fetch() send() receive() <<entity>> Domain Expert
  28. 28. Benefits of a Use-Case Driven Process <ul><li>Use cases are concise, simple, and understandable by a wide range of stakeholders </li></ul><ul><ul><li>End users, developers and acquirers understand functional requirements of the system </li></ul></ul><ul><li>Use cases drive numerous activities in the process: </li></ul><ul><ul><li>Creation and validation of the design model </li></ul></ul><ul><ul><li>Definition of test cases and procedures of the test model </li></ul></ul><ul><ul><li>Planning of iterations </li></ul></ul><ul><ul><li>Creation of user documentation </li></ul></ul><ul><ul><li>System deployment </li></ul></ul><ul><li>Use cases help synchronize the content of different models </li></ul>
  29. 29. Summary: Unified Process <ul><li>The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of a software-intensive system </li></ul><ul><li>A software development process defines Who is doing What, When and How in building a software product </li></ul><ul><li>The Rational Unified Process has four phases: Inception, Elaboration, Construction and Transition </li></ul><ul><li>Each phase ends at a major milestone and contains one or more iterations </li></ul><ul><li>An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release </li></ul><ul><li>Rational Unified Process is a commercial version of this methodology developed by IBM / Rational </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×