Dynamic Systems Analysis & Design: Adaptive Approaches & Software Principles

1. Systems Analysis and Design in a Changing World, Fourth Edition

2. Learning Objectives • Explain the foundations for the adaptive methodologies to development • List and describe the features of the Unified Process system development methodology • List and describe the features of Agile Modeling Systems Analysis and Design in a Changing World, 4th Edition

3. Learning Objectives (continued) • Compare and contrast the features of Extreme Programming and Scrum development • Explain the importance of Model-Driven Architecture on enterprise-level development • Describe frameworks and components, the process by which they are developed, and their impact on system development Systems Analysis and Design in a Changing World, 4th Edition

4. Overview • The IS discipline is dynamic and always changing • More complex system requirements have necessitated a whole new set of tools • The Unified Process (UP) • Radical, adaptive approaches, including Agile Development, Extreme Programming, and Scrum • Model-Driven Architecture for enterprise-level systems • Object frameworks and components to increase productivity and quality Systems Analysis and Design in a Changing World, 4th Edition

5. Software Principles and Practices • Ubiquitous computing is the current trend in our society • Using computer technology in every aspect of our lives • The effort to develop current solutions is demanding • Current trends in modeling and development processes use five important principles Systems Analysis and Design in a Changing World, 4th Edition

6. Software Principles and Practices (continued) • Abstraction • Process of extracting core principles from a set of facts or statement • Example: Metamodels describe the characteristics of another model • Models and modeling • An abstraction of something in the real world, representing a particular set of properties Systems Analysis and Design in a Changing World, 4th Edition

7. Software Principles and Practices (continued) • Patterns • Standard solutions to a given problem or templates that can be applied to a problem • Reuse • Building standard solutions and components that can be used over and over again • Methodologies • A process—including the rules, guidelines, and techniques—that defines how systems are built Systems Analysis and Design in a Changing World, 4th Edition

8. Adaptive Approaches to Development • Opposite end of spectrum from predictive approaches (recall Chapter 2) • Allow for uncertainty • Use empirical controls, not predictive controls • Describe processes that are variable and unpredictable • Monitor progress and make corrections on the fly Systems Analysis and Design in a Changing World, 4th Edition

9. Adaptive Approaches to Development— Characteristics • Less emphasis on up-front analysis, design, and documentation • More focus on incremental development • More user involvement in project teams • Reduced detailed planning • Used for near-term work phases only • Tightly control schedules by fitting work into discrete time boxes • More use of small work teams that are self-organizing Systems Analysis and Design in a Changing World, 4th Edition

10. The Unified Process (UP) • Object-oriented system development methodology (system development process) • Offered by Rational/IBM, UP developed by Booch, Rumbaugh, and Jacobson • UP should be tailored to organizational and project needs • Highly iterative life cycle • Project will be use-case driven and modeled using UML Systems Analysis and Design in a Changing World, 4th Edition

11. The Unified Process Life Cycle • UP life cycle • Includes four phases which consist of iterations • Iterations are “mini-projects” • Inception – develop and refine system vision • Elaboration – define requirements and design and implement core architecture • Construction – continue design and implementation of routine, less risky parts • Transition – move the system into operational mode Systems Analysis and Design in a Changing World, 4th Edition

12. The Unified Process Life Cycle (Figure 16-1) Systems Analysis and Design in a Changing World, 4th Edition

13. UP Phases and Objectives (Figure 16-2) Systems Analysis and Design in a Changing World, 4th Edition

14. The UP Disciplines • UP defines disciplines used within each phase • Discipline – set of functionally related development activities • Each iteration includes activities from all disciplines • Activities in each discipline produce artifacts – models, documents, source code, and executables • Learning CIS/MIS means learning techniques from these disciplines Systems Analysis and Design in a Changing World, 4th Edition

15. The UP Disciplines (continued) • Six main UP development disciplines • Business modeling, requirements, design, implementation, testing, and deployment • Three additional support disciplines • Project management, configuration and change management, and environment Systems Analysis and Design in a Changing World, 4th Edition

16. UP Disciplines Used in Varying Amounts in Each Iteration (Figure 16-3) Systems Analysis and Design in a Changing World, 4th Edition

17. UP Life Cycle Model Showing Phases, Iterations, and Disciplines (Figure 16-4) Systems Analysis and Design in a Changing World, 4th Edition

