This Document Contains Appendix A to B Appendix A Object-Oriented Analysis and Design Chapter Overview Appendix A introduces students to object-oriented analysis and design. OOAD’s increasing popularity is brought about in part because of its ability to represent complex relationships, as well as data and data processing, with a consistent notation. Students are introduced to several techniques that systems analysts can use to perform object-oriented analysis and design. The techniques and notations presented in this chapter include use cases, class diagrams, object diagrams, state diagrams, and sequence diagrams. The Unified Modeling Language (UML) is used to present these techniques and notations. The object-oriented development life cycle consists of three primary phases: analysis, design, and implementation. An object representation develops more detail as it moves through each of these phases. After a brief introduction to UML, students are shown how to prepare use cases, class diagrams, object diagrams, state diagrams, and sequence diagrams. A component diagram is reviewed at the end of the chapter. Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor's point of view, the objectives of this chapter are to: 1. Discuss the similarities and differences between the object-oriented development life cycle and the more traditional systems development life cycle. 2. Show the similarities and differences between object-oriented analysis and design (OOAD) and more traditional, structured systems analysis and design notations and methods. 3. Reinforce the terminology utilized in this chapter. 4. Discuss when each of the modeling techniques would be utilized in the object-oriented development life cycle. 5. Show students how to construct each of the models presented in the chapter. 6. Show and discuss how the models are related to each other. Classroom Ideas 1. An object-oriented specification can become very extensive since all aspects are integrated into one model, so you will need to use simple examples. After briefly reviewing OOAD terminology and notation, it is recommended that you teach from examples for the rest of the class. Problem and Exercise 3 is a good example to work in class. The greatest discussion will probably center around what methods should exist and where they should be located (that is, with what object). 2. It is essential that students have a sound understanding of the core concepts of OOAD: object, class, encapsulation, and inheritance. Be sure students can distinguish an object from a data entity instance and a class from an entity type. Emphasize the ramifications of encapsulation for systems development, which deal primarily with decoupling system components. 3. Compare and contrast the OOAD phases with the traditional SDLC phases. Stress to the students that in the beginning the model is abstract, showing more detail as it moves through the OOAD phases. 4. If you have access to practicing systems analysts, invite them to your class to discuss their usage of OOAD. 5. Stress the benefits of OOAD, especially the increased consistency among the models developed during object-oriented analysis and design. 6. For some students this may be their first exposure to object-oriented analysis and design. One way to approach the presentation of this material is to make heavy use of the figures and illustrations utilized in the chapter. Use these figures and illustrations to reinforce the terminology and diagramming rules presented in the chapter. Lecture Notes The Object-Oriented Modeling Approach Appendix A introduces students to the techniques and graphical diagrams that systems analysts use for object-oriented analysis and design. The deliverables from project activities using object-oriented modeling include data-flow diagrams, entity-relationship diagrams, and repository descriptions. Benefits associated with the object-oriented modeling approach include: (1) the ability to tackle more challenging problem domains; (2) improved communication among users, analysts, designers, and programmers; (3) reusability of analysis, design, and programming results; and (4) increased consistency among the models developed during object-oriented analysis, design, and programming. The object-oriented systems development life cycle progressively develops a representation of an object, with the model becoming more detailed as it evolves. During the analysis phase, a model of the real-world application is prepared. During the design phase, this model is refined and adapted to suit the target implementation environment. During the implementation phase, the design is implemented using a programming language and/or database management system. The Unified Modeling Language is a notation that allows the modeler to specify, visualize, and construct the artifacts of software systems, as well as business models. The UML includes the following techniques and notations: use cases, class diagrams, state diagrams, and sequence diagrams. Using the UML, an analyst represents several views of the system. Use-Case Modeling During the analysis phase, analysts perform use-case modeling to help them understand the functional requirements of the system. A use-case model depicts actors and use cases. Figure A–1 shows a use-case diagram for a university registration system. Use cases are initiated by an actor, represent the complete functionality of the system, participate in relationships with other use cases, and may use other use cases. A use case may participate in “extends” or “include” relationships. Figure A–2 shows a use-case diagram for the Hoosier Burger system. Object Modeling: Class Diagrams The object-oriented approach models the world as objects; an object has a state and exhibits behavior. An object class is a set of objects that share a common structure and a common behavior. Object models include class diagrams and object diagrams. A class diagram shows the static structure of an object-oriented model; an object diagram is a graph of instances that are compatible with a given class diagram. Figure A–3 shows UML class and object diagrams. On a class diagram, a class is represented as a rectangle with three compartments separated by horizontal lines. On an object diagram, an object is represented as a rectangle with two compartments. An operation is a function or a service that is provided by all the instances of a class. Encapsulation is the technique of hiding the internal implementation details of an object from its external view. An association is a relationship between object classes. The degree of an association may be unary, binary, ternary, or n-ary. Figure A–4 provides examples of these different degrees. A solid line depicts an association between the participating classes. An association role is the end of an association where it connects to a class. Multiplicity is an indication of how many objects participate in a relationship. Figure A–5 shows binary association relationships. Representing Generalization Generalization abstracts the common features among multiple classes, as well as their relationships, into a more general class. Generalization generalizes subclasses into super classes. The basis of generalization is noted by placing a discriminator next to the path. A subclass inherits features from its superclass. Figure A–6 provides examples of generalization, inheritance, and constraints. An abstract class does not have direct instances, but its descendants may have direct instances. In contrast, a concrete class can have direct instances. Representing Aggregation Aggregation is a part-of relationship between a component object and an aggregate object; it is represented by a hollow diamond at the aggregate end. Figure A–7 provides an example of aggregation. Dynamic Modeling: State Diagrams State diagrams model the dynamic aspects of a system. State transitions are the changes in the attributes of an object or in the links an object has with other objects. State transitions are triggered by events. Figure A–8 shows a state diagram. Dynamic Modeling: Sequence Diagrams Interaction diagrams show the pattern of interactions among objects for a particular use case. There are two types of interaction diagrams: sequence and collaboration. A sequence diagram is a depiction of the interactions among objects during a certain period of time. Figure A–9 illustrates a sequence diagram. On a sequence diagram, an object is shown as a vertical dashed line. Objects send each other either synchronous messages or simple messages. Collaboration diagrams are not discussed in the chapter. Designing a Use Case with a Sequence Diagram In this section, the authors show students how to draw a sequence diagram for an instance of the Class registration use case. Students can reference Figure A–9. Moving to Design Design begins with an existing set of analysis models and adds technical details. Figure A–10 shows an example of UML packages and dependencies. During design, component diagrams are prepared. Figure A–11 shows a component diagram for a class registration system. Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list. Review Questions Solutions A-1. Compare and contrast the object-oriented analysis and design models with structured analysis and design models. Answer: The biggest difference between the models is that the object-oriented models build on each other and are consistent. Models developed during structured analysis and design are weakly connected and lack a common representation. A-2. Give an example of an abstract use case. Your example should involve at least two other use cases and show how they are related to the abstract use case. Answer: In Figure A–2, the Track Sales and Inventory Data use case is an example of an abstract use case. Abstract Use Case: "Manage User Authentication" Concrete Use Cases: 1. "Login User": Handles the process where a user provides credentials to access their account. 2. "Register New User": Manages the creation of a new user account with required details. Relation: Both "Login User" and "Register New User" are specific implementations of the broader "Manage User Authentication" use case. The abstract use case encompasses the general concept of verifying and managing user identities, while the concrete use cases represent distinct actions within this concept. A-3. Explain the use of association role for an association on a class diagram. Answer: The association role is the end of an association where it connects to a class. The role can be explicitly named, indicating the role played by the class attached to the end at which the name appears. A role will have multiplicity; multiplicity gives an indication of how many objects participate in the relationship. A-4. Give an example of generalization. Your example should include at least one superclass and three subclasses, and a minimum of one attribute and one operation for each of the classes. Indicate the discriminator and specify the semantic constraints among the subclasses. Answer: A suggested answer is provided below Example of Generalization: Superclass: Vehicle • Attribute: maxSpeed • Operation: startEngine() Subclass 1: Car • Attribute: numDoors • Operation: playRadio() Subclass 2: Motorcycle • Attribute: hasSidecar • Operation: popWheelie() Subclass 3: Truck • Attribute: cargoCapacity • Operation: loadCargo() Discriminator: type (e.g., Car, Motorcycle, Truck) Semantic Constraints: • Each Vehicle must be one and only one of the subclasses (Car, Motorcycle, or Truck). • The `startEngine()` operation is common to all subclasses, but each subclass adds specific operations and attributes. A-5. Give an example of aggregation. Your example should include at least one aggregate object and three component objects. Specify the multiplicities at each end of all the aggregation relationships. Answer: One example of aggregation is a vehicle. A car will have front and side air bags, an air conditioner, an engine, and other components. A suggested diagram is provided below. An example of aggregation is a Library (aggregate object) containing Books, Magazines, and Newspapers (component objects). • Library to Books: 1 to many (1..) • Library to Magazines: 1 to many (1..) • Library to Newspapers: 1 to many (1..) Here, the Library can exist without the Books, Magazines, and Newspapers, but they are part of the Library as a whole. A-6. Give an example of state transition. Your example should show how the state of the object undergoes a transition based on some event. Answer: A suggested answer is provided below. The image represents a state transition for a game. Here's a corresponding example: Object: Game • Initial State: In-Play (when the game starts) • Event: Timeout called → Transition to TimeOut state • Event: Game resumes → Transition back to In-Play state • Event: Game ends → Transition to Over state This example shows how the game transitions between states (In-Play, TimeOut, Over) based on events like timeout calls, game resumption, and the end of the game. Problems and Exercises Solutions A-7. The use-case diagram shown in Figure A-1 captures the Student billing function but does not contain any function for accepting tuition payment from students. Revise the diagram to capture this functionality. Also, express some common behavior among two use cases in the revised diagram by using “include” relationships. Answer: A suggested answer is provided below. A-8. Suppose that the employees of the university are not billed for tuition. Their spouses do not get a full-tuition waiver, but pay for only 25 percent of the total tuition. Extend the use-case diagram of Figure A-1 to capture these situations. Answer: A suggested answer is provided below. A-9. Draw a class diagram, showing the relevant classes, attributes, operations, and relationships for the following situation (if you believe that you need to make additional assumptions, clearly state them for each situation). (Note: The scenario is provided on pages 386 and 387 in the textbook.) Answer: A suggested answer is provided below. A-10. An organization has been entrusted with developing a Registration and Title system that maintains information about all vehicles registered in a particular state. For each vehicle that is registered with the office, the system has to store the name, address, telephone number of the owner, the start date and end date of the registration, plate information (issuer, year, type, and number), sticker (year, type, and number), and registration fee. In addition, the following information is maintained about the vehicles themselves: the number, year, make, model, body style, gross weight, number of passengers, diesel powered (yes/no), color, cost, and mileage. If the vehicle is a trailer, diesel powered and number of passengers are not relevant. For travel trailers, the body number and length must be known. The system needs to maintain information on the luggage capacity for a car, maximum cargo capacity and maximum towing capacity for a truck, and horsepower for a motorcycle. The system issues registration notices to owners of vehicles whose registrations are due to expire after two months. When the owner reviews the registration, the system updates the registration information on the vehicle. a. Develop a static object model by drawing a class diagram that shows all the object classes, attributes, operations, relationships, and multiplicities. For each operation, show its argument list. b. Draw a state diagram that captures all the possible states of a Vehicle object, right from the time the vehicle was manufactured until it goes to the junkyard. In drawing the diagram, you may make any necessary assumptions, as long as they are realistic. c. Select any state or event from the high-level state diagram that you have drawn and show its fine structure (substates and their transitions) in a lower-level diagram. d. One of the use cases for this application is "Issue registration renewal notice,” which is performed once every day. Draw a sequence diagram, in generic form, showing all possible object interactions for this use case. Answer: Suggested answers for parts a, b, c, and d are provided below. Part a Part b Part c Part d For part d, your students can use Figure A–9 as a guide for preparing their sequence diagrams. At a minimum, the sequence diagrams should show the interactions among the registration window, registration entry, customer, vehicle, and title objects. Appendix B Agile Methodologies Chapter Overview Appendix B introduces students to Agile Methodologies with a focus on eXtreme Programming. Agile Methodologies are compared and contrasted with traditional engineering-based approaches, describing when Agile Methodologies are preferred over the traditional engineering-based approaches. eXtreme Programming, a popular Agile Methodology, is discussed along with its key principles. The end of the appendix discusses how requirements determination, design specifications, and implementation are carried out when using an Agile Methodology. Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor's point of view, the objectives of this chapter are to: 1. Explain the benefits and usage of Agile Methodologies. 2. Differentiate between Agile Methodologies and engineering-based approaches to systems development. 3. Reinforce the concepts and terminology presented in this chapter. 4. Explain the Agile Methodologies approach to system requirements determination, design specifications, and implementation. 5. Compare and contrast Agile Methodology design activities with the engineering-based methods. 6. Stress the three key principles of Agile Methodologies and show how these principles help differentiate the Agile Methodologies from the engineering-based approaches. Classroom Ideas 1. For some students this may be their first exposure to Agile Methodologies. One way to approach the presentation of this material is to make heavy use of the figures and illustrations presented in this appendix. 2. Ask your students to identify and research a specific Agile Methodology, such as Scrum, the Crystal Families, or Feature Driven Development. Ask your students to present their findings to the class. 3. If you have the class time, assign your students to groups. Ask your students to prepare answers to Problem and Exercise 5. Ask your students to then present their answers to the class. 4. If you have access to practicing systems analysts, invite them to your class to discuss their usage of Agile Methodologies. Lecture Notes The Trend to Agile Methodologies Systems analysis and design has gone through three distinct phases. These phases include developer-as-artist, developer-as-engineer, and Agile Methodologies. The developer-as-artist phase was marked by a lack of documentation and development tools; developers were seen as more geniuses and artists, and there was a high degree of dependence on the developer for the continued operation of the system. The developer-as-engineer phase brought discipline to the systems analysis and design area. The convergence of the Internet economy and object-oriented approach led to the latest approach, Agile Methodologies. Agile Methodologies favor close cooperation between developers and clients, combine numerous life cycle phases into few phases, and have multiple releases of software. Agile Methodologies Agile Methodologies is an umbrella term referring to several alternative approaches to systems analysis and design. These alternative approaches include the Crystal Family, Adaptive Software Development, Scrum, Feature Driven Development, and eXtreme Programming, as well as several other approaches. Agile Methodology proponents agree that the Agile Methodologies share three key principles; these principles are: (1) a focus on adaptive rather than predictive methodologies; (2) a focus on people rather than roles; and (3) a self-adaptive process. Figure B–1 shows the Agile Manifesto. The Agile Manifesto outlines the values and principles agreed to by the seventeen anarchists. An organization needs different approaches to systems development. An Agile process is recommended when your project involves: (1) unpredictable or dynamic requirements; (2) responsible and motivated developers; and (3) customers who understand and will get involved. In contrast, an engineer-based approach is recommended when the development team exceeds 100 people and the project has a fixed-price or fixed-scope contract. Table B–1 summarizes five critical factors that distinguish Agile and traditional approaches to systems development. Agile approaches and traditional approaches can be distinguished on size, criticality, dynamism, personnel, and culture. eXtreme Programming eXtreme Programming is presented as a popular Agile Methodologies example. eXtreme Programming has short development cycles, uses an incremental planning approach, focuses on automated tests written by programmers and customers to monitor the process of development, and relies on an evolutionary approach to development. eXtreme Programming is characterized by two-person programming teams and having a customer on-site during development; it fuses planning, analysis, design, and construction together into a single phase, and uses a unique approach to capturing and presenting system requirements and design specifications. With eXtreme Programming, programmers both write and test the code; only things that can go wrong are tested; code is integrated into the system soon after it has been written; and pair programming is utilized. The Heart of the Systems Development Process Agile Methodologies combine analysis, design, and implementation activities into a single phase. Figure B–2 illustrates the analysis-design-code-test loop. Agile Methodologies view analysis, design, and implementation as the heart of systems development. Figure B–3 illustrates this point. The iteration between analysis and design is at the core of development agility. This appendix introduces students to three requirements determination techniques, including continual user involvement, Agile Usage-Centered Design, and the Planning Game. The Continual User Involvement technique encourages constant involvement of users in the analysis and design process. Users provide input about their requirements and then observe and evaluate as the requirements are designed, coded, and tested. Agile Usage-Centered Design focuses on user roles, user goals, and necessary tasks to accomplish goals. Table B–2 identifies the Agile Usage-Centered Design steps. Of particular interest are the uses of venting sessions and 3 x 5 cards. eXtreme Programming utilizes a Planning Game and an Iteration Planning Game. The Planning Game encourages interaction between Business and Development. Business refers to the customers, and Development refers to the individuals responsible for developing and constructing the system. The Planning Game includes exploration, commitment, and steering phases. Figure B–4 illustrates the Planning Game. During the exploration phase, Story Cards are created. During the commitment phase, Business sorts the Story Cards based on feature priorities. During the steering phase, Business evaluates how development is progressing. The Iteration Planning Game also has exploration, commitment, and steering phases. Only programmers play the Iteration Planning Game. During exploration, Story Cards are converted to Task Cards. During commitment, responsibility for tasks is assigned. During steering, the programmers code, test, and integrate the features into the product. Agile Methodologies capture the design specifications as part of the design process. The code serves as the design specifications. eXtreme Programming uses simple design and refactoring to improve the design quality. Simple design refers to creating uncomplicated software and software components that work to solve the current problem rather than creating complicated software designed for a future that may not come. Refactoring makes a program simpler after adding a new feature. According to Beck (2000), eXtreme Programming’s simplest design has four constraints; these include (1) the system must communicate everything you want it to communicate; (2) the system must contain no duplicate code; (3) the system should have the fewest possible classes, and (4) the system should have the fewest possible methods. Forms of refactoring include simplifying complex statements, abstracting solutions from reusable code, and removing duplicate code. With Agile Methodologies, coding and testing are tightly linked. The same programmers write and test the code. Code is tested and then, if it passes the test, it is implemented into the system. Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list. Review Questions Solutions B-1. What are Agile Methodologies? Answer: Agile Methodologies is an umbrella term referring to a group of development approaches that rely on an object-orientation and the need for speed. This group of agile approaches shares three key principles, including a focus on adaptive rather than predictive methodologies, a focus on people rather than roles, and a self-adaptive process. B-2. Describe the three stages that information systems development has passed through. Answer: Developer-as-artist, developer-as-engineer, and Agile Methodologies are the three stages mentioned in Appendix B. Developer-as-artist is described by a lack of documentation and development tools and a high degree of dependence on the developer. The developer-as-engineer stage saw the introduction of discipline and theory to systems development. Factoring, decomposition, prototyping, documentation, rigorous testing, structure tools and techniques, and computer-based tools are associated with this stage. The object-oriented approach and the Internet economy can be seen as the enabler for the Agile Methodologies. The Agile Methodologies rely on an object-orientation and the need for speed. The Agile Methodologies are characterized by their focus on adaptive rather than predictive methodologies, focus on people rather than roles, and focus on a self-adaptive process. B-3. What is at the heart of the systems development process? How does it fit within the larger SDLC framework? Answer: Analysis, design, and implementation are at the heart of the systems development process. The textbook identified four major SDLC phases: (1) planning and selection, (2) analysis, (3) design, and (4) implementation and operation. During systems planning and selection, possible projects are identified, prioritized, and selected for development. During analysis, requirements are identified, documented, and alternative design strategies are generated. During systems design, system specifications are produced. During implementation and operation, coding and testing are done, as well as other operations activities. B-4. Explain eXtreme Programming. Answer: eXtreme Programming is a popular Agile methodology. eXtreme Programming employs short development cycles, an incremental planning approach and automated tests written by programmers. eXtreme Programming actively involves customers in the development process by having the customer onsite during development, uses two-person programming teams (pair programming) and fuses planning, analysis, design, and construction into a single phase. eXtreme Programming uses the Planning Game and Iteration Planning Game techniques. Both techniques have exploration, commitment and steering phases. The Planning Game involves customers (Business) and the individuals designing and constructing the system (Development). During the Planning Game’s exploration phase, Business prepares Story Cards. Story Cards capture the new system’s requirements. During the commitment phase, Business sorts the Story Cards based on the new system’s mandatory, essential, and desirable features. Development sorts the cards based on risk. Business selects the cards that will be included in the next product release. During the steering phase, Business monitors the progress and works with Development to make any necessary adjustments. During the Iteration Planning Game’s exploration phase, Story Cards are converted into one or more Task Cards. During the Iteration Planning Game’s commitment phase, programmers assume responsibility for tasks and balance workloads. During the Iteration Planning Game’s steering phase, programmers write, test, and integrate the code into the system. B-5. What is continual user involvement? Answer: Continual user involvement is a requirements determination technique that works well with small, dedicated development teams. Continual user involvement encourages the continual involvement of the user during the analysis and design process. Continual user involvement answers one of the criticisms of the traditional, engineering-based approaches. The traditional approaches to systems development are often criticized because of the user’s limited involvement in the development process. B-6. What is Agile Usage-Centered Design? How is it used for requirements determination? Answer: Agile Usage-Centered Design is a requirements determination technique for involving users in the requirements determination process. The Agile Usage-Centered Design technique has nine steps, eight of which are outlined in Table B–2. Agile Usage-Centered Design brings together analysts, users, programmers, and testing staff. Everyone is given a chance to “vent” about the current system and identify requirements for the new system. Important user roles are identified and recorded on 3 x 5 cards. These cards are then sorted based on similarity. This process is called role model. Next, the tasks for the user roles are identified and recorded on 3 x 5 cards. These tasks are ordered by importance and then by frequency. Cards are then sorted based on task similarity. This process is called task model. Tasks cards are clumped together based on similarity and then grabbed; this process is called interaction context. For each task, a description of the task is recorded on the task card and steps required to complete the task are listed on the card. Each set of cards (clump) is treated as a set of tasks to be supported by the user interface. Finally, a user role is assumed and each task is stepped through. B-7. What is the Planning Game, and what is it used for? Answer: The Planning Game is a requirements determination technique used by eXtreme Programming. The Planning Game encourages active interaction between the individuals who will use the system and those that will develop the system. B-8. How are design specifications handled in the Agile Methodologies? Answer: Design specifications are captured as part of the design process and continue to evolve with each analysis-design-code-test iteration. For example, a project utilizing Agile Methodologies captures the design specifications as part of the code and does not produce detailed design specifications. B-9. What is simple design? What is refactoring? Answer: Simple design creates uncomplicated software and software components that work to solve the current problem rather than creating complicated software designed for a future that may not come. Refactoring makes a program simpler after adding a new feature. B-10. Explain how testing differs in the Agile Methodologies and in traditional approaches. Answer: With Agile Methodologies, coding and testing are intimate parts of the same process. Programmers who write the code also test it, and code is often tested and integrated into the system soon after it is written. B-11. What have we learned about Agile development methods in practice? Answer: There are three primary critical success factors Agile development: 1) Continuous delivery (delivery Strategy) of working software in short time scales. 2) Managers and programmers must continually focus on technical excellence and simple Design by following Agile software engineering practices. 3) Projects should be built around motivated individuals (Team Capability). After implementation Agile methods can lead to several positive outcomes: 1) Improved job satisfaction. 2) Improved programmer productivity. 3) Increased customer satisfaction. Agile methods work best for Small projects. Additional lessons learned from Agile Methods in practice are discussed on page 3.89. Problems and Exercises Solutions B-12. When should you use an Agile method, and when should you use an engineering-based method for developing a system? Support your answer. Answer: An Agile method is recommended if the project has unpredictable or dynamic requirements, responsible and motivated developers, and customers who understand and will get involved. An engineering-based method is recommended when the project operates under a fixed-price or fixed-scope contract. Table B-1 identifies five critical factors that also distinguish Agile and traditional approaches. These critical factors include size, criticality, dynamism, personnel, and culture. While Agile methods are well suited for small products and teams, traditional methods are better for large projects and safety-critical systems. Agile methods work better for systems operating in volatile and fluid environments. In contrast, traditional methods work best for projects that will operate in stable environments. Agile methods may need a critical mass of agility experts and seem to work best in a culture where people are empowered by freedom. In contrast, engineering-based methods seem to work best where people are more comfortable having their roles defined for them. B-13. Find books and articles on some of the other Agile Methodologies, such as Scrum and Feature Driven Development. Compare what you find to what you have read in this appendix about eXtreme Programming. Write a report that illustrates the similarities and differences in these approaches. Answer: Martin Fowler has written a nice, informative article on Agile Methodologies. Currently, the URL is http://www.martinfowler.com/articles/newMethodology.html. This is a good starting point for students interested in learning more about Agile Methodologies. The article provides an overview of several Agile Methodologies, including Scrum and Feature Driven Development. B-14. How widespread are the Agile Methodologies in the information technology industry? Research this question and write a report that explains what you find. Answer: Students will find many articles and Web sites attesting to the growing popularity of Agile Methodologies. For instance, an Agile Business Conference is held in the United Kingdom. More information can be obtained at http://www.agileconference.org/organisation.asp. Report Summary: Agile Methodologies in IT Industry Agile methodologies are highly prevalent in the IT industry, with around 95% of organizations adopting some form. The most widely used Agile practices include Scrum, Kanban, and Extreme Programming (XP), with Scrum being the most popular. Agile has revolutionized project management by enhancing flexibility and customer satisfaction. Despite its success, scaling Agile in large organizations can be challenging, leading to the development of frameworks like SAFe and LeSS to address these issues. Agile practices are integral to modern IT operations and continue to drive innovation. B-15. Using the World Wide Web, find a company or firm near you where Agile Methodologies are in use. Interview developers to find out what their approach to development looks like. Prepare a report based on your findings. Answer: Students should easily locate companies that are currently using Agile Methodologies. Ask your students to compare their interview findings to information from the appendix, as well as any articles that they read in preparation for the interview. Report: Agile Methodologies at XYZ Tech Solutions Company: XYZ Tech Solutions Location: [Your City, Your Country] Findings: • Methodology: Uses Scrum with two-week sprints. • Practices: Daily stand-ups, sprint planning, and retrospectives. • Tools: Jira for task management. • Challenges: Scaling Agile and integrating with legacy systems. Conclusion: XYZ Tech Solutions applies Scrum effectively, improving flexibility and team collaboration despite some challenges in scaling. B-16. Assume you have been given the task of leading a team developing an online order-entry system. What would your project look like using the structured techniques featured in this book? What would your project look like using an Agile method? Compare and contrast these two different approaches to developing this system. Be sure to include important considerations such as project duration, personnel issues, and the quantity and quality of involvement of the client. Answer: This is an interesting activity for your students to complete. One approach to this question is to divide your students into two or more groups. Have half the groups prepare a project plan for the online order-entry system utilizing a traditional approach. In contrast, have the remaining half prepare project plans for an Agile method. If you have the class time, ask your students to present their findings to the class. As indicated in the chapter, your students will find that the Agile methods have an adaptive, people-oriented focus. The Agile methods have a strong focus on iterative development, as well as a close relationship between coding and testing. Students should find that the Agile methods require a more active involvement with the end user, numerous iterations, and less required documentation. Comparison: Structured vs. Agile for Online Order-Entry System Structured Techniques (Waterfall): • Duration: Longer with sequential phases. • Personnel: Defined roles, less flexible to changes. • Client Involvement: Limited to initial requirements and final delivery. • Quality: Difficult to incorporate changes once set. Agile Method (Scrum): • Duration: Shorter with iterative sprints. • Personnel: Flexible, self-organizing teams. • Client Involvement: High, with continuous feedback. • Quality: Adaptable to changes and continuous improvement. Summary: Agile offers flexibility, frequent client engagement, and adaptability, while structured techniques provide a predictable process but with less flexibility and client interaction. Solution Manual for Essentials of Systems Analysis and Design Joseph S. Valacich, Joey F. George, Jeffrey A. Hoffer 9780133546231
Download
Close
Close
