16 si(systems analysis and design )


Published on

Kumpulan Materi Kuliah TI

Published in: Technology
1 Like
  • Be the first to comment

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

No notes for slide

16 si(systems analysis and design )

  1. 1. Systems Analysis and Design in a Changing World, Fourth Edition
  2. 2. Learning Objectives <ul><li>Explain the foundations for the adaptive methodologies to development </li></ul><ul><li>List and describe the features of the Unified Process system development methodology </li></ul><ul><li>List and describe the features of Agile Modeling </li></ul>
  3. 3. Learning Objectives ( continued ) <ul><li>Compare and contrast the features of Extreme Programming and Scrum development </li></ul><ul><li>Explain the importance of Model-Driven Architecture on enterprise-level development </li></ul><ul><li>Describe frameworks and components, the process by which they are developed, and their impact on system development </li></ul>
  4. 4. Overview <ul><li>The IS discipline is dynamic and always changing </li></ul><ul><li>More complex system requirements have necessitated a whole new set of tools </li></ul><ul><ul><li>The Unified Process (UP) </li></ul></ul><ul><ul><li>Radical, adaptive approaches, including Agile Development, Extreme Programming, and Scrum </li></ul></ul><ul><ul><li>Model-Driven Architecture for enterprise-level systems </li></ul></ul><ul><ul><li>Object frameworks and components to increase productivity and quality </li></ul></ul>
  5. 5. Software Principles and Practices <ul><li>Ubiquitous computing is the current trend in our society </li></ul><ul><ul><li>Using computer technology in every aspect of our lives </li></ul></ul><ul><li>The effort to develop current solutions is demanding </li></ul><ul><li>Current trends in modeling and development processes use five important principles </li></ul>
  6. 6. Software Principles and Practices (continued) <ul><li>Abstraction </li></ul><ul><ul><li>Process of extracting core principles from a set of facts or statement </li></ul></ul><ul><ul><li>Example: Metamodels describe the characteristics of another model </li></ul></ul><ul><li>Models and modeling </li></ul><ul><ul><li>An abstraction of something in the real world, representing a particular set of properties </li></ul></ul>
  7. 7. Software Principles and Practices (continued) <ul><li>Patterns </li></ul><ul><ul><li>Standard solutions to a given problem or templates that can be applied to a problem </li></ul></ul><ul><li>Reuse </li></ul><ul><ul><li>Building standard solutions and components that can be used over and over again </li></ul></ul><ul><li>Methodologies </li></ul><ul><ul><li>A process — including the rules, guidelines, and techniques — that defines how systems are built </li></ul></ul>
  8. 8. Adaptive Approaches to Development <ul><li>Opposite end of spectrum from predictive approaches (recall Chapter 2) </li></ul><ul><li>Allow for uncertainty </li></ul><ul><li>Use empirical controls, not predictive controls </li></ul><ul><ul><li>Describe processes that are variable and unpredictable </li></ul></ul><ul><ul><li>Monitor progress and make corrections on the fly </li></ul></ul>
  9. 9. Adaptive Approaches to Development — Characteristics <ul><li>Less emphasis on up-front analysis, design, and documentation </li></ul><ul><li>More focus on incremental development </li></ul><ul><li>More user involvement in project teams </li></ul><ul><li>Reduced detailed planning </li></ul><ul><ul><li>Used for near-term work phases only </li></ul></ul><ul><li>Tightly control schedules by fitting work into discrete time boxes </li></ul><ul><li>More use of small work teams that are self-organizing </li></ul>
  10. 10. The Unified Process (UP) <ul><li>Object-oriented system development methodology (system development process ) </li></ul><ul><li>Offered by Rational/IBM, UP developed by Booch, Rumbaugh, and Jacobson </li></ul><ul><li>UP should be tailored to organizational and project needs </li></ul><ul><li>Highly iterative life cycle </li></ul><ul><li>Project will be use-case driven and modeled using UML </li></ul>
  11. 11. The Unified Process Life Cycle <ul><li>UP life cycle </li></ul><ul><ul><li>Includes four phases which consist of iterations </li></ul></ul><ul><ul><li>Iterations are “mini-projects” </li></ul></ul><ul><li>Inception – develop and refine system vision </li></ul><ul><li>Elaboration – define requirements and design and implement core architecture </li></ul><ul><li>Construction – continue design and implementation of routine, less risky parts </li></ul><ul><li>Transition – move the system into operational mode </li></ul>
  12. 12. The Unified Process Life Cycle (Figure 16-1)
  13. 13. UP Phases and Objectives (Figure 16-2)
  14. 14. The UP Disciplines <ul><li>UP defines disciplines used within each phase </li></ul><ul><li>Discipline – set of functionally related development activities </li></ul><ul><li>Each iteration includes activities from all disciplines </li></ul><ul><li>Activities in each discipline produce artifacts – models, documents, source code, and executables </li></ul><ul><li>Learning CIS/MIS means learning techniques from these disciplines </li></ul>
  15. 15. The UP Disciplines (continued) <ul><li>Six main UP development disciplines </li></ul><ul><ul><li>Business modeling, requirements, design, implementation, testing, and deployment </li></ul></ul><ul><li>Three additional support disciplines </li></ul><ul><ul><li>Project management, configuration and change management, and environment </li></ul></ul>
  16. 16. UP Disciplines Used in Varying Amounts in Each Iteration (Figure 16-3)
  17. 17. UP Life Cycle Model Showing Phases, Iterations, and Disciplines (Figure 16-4)
  18. 18. The Agile Development Philosophy and Modeling <ul><li>Agile Development </li></ul><ul><ul><li>A philosophy and set of guidelines for developing software in an unknown, rapidly changing environment </li></ul></ul><ul><ul><ul><li>Requires agility – being able to change direction rapidly, even in the middle of a project </li></ul></ul></ul><ul><li>Agile Modeling </li></ul><ul><ul><li>A philosophy about how to build models, some of which are formal and detailed and others are sketchy and minimal </li></ul></ul>
  19. 19. The Agile Development Philosophy and Values <ul><li>Responding to change over following a plan </li></ul><ul><ul><li>An agile project is chaordic – both chaotic and ordered </li></ul></ul><ul><li>Individuals and interactions over processes and tools </li></ul><ul><li>Working software over comprehensive documentation </li></ul><ul><li>Customer collaboration over contract negotiation </li></ul>
  20. 20. Adaptive Methodologies Using Agile Modeling (Figure 16-5)
  21. 21. Agile Modeling Principles <ul><li>AM is about doing the right kind of modeling at the right level of detail for the right purposes </li></ul><ul><ul><li>Use models as a means to an end instead of building models as end deliverables </li></ul></ul><ul><ul><li>Does not dictate which models to build or how formal to make those models </li></ul></ul><ul><ul><li>Has basic principles to express the attitude that developers should have as they develop software </li></ul></ul>
  22. 22. Agile Modeling Principles (Figure 16-6)
  23. 23. Agile Modeling Practices (Figure 16-7)
  24. 24. Extreme Programming (XP) <ul><li>An adaptive, agile development methodology created in the mid-1990s </li></ul><ul><li>Takes proven industry best practices and focuses on them intensely </li></ul><ul><li>Combines those best practices (in their intense form) in a new way to produce a result that is greater than the sum of the parts </li></ul>
  25. 25. XP Core Values <ul><li>Communication </li></ul><ul><ul><li>In open, frequent verbal discussions </li></ul></ul><ul><li>Simplicity </li></ul><ul><ul><li>In designing and implementing solutions </li></ul></ul><ul><li>Feedback </li></ul><ul><ul><li>On functionality, requirements, designs, and code </li></ul></ul><ul><li>Courage </li></ul><ul><ul><li>In facing choices such as throwing away bad code or standing up to a too-tight schedule </li></ul></ul>
  26. 26. Some XP Practices <ul><li>Planning </li></ul><ul><ul><li>Users develop a set of stories to describe what the system needs to do </li></ul></ul><ul><li>Testing </li></ul><ul><ul><li>Tests are written before solutions are implemented </li></ul></ul><ul><li>Pair programming </li></ul><ul><ul><li>Two programmers work together on designing, coding, and testing </li></ul></ul><ul><li>Simple designs </li></ul><ul><ul><li>“KISS” and design continuously </li></ul></ul>
  27. 27. Some XP Practices (continued) <ul><li>Refactoring </li></ul><ul><ul><li>Improving code without changing what it does </li></ul></ul><ul><li>Owning the code collectively </li></ul><ul><ul><li>Anyone can modify any piece of code </li></ul></ul><ul><li>Continuous integration </li></ul><ul><ul><li>Small pieces of code are integrated into the system daily or more often </li></ul></ul><ul><li>System metaphor </li></ul><ul><ul><li>Guides members towards a vision of the system </li></ul></ul>
  28. 28. Some XP Practices (continued) <ul><li>On-site customer </li></ul><ul><ul><li>Intensive user/customer interaction required </li></ul></ul><ul><li>Small releases </li></ul><ul><ul><li>Produce small and frequent releases to user/customer </li></ul></ul><ul><li>Forty-hour work week </li></ul><ul><ul><li>Project should be managed to avoid burnout </li></ul></ul><ul><li>Coding standards </li></ul><ul><ul><li>Follow coding standards to ensure flexibility </li></ul></ul>
  29. 29. XP Core Values and Practices (Figure 16-8)
  30. 30. XP Project Activities <ul><li>System-level activities </li></ul><ul><ul><li>Occur once during each development project </li></ul></ul><ul><ul><li>Involve creating user stories to planning releases </li></ul></ul><ul><li>Release-level activities </li></ul><ul><ul><li>Cycle multiple times – once for each release </li></ul></ul><ul><ul><li>Are developed and tested in a period of no more than a few weeks or months </li></ul></ul><ul><li>Iteration-level activities </li></ul><ul><ul><li>Code and test a specific functional subset in a few days or weeks </li></ul></ul>
  31. 31. XP Development Approach (Figure 16-9)
  32. 32. Scrum <ul><li>A quick, adaptive, and self-organizing development methodology </li></ul><ul><ul><li>Named after rugby’s system for getting an out-of-play ball into play </li></ul></ul><ul><ul><li>Responds to a current situation as rapidly and positively as possible </li></ul></ul><ul><ul><li>A truly empirical process control approach to developing software </li></ul></ul>
  33. 33. Scrum Philosophy <ul><li>Responsive to a highly changing, dynamic environment </li></ul><ul><li>Focuses primarily on the team level </li></ul><ul><ul><li>Team exerts total control over its own organization and work processes </li></ul></ul><ul><li>Uses a product backlog as the basic control mechanism </li></ul><ul><ul><li>Prioritized list of user requirements used to choose work to be done during a Scrum project </li></ul></ul>
  34. 34. Scrum Organization <ul><li>Product owner </li></ul><ul><ul><li>The client stakeholder for whom a system is being built </li></ul></ul><ul><ul><li>Maintains the product backlog list </li></ul></ul><ul><li>Scrum master </li></ul><ul><ul><li>Person in charge of a Scrum project </li></ul></ul><ul><li>Scrum team or teams </li></ul><ul><ul><li>Small group of developers </li></ul></ul><ul><ul><li>Set their own goals and distribute work among themselves </li></ul></ul>
  35. 35. Scrum Practices <ul><li>Sprint </li></ul><ul><ul><li>The basic work process in Scrum </li></ul></ul><ul><ul><li>A time-controlled mini-project </li></ul></ul><ul><ul><li>Firm 30-day time box with a specific goal or deliverable </li></ul></ul><ul><li>Parts of a sprint </li></ul><ul><ul><li>Begins with a one-day planning session </li></ul></ul><ul><ul><li>A short daily Scrum meeting to report progress </li></ul></ul><ul><ul><li>Ends with a final half-day review </li></ul></ul>
  36. 36. Scrum Software Development Process (Figure 16-10)
  37. 37. Project Management and Adaptive Methodologies <ul><li>Project time management </li></ul><ul><ul><li>Smaller scope and focused on each iteration </li></ul></ul><ul><ul><li>Realistic work schedules </li></ul></ul><ul><li>Project scope management </li></ul><ul><ul><li>Users and clients are responsible for the scope </li></ul></ul><ul><ul><li>Scope control consists of controlling the number of iterations </li></ul></ul><ul><li>Project cost management </li></ul><ul><ul><li>More difficult to predict because of unknowns </li></ul></ul>
  38. 38. Project Management and Adaptive Methodologies (continued) <ul><li>Project communication management </li></ul><ul><ul><li>Critical because of open verbal communication and collaborative work </li></ul></ul><ul><li>Project quality management </li></ul><ul><ul><li>Continual testing and refactoring must be scheduled </li></ul></ul><ul><li>Project risk management </li></ul><ul><ul><li>High-risk aspects addressed in early iterations </li></ul></ul>
  39. 39. Project Management and Adaptive Methodologies (continued) <ul><li>Project human resource management </li></ul><ul><ul><li>Teams organize themselves </li></ul></ul><ul><li>Project procurement management </li></ul><ul><ul><li>Integrating purchased elements into the overall project </li></ul></ul><ul><ul><li>Verifying quality of components </li></ul></ul><ul><ul><li>Satisfying contractual commitments </li></ul></ul>
  40. 40. Model-Driven Architecture — Generalizing Solutions <ul><li>Model-Driven Architecture (MDA) is an OMG (Object Management Group) initiative </li></ul><ul><ul><li>Built on the principles of abstraction, modeling, reuse, and patterns </li></ul></ul><ul><ul><li>Provides companies with a framework to identify and classify all system development work being done in an enterprise </li></ul></ul><ul><li>MDA extracts current systems features and information and combines them into a platform independent model (PIM) </li></ul>
  41. 41. Model-Driven Architecture (continued) <ul><li>Platform-independent model (PIM) </li></ul><ul><ul><li>Describes system characteristics that are not specific to any deployment diagram </li></ul></ul><ul><ul><li>Uses UML </li></ul></ul><ul><li>Platform-specific model (PSM) </li></ul><ul><ul><li>Describes system characteristics that include deployment platform requirements </li></ul></ul><ul><li>A set of standard transformations by the OMG move a PSM to a PIM </li></ul>
  42. 42. Software Development and MDA (Figure 16-11)
  43. 43. Metamodels and Transitions between PIM, PSM, and Code (Figure 16-12)
  44. 44. Partial Metamodel of UML Class Diagram (Figure 16-13)
  45. 45. Object Frameworks <ul><li>A set of classes that are designed to be reused in a variety of programs </li></ul><ul><li>The classes within an object framework are called foundation classes </li></ul><ul><ul><li>Can be organized into one or more inheritance hierarchies </li></ul></ul><ul><ul><li>Application-specific classes can be derived from existing foundation classes </li></ul></ul>
  46. 46. Object Framework Types <ul><li>User-interface classes </li></ul><ul><ul><li>Commonly used objects within a GUI </li></ul></ul><ul><li>Generic data structure classes </li></ul><ul><ul><li>Linked lists, binary trees, and so on, and related processing operations </li></ul></ul><ul><li>Relational database interface classes </li></ul><ul><ul><li>Classes to create and perform operations on tables </li></ul></ul><ul><li>Classes specific to an application area </li></ul><ul><ul><li>For use in a specific industry or application type </li></ul></ul>
  47. 47. Impact on Design and Implementation <ul><li>Frameworks must be chosen early in the project </li></ul><ul><li>Systems design must conform to specific assumptions about application program structure and operation that the framework imposes </li></ul><ul><li>Design and development personnel must be trained to use a framework effectively </li></ul><ul><li>Multiple frameworks might be required, necessitating early compatibility and integration testing </li></ul>
  48. 48. Components <ul><li>Software modules that are fully assembled and ready to use </li></ul><ul><ul><li>Reusable packages of executable code </li></ul></ul><ul><li>Have well-defined interfaces to connect them to clients or other components </li></ul><ul><ul><li>Public interfaces and encapsulated implementation </li></ul></ul><ul><li>Standardized and interchangeable </li></ul><ul><ul><li>Updating a single component does not require relinking, recompiling, and redistributing an entire application </li></ul></ul>
  49. 49. Component Standards and Infrastructure <ul><li>Interoperability of components requires standards to be developed and readily available </li></ul><ul><li>Components might also require standard support infrastructure </li></ul><ul><ul><li>Software components have more flexibility when they can rely on standard infrastructure services to find other components </li></ul></ul><ul><li>Networking standards are required for components in different locations </li></ul>
  50. 50. CORBA and COM+ <ul><li>CORBA (Common Object Request Broker Architecture) is a standard for software component connection and interaction developed by the OMG </li></ul><ul><ul><li>An object request broker (ORB) provides component directory and communication services </li></ul></ul><ul><ul><li>The Internet Inter-ORB Protocol (IIOP) is used to communicate among objects and ORBs </li></ul></ul><ul><li>Component Object Model Plus (COM+) is a standard for software component connection and interaction developed by Microsoft </li></ul>
  51. 51. Enterprise JavaBeans <ul><li>Part of the Java programming language’s extensive object framework (JDK) </li></ul><ul><li>A JavaBean can execute on a server and communicate with clients and other components using CORBA </li></ul><ul><ul><li>A JavaBean implements the required component methods and follows the required naming conventions of the JavaBean standard </li></ul></ul><ul><li>Platform independent </li></ul>
  52. 52. Components and the Development Life Cycle <ul><li>Component purchase and reuse is a viable approach to speeding completion of a system </li></ul><ul><ul><li>Purchased components can form all or part of a newly developed or re-implemented system </li></ul></ul><ul><ul><li>Components can be designed in-house and deployed in a newly developed or re-implemented system </li></ul></ul>
  53. 53. Using Purchased Components — Implications <ul><li>Standards and support software of purchased components must become part of the technical requirements definition </li></ul><ul><li>A component’s technical support requirements restrict the options considered during software architectural design </li></ul>
  54. 54. Monitoring System Performance <ul><li>Examine component-based designs to estimate network traffic patterns and demands on computer hardware </li></ul><ul><li>Examine existing server capacity and network infrastructure to determine their ability to accommodate communication among components </li></ul><ul><li>Upgrade network and server capacity prior to development and testing </li></ul>
  55. 55. Monitoring System Performance (continued) <ul><li>Test system performance during development and make any necessary adjustments </li></ul><ul><li>Continuously monitor system performance after deployment to detect emerging problems </li></ul><ul><li>Redeploy components, upgrade server capacity, and upgrade network capacity to reflect changing conditions </li></ul>
  56. 56. Services <ul><li>New method of software reuse enabled by Internet — external services identified and used for applications </li></ul><ul><li>Called Web services and service-oriented architecture (SOA) </li></ul><ul><li>Microsoft .NET is service standard based on SOAP </li></ul><ul><li>Java 2 Web Services (J2WS) is service standard for services in Java </li></ul>
  57. 57. Component Communication Using SOAP (Figure 16-14)
  58. 58. Summary <ul><li>Adaptive development methodologies </li></ul><ul><ul><li>Unified Process (UP) </li></ul></ul><ul><ul><li>Agile Modeling and Agile Development </li></ul></ul><ul><ul><ul><li>Flexibility in an unpredictable business world </li></ul></ul></ul><ul><ul><li>Extreme Programming (XP) </li></ul></ul><ul><ul><ul><li>Tests are written first; programmers work in pairs </li></ul></ul></ul><ul><ul><li>Scrum </li></ul></ul><ul><ul><ul><li>Defines a specific goal that can be completed within four weeks </li></ul></ul></ul>
  59. 59. Summary ( continued ) <ul><li>Model-Driven Architecture (MDA) </li></ul><ul><ul><li>Provides techniques for large organizations to integrate all software and all software development across the entire enterprise </li></ul></ul><ul><li>Software reuse is a fundamental approach to rapid development </li></ul><ul><ul><li>Object frameworks provide a means of reusing existing software through inheritance </li></ul></ul><ul><ul><li>Components are units of reusable executable code that behave as distributed objects </li></ul></ul>