18. The Agile Development Philosophy and Modeling • Agile Development • A philosophy and set of guidelines for developing software in an unknown, rapidly changing environment • Requires agility – being able to change direction rapidly, even in the middle of a project • Agile Modeling • A philosophy about how to build models, some of which are formal and detailed and others are sketchy and minimal Systems Analysis and Design in a Changing World, 4th Edition

19. The Agile Development Philosophy and Values • Responding to change over following a plan • An agile project is chaordic – both chaotic and ordered • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation Systems Analysis and Design in a Changing World, 4th Edition

20. Adaptive Methodologies Using Agile Modeling (Figure 16-5) Systems Analysis and Design in a Changing World, 4th Edition

21. Agile Modeling Principles • AM is about doing the right kind of modeling at the right level of detail for the right purposes • Use models as a means to an end instead of building models as end deliverables • Does not dictate which models to build or how formal to make those models • Has basic principles to express the attitude that developers should have as they develop software Systems Analysis and Design in a Changing World, 4th Edition

22. Agile Modeling Principles (Figure 16-6) Systems Analysis and Design in a Changing World, 4th Edition

23. Agile Modeling Practices (Figure 16-7) Systems Analysis and Design in a Changing World, 4th Edition

24. Extreme Programming (XP) • An adaptive, agile development methodology created in the mid-1990s • Takes proven industry best practices and focuses on them intensely • 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 Systems Analysis and Design in a Changing World, 4th Edition

25. XP Core Values • Communication • In open, frequent verbal discussions • Simplicity • In designing and implementing solutions • Feedback • On functionality, requirements, designs, and code • Courage • In facing choices such as throwing away bad code or standing up to a too-tight schedule Systems Analysis and Design in a Changing World, 4th Edition

26. Some XP Practices • Planning • Users develop a set of stories to describe what the system needs to do • Testing • Tests are written before solutions are implemented • Pair programming • Two programmers work together on designing, coding, and testing • Simple designs • “KISS” and design continuously Systems Analysis and Design in a Changing World, 4th Edition

27. Some XP Practices (continued) • Refactoring • Improving code without changing what it does • Owning the code collectively • Anyone can modify any piece of code • Continuous integration • Small pieces of code are integrated into the system daily or more often • System metaphor • Guides members towards a vision of the system Systems Analysis and Design in a Changing World, 4th Edition

28. Some XP Practices (continued) • On-site customer • Intensive user/customer interaction required • Small releases • Produce small and frequent releases to user/customer • Forty-hour work week • Project should be managed to avoid burnout • Coding standards • Follow coding standards to ensure flexibility Systems Analysis and Design in a Changing World, 4th Edition

29. XP Core Values and Practices (Figure 16-8) Systems Analysis and Design in a Changing World, 4th Edition

30. XP Project Activities • System-level activities • Occur once during each development project • Involve creating user stories to planning releases • Release-level activities • Cycle multiple times – once for each release • Are developed and tested in a period of no more than a few weeks or months • Iteration-level activities • Code and test a specific functional subset in a few days or weeks Systems Analysis and Design in a Changing World, 4th Edition

31. XP Development Approach(Figure 16-9) Systems Analysis and Design in a Changing World, 4th Edition

32. Scrum • A quick, adaptive, and self-organizing development methodology • Named after rugby’s system for getting an out-of-play ball into play • Responds to a current situation as rapidly and positively as possible • A truly empirical process control approach to developing software Systems Analysis and Design in a Changing World, 4th Edition

33. Scrum Philosophy • Responsive to a highly changing, dynamic environment • Focuses primarily on the team level • Team exerts total control over its own organization and work processes • Uses a product backlog as the basic control mechanism • Prioritized list of user requirements used to choose work to be done during a Scrum project Systems Analysis and Design in a Changing World, 4th Edition

34. Scrum Organization • Product owner • The client stakeholder for whom a system is being built • Maintains the product backlog list • Scrum master • Person in charge of a Scrum project • Scrum team or teams • Small group of developers • Set their own goals and distribute work among themselves Systems Analysis and Design in a Changing World, 4th Edition

