CH-10 Approaches to System Development – Systems Analysis and Design in a Changing World : Chapter Notes

Chapter 10 – Approaches to System Development Table of Contents Chapter Overview Learning Objectives Notes on Opening Case and EOC Cases Instructor's Notes (for each section) Key Terms Lecture notes Quick quizzes Classroom Activities Troubleshooting Tips Discussion Questions Chapter Overview The chapter first presents and explains the differences in the life cycle approach—the predictive and the adaptive approaches. These two approaches are really a continuum and any give project may have elements of both approaches. The predictive approach to the SDLC is used for projects that are well understood and low risk. The adaptive approach to the SDLC is used for projects that are not well understood and are higher risk. Adaptive SDLCs are more iterative and allow the project team to adapt the project to changing circumstances. The chapter includes a discussion of the Agile philosophy and Agile modeling principles. Students should understand that Agile philosophy recognizes that most users do not understand the complexities of business processes and supporting software and therefore most projects must be flexible and agile. Agile modeling has basic principles to encourage developers to use modeling as a means to the end product (working software), and not an end in and of itself. Finally the chapter concludes with a discussion of three methodologies that embrace the Agile philosophy – Unified Process (UP), Extreme Programming (XP), and Scrum. Learning Objectives After reading this chapter, the student should be able to: Compare the underlying assumptions and uses of a predictive and an adaptive system development life cycle (SDLC) Explain what makes up a system development methodology—the SDLC as well as models, tools, and techniques Describe the key features of Agile development Understand and describe the key features of the Unified Process, Extreme Programming, and Scrum Agile system development methodologies Notes on Opening Case and EOC Cases Opening Case Development Approaches at Ajax Corporation, Consolidated Concepts, and Pinnacle Manufacturing: This case briefly describes various development approaches used by three different companies. Each company uses a different approach with different techniques. Some techniques were based on structured methods; another company used object-oriented develop techniques; and the third company were experimenting with Agile techniques. The point of the case is that there are many different ways to develop software and students will encounter various combinations when they begin working in industry. When students interview for employment it is also a good idea if they ask questions about the approach, techniques, and methods used by the company with which they are interviewing. Some companies like to focus on the latest approaches while at the other extreme are companies that have not updated their approaches for many years. EOC Cases A “College Education Completion” Methodology: This case is based on the system oriented principles covered in the chapter. The student is asked to think of his college education and to divide it into phases. Then students are asked to identify specific activities that might apply to each phase. Finally they are asked to identify specific techniques. This case requires that the students think in terms of abstract system concepts and development cycle concepts and apply them to an entirely different context. Community Board of Realtors (running case): Community Board of Realtors is a professional organization that supports real estate offices and agents. This case is a smaller case in that it has few use cases and a simple database structure. The students are asked to think about developing the system with both a predictive project and an adaptive project. They are asked additional questions about an iterative approach, including how to iterate if the total solution included support for mobile devices. Spring Breaks 'R' Us Travel Services (SBRU) (running case): SBRU is an online travel services that books spring break trips to resorts for college students. This is fairly sophisticated system with four subsystems and various users and different database tables. The student is asked to identify classes for all four subsystems (in addition to a previous chapter's solutions for one subsystem). Then students are asked how to structure the project as an iterative project, especially with regard to implementation of the various classes. On the Spot Courier Services (running case): On the Spot is a small, but growing, courier service that needs to track customers, package pickups, package deliveries, and delivery routes. In this chapter, we introduce four subsystems. The student is asked to organize an adaptive, iterative project to develop these four subsystems. Various questions help the student think about the ramifications of organizing the project in different ways. The student is also asked about which models are necessary and to what depth is modeling require based on the Agile principles given in the chapter. Sandia Medical Devices (running case): Sandia Medical Devices is a company that specializes in medical monitoring through remote, mobile telecommunication devices. This chapter describes the project team, including users assigned to the project, and the anticipated project schedule. The use cases to be implemented are also identified. The student is asked to comment on the anticipated project schedule, the use of Agile techniques, and the potential problems with user involvement. Instructor's Notes The Systems Development Life Cycle Key Terms predictive approach to the SDLC – an approach that assumes the project can be planned in advance and that the new information system can be developed according to the plan adaptive approach to the SDLC – an approach that assumes the project must be more flexible and adapt to changing needs as the project progresses phases – related groups of development activities, such as planning, analysis, design, implementation, and support waterfall model – an SDLC approach that assumes the phases can be completed sequentially with no overlap incremental development – an SDLC approach that completes portions of the system in small increments across iterations, with each increment being integrated into the whole as it is completed walking skeleton – a development approach in which the complete system structure is built but with bare-bones functionality Lecture Notes A project is a planned undertaking that has a beginning and an end, and which produces a predetermined result or product. The term system development project describes a planned undertaking, which is normally a large job that produces a new information system. Success depends heavily on having an organized, methodical sequence of tasks and activities that culminate with an information system that is reliable, robust, and efficient. One of the key concepts in system development is the systems development life cycle (SDLC). The SDLC refers to the entire process of building, deploying, using, and updating an information system. The other major concept in this chapter that students should learn well relates to the two types of SDLC approaches. The nature of the project determines the best approach to use. A predictive approach to the SDLC assumes that the development project is planned in advance and that the new information system can be developed according to the plan. An adaptive approach to the SDLC is used when the exact requirements or needs of the users are not well understood. A more flexible approach is needed that allows the plan to be modified as the project progresses. Figure 10-1 shows the continuum from completely predictive to completely adaptive projects. Traditional Predictive Approaches to the SDLC In every project there must be activities associated with project initiation, planning, analysis, design, implementation, and deployment. Each of these sets of activities are called a phase. There is another phase, called support, which consists of those ongoing activities to maintain the system once it is in production. This text teaches the basic concepts associated with the initiation, planning, analysis, design, implementation, and the deployment phases of an SDLC. The following list identifies the objective of each of the six phases: initiation – activities to get the project identified, approved, and budgeted planning – activities to scope the project, plan and schedule the work, and identify the required resources analysis – activities to understand the user requirements design – activities to define and structure the solution system implementation – programming activities and other activities to build the solution and database deployment – activities associated with data conversion, final testing, and putting the system into production The SDLC that is the most predictive is called the waterfall model, an SDLC that assumes the various phases of a project can be completed sequentially—one phase falls into the next phase, and there is no going back as shown in Figure 10-3. This approach is almost never used any more. It never worked very well. Modified waterfall approaches are more flexible and allow considerable overlap of the phases. The six phases tend to follow one after the other, but there is always a lot of overlap. Figure 10-4 shows how a modified waterfall model might work. Not only is a modified waterfall more effective, but it is more efficient by allowing developers to multi-task with analysis, design, and programming. However, the overall approach is to have one big project and to develop the system in one large continuous sequence of activities. Newer Adaptive Approaches to the SDLC In contrast to the predictive SDLC, the adaptive SDLC assumes project activities have to be adjusted as the project progresses. This is necessary because aspects of the project are not well understood at the beginning. Rather than having the analysis, design, and implementation phases proceed sequentially with some overlap, iterations can be used to create a series of mini-projects that address smaller parts of the application. One of these smaller parts is analyzed, designed, built, and tested during a single iteration; then, based on the results, the next iteration proceeds to analyze, design, build, and test the next smaller part. Related to the idea of an iterative project is the concept of incremental development. Obviously by having a limited scope for each interaction, we are only developing a portion – and increment – of the total system. An increment may be completed in one or more iterations. Sometimes this is also referred to as an organic approach because the system is growing during the life of the overall project. One approach to incremental development is to build the overall structure of the system first, but with very limited functionality. This is usually called a walking skeleton. The system is “fleshed out” over time as it is built tested. Quick Quiz Q: What is the basic difference between the predictive approach and the adaptive approach? A: The predictive approach tries to predict the entire scope of the project and execute it in one large process, while the adaptive approach recognizes that the project changes as the users and development team learn and so the project has to adapt during its lifecycle. Q: What is the standard type of predictive approach called? How does it work? A: The Waterfall model. One phase completes and the project team moves (falls) to the next phase. Q: What does incremental development mean? A: It means the system is developed in increments, also referred to as “growing” the system. Q: What is a walking skeleton? What does the name mean? A: It is a skeleton because it has very little functionality, i.e. very little “flesh.” It is walking because it can execute. Methodologies, Models, Tools, and Techniques Key Terms tool – a software application that assists developers in creating models or other components required for a project integrated development environments (IDEs) – a set of tools that work together to provide a comprehensive development and programming environment for software developers visual modeling tools – tools that help analysts create and verify graphical models and may also generate program code technique – guidelines to specify a method for how to carry out a development activity or task Lecture Notes Methodologies A system development methodology provides guidelines for every facet of the systems development life cycle. Some methodologies (whether built in-house or purchased) contain massive written documentation that defines everything the developers may need to produce at any point in the project. Other methodologies are much more informal. Models A model is a representation of an important aspect of the real world. Sometimes, the term abstraction is used because we abstract (separate out) an aspect that is of particular importance to us. The models used in system development include representations of inputs, outputs, processes, data, objects, object interactions, locations, networks, and devices, among other things. Most of the models are graphical models, which are drawn representations that employ agreed-upon symbols and conventions. Tools In the context of system development, a tool is software support that helps create models or other components required in the project, such as a drawing tool to create graphical models. Tools have been specifically designed to help system developers. Programmers should be familiar with integrated development environments (IDEs), which include many tools to help with programming tasks. Techniques In system development, a technique is a collection of guidelines that helps an analyst complete an activity or task. It often includes step-by-step instructions for creating a model, or it might include more general advice on collecting information from system users. A methodology includes a collection of techniques that are used to complete activities within each phase of the systems development life cycle. Quick Quiz Q: What is the difference between a methodology and a technique? A: A methodology covers the entire process of development and defines the appropriate techniques, models, and tools to be used. Q: What is the difference between a model and a tool? A: A model is an abstraction of the real world that is produced, often by a tool. Q: What is the difference between a technique and a tool? A: A technique explains the how to do something, where a tool is something that is used, possible as part of the technique. Agile Development Key Terms Agile development – a guiding philosophy and set of guidelines for developing information systems in an unknown, rapidly changing environment chaordic – a term used to describe adaptive projects that are chaotic and ordered Agile modeling (AM) – guiding philosophy in which only models that are necessary, with a valid need and at the right level of detail, are created Lecture Notes Agile development is a philosophy and set of guidelines for developing information systems in an unknown, rapidly changing environment, and it can be used with any system development methodology. Agile modeling is a philosophy about how to build models, some of which are formal and detailed, others sketchy and minimal. All the models in this text can be used with Agile modeling. Agile Development Philosophy and Values The Agile philosophy takes a flexible approach with project schedules and letting the project teams plan and execute their work as the project progresses. The core philosophy of Agile development includes: Value responding to change over following a plan Value individuals and interactions over processes and tools Value working software over comprehensive documentation Value customer collaboration over contract negotiation Some industry leaders in the Agile movement coined the term chaordic to describe an Agile project. Chaordic comes from two words: chaos and order. The Agile philosophy recognizes this unpredictability, handling it with increased flexibility and by trusting the project team to develop solutions to project problems. Another important aspect of Agile development is that customers must continually be involved with the project team. They don’t just sit down with the project team for a few sessions to develop the specifications. They become part of the technical team. Agile Modeling Principles Agile modeling (AM) isn’t about doing less modeling but about doing the right kind of modeling at the right level of detail for the right purposes. AM doesn’t dictate which models to build or how formal to make those models. Instead, it helps developers stay on track with their models by using them as a means to an end rather than end deliverables. The following Agile modeling principles indicate that building models is an essential technique for software development, but that the models are the means and not the ends. Develop Software as Your Primary Goal Enable the Next Effort as Your Secondary Goal Minimize Your Modeling Activity—Few and Simple Embrace Change, and Change Incrementally Model with a Purpose Build Multiple Models Build High-Quality Models and Get Feedback Rapidly Focus on Content Rather Than Representation Learn from Each Other with Open Communication Know Your Models and How to Use Them Adapt to Specific Project Needs Maximize Stakeholder ROI Quick Quiz Q: With which project methodology can you follow Agile modeling techniques? A: With either, predictive or adaptive. Q: With which project methodology does the Agile philosophy more closely follow? A: Adaptive projects tend to be more flexible and are more agile. Q: What are the four elements of the Agile philosophy? A: Value responding to change over following a plan; Value individuals and interactions over processes and tools; Value working software over comprehensive documentation; Value customer collaboration over contract negotiation. The Unified Process, Extreme Programming, and Scrum Key Terms UP discipline – a set of functionally related activities that combine to enable the development process in a UP project pair programming – XP practice in which two programmers work together on designing, coding, and testing software refactoring – revising, reorganizing, and rebuilding part of a system so it is of higher quality product backlog – a prioritized list of user requirements used to choose work to be done in a Scrum project product owner – the client stakeholder for whom the system is being built Scrum master – the person in charge of a Scrum project—similar to a project manager sprint – a time-controlled mini-project that implements a specific portion of a system Lecture Notes The Agile philosophy only proposes principles; it isn’t meant to be a complete methodology, with practices and action steps. This section presents three methodologies (UP, XP, and Scrum) that incorporate Agile principles, but are also complete methodologies, with specific techniques and practices. The Unified Process The Unified Process (UP) is an object-oriented system development methodology originally offered by Rational Software, which is now part of IBM. The UP is now widely recognized as a highly influential innovation in software development methodologies for object-oriented development using an adaptive approach. A UP phase can be thought of as a goal or major emphasis for a particular portion of the project. The four phases of the UP life cycle are inception, elaboration, construction, and transition, as shown in Figure 10-11. Inception – Develop an approximate vision of the system, make the business case, define the scope, and produce rough estimates for cost and schedule. Elaboration – Define the vision, identify and describe all requirements, finalize the scope, design and implement the core architecture and functions, resolve high risks, and produce realistic estimates for cost and schedule. Transition Complete the beta test and deployment so users have a working system and are ready to benefit as expected. Construction – Iteratively implement the remaining lower-risk, predictable, and easier elements and prepare for deployment. Transition – Complete the beta test and deployment so users have a working system and are ready to benefit as expected. The four UP phases define the project sequentially by indicating the emphasis of the project team at any point in time. To make iterative development manageable, the UP defines disciplines to use within each iteration. A UP discipline is a set of functionally related activities that contributes to one aspect of the development project. UP disciplines include business modeling, requirements, design, implementation, testing, deployment, configuration and change management, project management, and environment. Each iteration usually involves activities from all disciplines. The six main UP development disciplines are: Business modeling Requirements Design Implementation Testing Deployment Three additional support disciplines are necessary for planning and controlling the project: Configuration and change management Project management Environment Extreme Programming Extreme Programming (XP) is an adaptive, Agile development methodology that was created in the mid-1990s. The word extreme sometimes makes people think that this methodology is completely new and that developers who embrace XP are radicals. However, XP is really an attempt to take the best practices of software development and extend them “to the extreme.” Extreme programming has these characteristics: Takes proven industry best practices and focuses on them intensely Combines those best practices (in their most intense forms) in a new way to produce a result that is greater than the sum of its parts The four core values of XP—communication, simplicity, feedback, and courage—drive its practices and project activities. Communication. Effective communication involves not only documentation, but also verbal discussion. The practices and methods of XP are designed to ensure that open, frequent communication occurs. Simplicity. XP includes techniques to reinforce this principle and make it a standard way of developing systems. Feedback. Feedback on functionality and requirements should come from the users, feedback on designs and code should come from other developers, and feedback on satisfying a business need should come from the client. Courage. Developers always need courage to face the harsh choice of doing things right or throwing away bad code and starting over. XP’s 12 practices embody the basic values just presented. Planning – Based on user stories. Planning involves two aspects: business issues and technical issues. In XP, the business issues are decided by the users and clients, whereas technical issues are decided by the development team. Testing – Every new piece of software requires testing, and every methodology includes testing. XP intensifies testing by requiring that the tests for each story be written first—before the solution is programmed. Pair Programming – More than any other, this practice is one for which XP is famous. First, one programmer might focus more on design and double-checking the algorithms while the other writes the code. Then, they switch roles. Simple designs Refactoring the code – Before and after adding any new functions, XP programmers review their code to see whether there is a simpler design or a simpler method of achieving the same result. Owning the code collectively – In XP, everyone is responsible for the code. Continuous integration – This practice embodies XP’s idea of “growing” the software. Small pieces of code—which have passed the unit tests—are integrated into the system daily or even more often. On-site customer System metaphor – This practice is XP’s unique and interesting approach to defining an architectural vision. It answers the questions “How does the system work?” and “What are its major components?” And it does it by having the developers identify a metaphor for the system. Small releases Forty-hour week Coding standards Figure 10-16 shows an overview of the XP Project Activities for the system development approach. It is divided into three levels: system (the outer ring), release (the middle ring), and iteration (the inner ring). System-level activities occur once during each development project. The first XP development activity is creating user stories, which are similar to use cases in object-oriented analysis. The first release-level activity is planning a series of iterations. Each iteration focuses on a small (possibly just one) system function or user story. When an iteration passes integration testing, work begins on the next iteration. Scrum Those of you who are familiar with rugby are aware that when a team gets possession of the ball, it attempts to go the entire distance in one continuous play—from point of possession to the score. Combining some of these principles of rugby with the Agile philosophy gave rise to a methodology—the objective of which is to be quick, agile, and intense and to go the entire distance. The basic control mechanism for a Scrum project is a list of all the things the system should include and address. This list—called the product backlog includes user functions (such as use cases), features (such as security), and technology (such as platforms). The product backlog list is continually being prioritized, and only a few of the high-priority items are worked on at a time, according to the current needs of the project and its sponsor. The three main organizational elements that affect a Scrum project are the product owner, the Scrum master, and the Scrum team or teams. The product owner is the client, but he or she has additional responsibilities. Remember that in Agile development, the user and client are closely involved in the project. In Scrum, the product owner maintains the product backlog list. The Scrum master enforces Scrum practices and helps the team complete its work. A Scrum master is comparable to a project manager in other approaches. However, because the team is self-organizing and no overall project schedule exists, the Scrum master’s duties are slightly different. He or she is the focal point for communication and progress reporting. In other words, the Scrum master is a facilitator. The Scrum practices are the mechanics of how a project progresses. The basic work process is called a sprint, and all other practices are focused on supporting a sprint. Every day during the sprint, the Scrum master holds a daily Scrum, which is a meeting of all members of the team. The objective is to report progress. The meeting is limited to 15 minutes or some other short time period. Members of the team answer only three questions: What have you done since the last daily Scrum (during the last 24 hours)? What will you do by the next daily Scrum? What kept you or is keeping you from completing your work? Quick Quiz Q: What are the four UP Phases? What do they represent? A: Inception, Elaboration, Construction, Transition. They represent a “focus” during that part of the project. For example, inception is how to get things started. Q: What are UP Disciplines? What are the six primary disciplines? What are the three project control disciplines? A: The UP disciplines are the related activities that carry out the activities of the projects The six primary disciplines are business modeling defining requirements, design, implementation, testing, and deployment. The three project control disciplines are Configuration, project management, and environment. Q: What does XP stand for? What are the four core values for XP? A: XP means Extreme Programming. The four core values are Communication, Simplicity, Feedback, and Courage. Q: Explain how pair programming works. A: Pair programing is where two programmers work together to design and program a part of the system. One programmer will work on design while the other writes code. Then they change. They also check each other’s work and provide assistance to each other. Q: What is a Scrum sprint? What is the primary purpose of a sprint? A: A Scrum sprint is a front to back development and programming period whose purpose is to finish (i.e. produce working code) a portion of the system. Its purpose is to produce working code. Q: What is a product backlog? Who maintains it? A: The product backlog is the list of items that need to be completed. It is maintain by the product owner, which is usually a client person. Classroom Activities This little activity will help students think about an SDLC. If you have formed teams, have the students do the activity in their teams. If not, just have work in groups of two, three, or four. Another way may be to have teams from half the class try to do a predictive project p;an and the other half try to do an adaptive, iterative project plan. The college has just started a new Masters of Information Systems program, and you need to develop a brochure to help recruit new students. 1. You are in charge. This is a project. You are assigned as a team leader or Project Manager. Consider that you are helping put together a team and project. Who do you need on your team? 2. Layout a project plan – identifying tasks and participants Do not worry about schedule. 3. Class discussion as a whole – Did you use predictive or adaptive? What is the difference? When would you use predictive, when adaptive? Some combination. 4. Back in groups – rework your schedule, thinking about Phases, Iterations and Disciplines. Try to organize tasks somewhat in order (phases) Look at schedules again. Think about disciplines and iterations. Troubleshooting Tips Use the correct terms and force the students to use the correct terms when they ask questions. Like any discipline, if you do not understand and use the vocabulary, you can never converse intelligently about the subject matter. Students will frequently have difficulty understanding the differences between a model and a tool. They also may confuse the terms methodology, technique, and approach. This material needs to be carefully presented with clear examples. (Notice we did not use the term “method” because it can cause more confusion between methodology and technique.) Sometimes students think that Agile development means “code and fix” without any in-depth analysis or design. They also think that Agile development means that it is unnecessary to develop any models, or that modeling does not need to be done correctly. You will need to emphasize the importance of models to capture decisions, understand the requirements, and think thoroughly about solutions. Discussion Questions 1. The need for a development methodology Many students will have developed some applications for themselves or for some simple mobile app. Some may even have developed larger systems. In many cases, the students have done this without any type of formal development methodology. You can have an interesting discussion about the importance and usefulness of a development methodology. If you have developed software, did you use a development methodology? If so what kind of methodology? 1. Organization and Structure: Development methodologies provide a structured framework for organizing project activities, tasks, and resources. This helps teams stay focused and coordinated throughout the development process, reducing confusion and ensuring everyone is on the same page. 2. Efficiency and Productivity: By following a development methodology, teams can streamline their development processes, identify potential bottlenecks, and allocate resources more effectively. This can lead to improved productivity, faster delivery times, and higher quality software. 3. Risk Management: Development methodologies often include risk management processes that help teams identify and mitigate potential risks and uncertainties early in the project lifecycle. This proactive approach can minimize the impact of unexpected issues and ensure projects stay on track. 4. Quality Assurance: Many development methodologies emphasize quality assurance practices such as code reviews, testing, and validation. By incorporating these practices into the development process, teams can identify and address defects and issues early, resulting in higher quality software. 5. Client Satisfaction: Development methodologies often involve client collaboration and feedback loops, ensuring that the final product meets the client's expectations and requirements. This iterative approach can lead to higher client satisfaction and increased likelihood of project success. 6. Scalability and Flexibility: Development methodologies can be tailored to suit the specific needs and constraints of different projects, teams, and organizations. This flexibility allows teams to adapt their processes to accommodate changing requirements, technologies, and project scopes. 7. Documentation and Knowledge Sharing: Many development methodologies emphasize the importance of documentation and knowledge sharing, ensuring that important project information, decisions, and lessons learned are captured and shared across the team. This promotes transparency, accountability, and continuous improvement. As for specific methodologies, there are several popular ones, including Agile, Scrum, Waterfall, Kanban, and DevOps, each with its own principles, practices, and methodologies. The choice of methodology depends on factors such as project requirements, team size, organizational culture, and client preferences. Ultimately, the goal of any development methodology is to help teams deliver high-quality software products efficiently and effectively. If you did not use a development methodology did you do planning, analysis, design, construction? In other words, even though you did not formally identify different activities, did you in fact do them? Would it have been helpful to have a more organized approach? What were the problems you encountered? Did you do enough analysis? Enough design? Enough planning? Even if a formal development methodology wasn't explicitly followed, it's likely that some level of planning, analysis, design, and construction occurred during the software development process. These activities are essential components of the software development lifecycle and are typically inherent in the development process, regardless of whether a formal methodology is followed. However, without a structured and organized approach, there may have been challenges in effectively managing the development process. Some potential problems encountered without a formal methodology could include: 1. Lack of Clear Direction: Without formal planning and analysis, there may have been ambiguity regarding project goals, requirements, and timelines, leading to confusion and inefficiencies during development. 2. Inadequate Analysis: Insufficient analysis may have resulted in incomplete or inaccurate understanding of user needs and requirements, leading to the development of software that doesn't fully meet user expectations. 3. Insufficient Design: Without proper design planning, there may have been a lack of clarity in system architecture, interface design, and data structures, potentially leading to scalability, performance, and usability issues in the software. 4. Poor Resource Management: Without formal planning and resource allocation, there may have been challenges in managing human and material resources effectively, leading to delays, budget overruns, and resource constraints. 5. Limited Quality Assurance: Without formal testing and quality assurance processes, there may have been inadequate testing coverage, resulting in undetected bugs, errors, and inconsistencies in the software. 6. Lack of Documentation: Without formal documentation practices, important project information, decisions, and design rationale may not have been adequately documented, leading to challenges in maintenance, troubleshooting, and knowledge transfer. In retrospect, following a more organized and structured approach, such as Agile, Waterfall, or Scrum, could have helped address these challenges and improve the overall efficiency and effectiveness of the development process. These methodologies provide frameworks for systematic planning, analysis, design, and construction, as well as mechanisms for iterative development, continuous improvement, and stakeholder collaboration. Overall, while some level of development activities likely occurred without a formal methodology, adopting a more organized approach could have helped mitigate challenges, improve project outcomes, and ensure the successful delivery of high-quality software products. If you did use a development methodology, how well was it executed? Was it helpful? Did it cause problems or slow down the development activities? Was there a project manager or leader? Did he/she help or hinder? How much time was spent in overhead activities such as meetings? Was the project formality too much? Too little? A help or a hindrance? The effectiveness of a development methodology depends on various factors such as the project's complexity, team dynamics, adherence to the methodology, and leadership. Here are some considerations regarding the execution and impact of development methodologies: 1. Execution and Effectiveness: • The execution of a development methodology can vary depending on the team's understanding and commitment to following its principles and practices. • If properly executed, a development methodology can provide structure, clarity, and guidance throughout the project lifecycle, leading to improved communication, collaboration, and project outcomes. 2. Helpfulness: • A well-executed development methodology can be highly beneficial by facilitating planning, prioritization, and risk management, as well as ensuring alignment with project goals and stakeholder expectations. • It can help teams stay on track, manage changes effectively, and deliver high-quality software products within budget and timeline constraints. 3. Challenges and Problems: • Poor execution of a development methodology or resistance to change can lead to challenges and problems such as scope creep, delays, and miscommunication. • In some cases, rigid adherence to a methodology without considering project-specific needs or feedback from team members can hinder flexibility and innovation. 4. Project Manager or Leader: • The presence of a project manager or leader is often beneficial in guiding the team and ensuring adherence to the development methodology. • A skilled project manager can facilitate communication, resolve conflicts, and provide direction, thereby enhancing the effectiveness of the methodology. 5. Overhead Activities and Formality: • Meetings and other overhead activities are essential components of many development methodologies, serving as opportunities for planning, review, and collaboration. • While excessive meetings or formalities can be counterproductive, a balanced approach that focuses on value-driven activities and minimizes unnecessary bureaucracy is ideal. 6. Balancing Formality: • The level of formality required by a development methodology should be tailored to the project's needs, team dynamics, and organizational culture. • Too much formality can lead to bureaucracy and inefficiency, while too little can result in chaos and lack of accountability. Striking the right balance is key to maximizing the benefits of the methodology. Overall, the success of a development methodology depends on how well it is executed, its alignment with project goals and team dynamics, and the effectiveness of project leadership. When implemented thoughtfully and adapted to meet the project's specific needs, a development methodology can significantly contribute to project success and the delivery of high-quality software products. How does the size of the project team affect the need for a development methodology? How does it affect the formality of the methodology? (formal meetings versus around the water cooler meetings). The size of the project team can significantly impact the need for a development methodology and the formality of its implementation. Here's how: 1. Need for Development Methodology: • Smaller Teams: Smaller project teams may have less complexity and fewer communication challenges compared to larger teams. In some cases, small teams may be able to manage projects effectively without a formal development methodology. They might rely on informal communication, ad-hoc decision-making, and individual accountability to drive progress. • Larger Teams: Larger project teams typically involve more stakeholders, diverse skill sets, and complex interdependencies. As a result, the need for a formal development methodology becomes more apparent. A methodology provides structure, guidelines, and processes to ensure effective coordination, collaboration, and alignment among team members. 2. Formality of the Methodology: • Smaller Teams: With smaller teams, there may be greater flexibility in the formality of the development methodology. Informal communication channels such as "water cooler" meetings, informal discussions, and quick ad-hoc decisions may suffice for smaller teams. Formal meetings and documentation may be less necessary, and teams may prioritize agility and responsiveness over strict adherence to formal processes. • Larger Teams: In contrast, larger teams require more structured and formalized processes to ensure clear communication, coordination, and accountability. Formal meetings, documentation, and standardized workflows become essential for managing complexity, ensuring consistency, and mitigating risks associated with miscommunication or lack of coordination. In summary, the size of the project team influences the need for a development methodology and the level of formality required in its implementation. Smaller teams may have greater flexibility and may be able to rely on informal communication channels, while larger teams necessitate more structured and formalized processes to ensure effective collaboration and project management. Ultimately, the choice of methodology and its formality should align with the project's size, complexity, goals, and team dynamics to maximize project success. 2. The need for models and modeling As with the first question, students who have developed software will probably not have used any models or done any modeling. You can have an interesting discussion about the need for models and modeling. Is it important to build models? Can you develop a system just as well without any models? Building models is crucial in the software development process, as they serve as blueprints that guide the development of complex systems. While it's possible to develop a system without explicitly creating models, doing so can introduce several risks and challenges: 1. Complexity Management: Models help simplify the understanding of complex systems by breaking them down into manageable components. Without models, developers may struggle to grasp the system's architecture, leading to confusion and inefficiency during development. 2. Communication and Collaboration: Models provide a common language for stakeholders to communicate and collaborate effectively. They serve as visual representations that facilitate discussions, clarify requirements, and align expectations among team members, clients, and other stakeholders. 3. Requirement Analysis: Models help capture and analyze system requirements, ensuring that stakeholders' needs and expectations are accurately documented and understood. Without models, requirements may be vague, incomplete, or misunderstood, leading to costly rework and dissatisfaction among stakeholders. 4. Design and Planning: Models aid in system design and planning by visualizing the system's structure, behavior, and interactions. They enable developers to explore alternative design solutions, identify potential risks and bottlenecks, and make informed decisions early in the development process. 5. Validation and Verification: Models support validation and verification activities by enabling stakeholders to simulate and test system behavior before implementation. They help detect errors, inconsistencies, and ambiguities in requirements and design, reducing the likelihood of defects and ensuring system reliability and quality. 6. Documentation: Models serve as documentation artifacts that capture important design decisions, rationale, and dependencies. They provide a valuable reference for developers, maintainers, and other stakeholders throughout the system's lifecycle, facilitating maintenance, troubleshooting, and knowledge transfer. In summary, while it may be possible to develop a system without explicitly building models, doing so introduces significant risks and challenges related to complexity management, communication, requirement analysis, design, validation, and documentation. Models play a vital role in guiding and supporting the software development process, enabling teams to build robust, scalable, and high-quality systems that meet stakeholders' needs and expectations. If you developed a software system did you have problems that could have been resolved more easily with some models? Did you do any rework because you had not completely thought through the problem (analysis) or the solution (design)? 1. Incomplete Understanding of Requirements: Without thorough analysis and modeling of system requirements, there may be ambiguity or misunderstanding regarding stakeholder needs and expectations. As a result, developers may implement features or functionalities that do not align with user requirements, leading to rework and dissatisfaction among stakeholders. 2. Inadequate Design Planning: Without proper design modeling, developers may face challenges in defining the system architecture, data structures, and interfaces. This can result in suboptimal design decisions, inefficient code structures, and difficulty in accommodating future changes or enhancements, necessitating rework to address design flaws. 3. Lack of Communication and Collaboration: In the absence of models, communication and collaboration among team members and stakeholders may suffer. Models serve as visual representations that facilitate discussions, clarify requirements, and align expectations. Without models, misunderstandings may arise, leading to misinterpretation of requirements and design decisions, which could result in rework to rectify discrepancies. 4. Validation and Verification Issues: Without models to simulate and test system behavior, it may be challenging to identify and address errors, inconsistencies, and usability issues early in the development process. As a result, developers may encounter difficulties in validating and verifying the system against stakeholder expectations, leading to rework to resolve defects and improve system quality. Overall, the use of models can help mitigate these challenges by providing a structured approach to requirement analysis, design planning, communication, and validation. By investing time and effort in developing models upfront, software development teams can minimize the risk of rework and ensure that the final product meets stakeholder needs and expectations effectively. When is it important to save the models you have developed? Then when is it important to make the models more formal so that they remain? How long should models be maintained or kept? 1. Documentation and Reference: Models serve as documentation artifacts that capture important design decisions, requirements, and system architecture. Saving these models allows team members to reference them for understanding, troubleshooting, and maintaining the software system in the future. 2. Change Management: Models provide a baseline for managing changes to the software system. By saving models, developers can track changes made to the system over time, analyze their impact, and ensure that modifications are implemented in a controlled and systematic manner. 3. Knowledge Preservation: Models capture valuable knowledge and insights gained during the development process. Saving these models preserves institutional knowledge within the organization, ensuring that critical information is retained even if team members leave or transition to other projects. 4. Compliance and Auditing: In regulated industries or environments where compliance with standards and regulations is required, saving models is essential for demonstrating adherence to guidelines and facilitating auditing and compliance activities. As for when it's important to make the models more formal: 1. Critical Milestones: Formalizing models becomes particularly important at critical milestones in the software development lifecycle, such as project initiation, requirements elicitation, and design reviews. Formal models help ensure that key decisions and requirements are documented, reviewed, and approved by relevant stakeholders. 2. Handover and Transition: When transitioning from one phase of the project to another or when handing over the project to another team, formalizing models helps ensure continuity and clarity. Formal models provide a clear representation of the current state of the system and facilitate knowledge transfer to new team members. Regarding how long models should be maintained or kept: 1. Throughout the Lifecycle: Models should be maintained and kept throughout the entire lifecycle of the software system, from inception to retirement. They serve as valuable artifacts that guide development, support decision-making, and facilitate maintenance and evolution of the system. 2. As Long as Needed: The duration for which models should be maintained depends on factors such as the complexity of the system, regulatory requirements, organizational policies, and the system's lifespan. In some cases, models may need to be retained indefinitely to support ongoing maintenance, upgrades, and compliance activities. 3. Regular Review and Update: Models should be periodically reviewed and updated to ensure their accuracy, relevance, and alignment with the evolving needs of the project and organization. Outdated or obsolete models should be archived or replaced with updated versions to maintain their usefulness and effectiveness over time. Which models might be most helpful? Analysis (understanding) models or Design (solution) models? Analysis Models vs. Design Models: • Analysis Models: Analysis models focus on understanding the problem domain, capturing requirements, and defining the scope of the system. They help stakeholders visualize and articulate their needs, clarify ambiguities, and ensure alignment between the proposed solution and user expectations. Analysis models, such as use case diagrams, data flow diagrams, and entity-relationship diagrams, are particularly helpful during the early stages of the project when gathering and analyzing requirements. • Design Models: Design models, on the other hand, focus on defining the solution architecture, specifying system components, and detailing implementation details. They translate requirements into concrete designs, providing blueprints for developers to follow during implementation. Design models, such as class diagrams, sequence diagrams, and architectural diagrams, are most helpful during the later stages of the project when planning and executing the development process. How does the size of the project team affect the modeling requirements? Impact of Project Team Size on Modeling Requirements: • Small Teams: In smaller project teams, where communication is more direct and informal, the modeling requirements may be less stringent. Team members may rely more on informal discussions and ad-hoc documentation to communicate ideas and requirements. However, clear and concise modeling can still be valuable for ensuring a shared understanding among team members and stakeholders. • Large Teams: In larger project teams, where coordination and collaboration are more complex, formalized modeling becomes crucial. Formal models help standardize communication, clarify requirements, and facilitate alignment among diverse stakeholders. Larger teams often require more structured documentation and modeling practices to ensure consistency and coherence across different work streams. How does the size of the solution system affect the need for models? Impact of Solution System Size on Modeling Needs: • Small Solution Systems: For smaller solution systems with limited complexity, the modeling needs may be relatively straightforward. Simple, high-level models may suffice to capture essential requirements and guide the development process. Agile approaches, with their emphasis on iterative development and minimal documentation, may be more suitable for smaller systems. • Large Solution Systems: In contrast, larger solution systems with greater complexity require more comprehensive and detailed modeling. Detailed analysis and design models are necessary to capture the intricacies of the system architecture, functionality, and interactions. Formal modeling practices, such as structured analysis and design methodologies, may be necessary to manage the complexity and ensure the robustness and scalability of the solution. Instructor Manual for Systems Analysis and Design in a Changing World John W. Satzinger, Robert B. Jackson, Stephen D. Burd 9781305117204, 9781111951641