35. Scrum Practices • Sprint • The basic work process in Scrum • A time-controlled mini-project • Firm 30-day time box with a specific goal or deliverable • Parts of a sprint • Begins with a one-day planning session • A short daily Scrum meeting to report progress • Ends with a final half-day review Systems Analysis and Design in a Changing World, 4th Edition

36. Scrum Software Development Process (Figure 16-10) Systems Analysis and Design in a Changing World, 4th Edition

37. Project Management and Adaptive Methodologies • Project time management • Smaller scope and focused on each iteration • Realistic work schedules • Project scope management • Users and clients are responsible for the scope • Scope control consists of controlling the number of iterations • Project cost management • More difficult to predict because of unknowns Systems Analysis and Design in a Changing World, 4th Edition

38. Project Management and Adaptive Methodologies (continued) • Project communication management • Critical because of open verbal communication and collaborative work • Project quality management • Continual testing and refactoring must be scheduled • Project risk management • High-risk aspects addressed in early iterations Systems Analysis and Design in a Changing World, 4th Edition

39. Project Management and Adaptive Methodologies (continued) • Project human resource management • Teams organize themselves • Project procurement management • Integrating purchased elements into the overall project • Verifying quality of components • Satisfying contractual commitments Systems Analysis and Design in a Changing World, 4th Edition

40. Model-Driven Architecture—Generalizing Solutions • Model-Driven Architecture (MDA) is an OMG (Object Management Group) initiative • Built on the principles of abstraction, modeling, reuse, and patterns • Provides companies with a framework to identify and classify all system development work being done in an enterprise • MDA extracts current systems features and information and combines them into a platform independent model (PIM) Systems Analysis and Design in a Changing World, 4th Edition

41. Model-Driven Architecture (continued) • Platform-independent model (PIM) • Describes system characteristics that are not specific to any deployment diagram • Uses UML • Platform-specific model (PSM) • Describes system characteristics that include deployment platform requirements • A set of standard transformations by the OMG move a PSM to a PIM Systems Analysis and Design in a Changing World, 4th Edition

42. Software Development and MDA (Figure 16-11) Systems Analysis and Design in a Changing World, 4th Edition

43. Metamodels and Transitions between PIM, PSM, and Code (Figure 16-12) Systems Analysis and Design in a Changing World, 4th Edition

44. Partial Metamodel of UML Class Diagram (Figure 16-13) Systems Analysis and Design in a Changing World, 4th Edition

45. Object Frameworks • A set of classes that are designed to be reused in a variety of programs • The classes within an object framework are called foundation classes • Can be organized into one or more inheritance hierarchies • Application-specific classes can be derived from existing foundation classes Systems Analysis and Design in a Changing World, 4th Edition

46. Object Framework Types • User-interface classes • Commonly used objects within a GUI • Generic data structure classes • Linked lists, binary trees, and so on, and related processing operations • Relational database interface classes • Classes to create and perform operations on tables • Classes specific to an application area • For use in a specific industry or application type Systems Analysis and Design in a Changing World, 4th Edition

47. Impact on Design and Implementation • Frameworks must be chosen early in the project • Systems design must conform to specific assumptions about application program structure and operation that the framework imposes • Design and development personnel must be trained to use a framework effectively • Multiple frameworks might be required, necessitating early compatibility and integration testing Systems Analysis and Design in a Changing World, 4th Edition

48. Components • Software modules that are fully assembled and ready to use • Reusable packages of executable code • Have well-defined interfaces to connect them to clients or other components • Public interfaces and encapsulated implementation • Standardized and interchangeable • Updating a single component does not require relinking, recompiling, and redistributing an entire application Systems Analysis and Design in a Changing World, 4th Edition

49. Component Standards and Infrastructure • Interoperability of components requires standards to be developed and readily available • Components might also require standard support infrastructure • Software components have more flexibility when they can rely on standard infrastructure services to find other components • Networking standards are required for components in different locations Systems Analysis and Design in a Changing World, 4th Edition

50. CORBA and COM+ • CORBA (Common Object Request Broker Architecture) is a standard for software component connection and interaction developed by the OMG • An object request broker (ORB) provides component directory and communication services • The Internet Inter-ORB Protocol (IIOP) is used to communicate among objects and ORBs • Component Object Model Plus (COM+) is a standard for software component connection and interaction developed by Microsoft Systems Analysis and Design in a Changing World, 4th Edition