Ch2 SW Processes.pdf

Chapter 2 – Software Processes Chapter 2 Software Processes 1 Topics covered ✧ Software process models ✧ Process activities ✧ Planned vs Agile processes ✧ Process Models: ▪ Waterfall ▪ Incremental & Iterative ▪ Integration and configuration...

Chapter 2 – Software Processes Chapter 2 Software Processes 1 Topics covered ✧ Software process models ✧ Process activities ✧ Planned vs Agile processes ✧ Process Models: ▪ Waterfall ▪ Incremental & Iterative ▪ Integration and configuration Chapter 2 Software Processes 2 The Challenges of Software Engineering ✧ Writing code is easy; engineering good software is HARD. ✧ The biggest challenge? Humans. Customers with changing needs and unclear requirements. Developers with varying skills and interpretations. Managers balancing resources, timelines, and goals ✧ Large software systems tend to take on a life of their own ✧ Even with just a few people involved, complications multiply quickly, including customer expectations! 3 The Importance of Following a Process ✧ A well-defined, well-understood, and repeatable software development process is key to success. Facilitates technical decision-making: What to deliver: Define the product features and functionality. When to deliver: Set realistic milestones and deadlines. How to deliver: Choose the right tools, methods, and technologies. Planning and Scheduling: Establish timelines for all activities. Improves management: Accurately estimate time and cost. Track progress and completion of tasks. Detect delays and adjust plans effectively. Helps identify and repeat good practices. Simplifies onboarding for new team members. 4 The software process ✧ A structured set of activities required to develop a software system. ✧ Many different software processes but all involve: ▪ Specification – defining what the system should do; ▪ Design and implementation – defining the organization of the system and implementing the system; ▪ Validation – checking that it does what the customer wants; ▪ Evolution – changing the system in response to changing customer needs. ✧ A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. Chapter 2 Software Processes 5 Software Process Model ✧ A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. ▪ A process in the context of software engineering refers to the actual series of steps or activities involved in developing software. It is the real, concrete actions that need to be performed to produce a working software system. ▪ A software process model is an abstract representation of that actual process. It is a template or a guide that suggests a certain way to organize and perform the software development activities. 6 Software process descriptions ✧ When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities. ✧ Process descriptions may also include: ▪ Products, which are the outcomes of a process activity; ▪ Roles, which reflect the responsibilities of the people involved in the process; ▪ Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced. Chapter 2 Software Processes 7 Plan-driven and agile processes ✧ Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. ✧ In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. ✧ In practice, most practical processes include elements of both plan-driven and agile approaches. ✧ There are no right or wrong software processes. Chapter 2 Software Processes 8 Plan-driven processes ✧ After collecting the requirements, we create a comprehensive plan that covers various aspects of the software development process: ▪ Time Estimation: We estimate how long each step or phase of the development process will take. ▪ Effort and Resources: We estimate the amount of effort needed for each task, often measured in person-hours or person-days. ▪ Activities and Tasks: We break down the entire project into specific tasks and activities. ▪ Deliverables ▪ Budget and Cost ▪ Risk Management ▪ Quality Assurance 9 Plan-driven and agile processes source: https://link.springer.com/article/10.1186/1687-3963-2013-15 Chapter 2 Software Processes 10 Agile processes ✧ In an Agile-based approach, planning is done in a more flexible, adaptive, and incremental way. It focuses on short-term planning and continuous adjustment based on feedback and changing needs. Overall Vision: At the beginning, the team establishes a high-level vision or goal: understanding the core purpose of the project, the key features, and the primary objectives. However, this is not a detailed plan; it’s a broad understanding of what the final product should achieve. Short-Term Planning (Sprints): At the start of each sprint, the team plans only the tasks and features that will be developed during that sprint. This means they focus on a small, manageable set of work that can be completed quickly. Continuous Replanning: After each sprint, the team reviews what has been accomplished and gathers feedback from stakeholders (like customers or users). Based on this feedback, they adjust the plan for the next sprint. This could mean changing priorities, adding new features, or modifying existing ones. 11 Plan-driven and agile processes Chapter 2 Software Processes 12 Plan-driven and agile processes source: https://twitter.com/MarcHemerik/status/657516180442320897?s=20 Chapter 2 Software Processes 13  Plan-driven and agile processes ✧ Ease of Change! cost Plan-based Agile-based time Chapter 2 Software Processes 14 Question 1 ✧ A Medical Records Management System for a Hospital. ▪ This system needs to handle sensitive patient data, comply with strict regulatory standards, and integrate with existing hospital systems. ✧ Would you choose a Plan-Driven approach or an Agile approach for this project? Why? 15 Question 1 ✧ A Medical Records Management System for a Hospital. ▪ This system needs to handle sensitive patient data, comply with strict regulatory standards, and integrate with existing hospital systems. Answer: Plan-Driven would be a better choice! ▪ Handles sensitive patient data and must comply with strict regulatory standards (e.g., HIPAA, GDPR). ▪ Requirements are stable and well-defined, guided by laws and hospital policies. ▪ Requires a structured approach for integration and interoperability with existing systems. ▪ Plan-Driven approach ensures thorough planning, documentation, and minimizes risks of data breaches and compliance issues. 16 Question 2 ✧ A New Social Media App for College Students ▪ This app aims to connect students across different campuses with features for messaging, sharing, and group activities. The requirements might change frequently based on user feedback and market trends. ✧ Would you choose a Plan-Driven approach or an Agile approach for this project? Why? 17 Question 2 ✧ A New Social Media App for College Students ▪ This app aims to connect students across different campuses with features for messaging, sharing, and group activities. The requirements might change frequently based on user feedback and market trends. Agile ✧ The app's features will evolve with user feedback, market trends, and competitive needs. ✧ Frequent changes in requirements demand flexibility to quickly adapt and add new features. ✧ Agile enables iterative development, allowing for building, testing, and releasing new features incrementally. ✧ Agile's fast-paced cycle helps the app stay relevant and engaging for users. 18 Question 3 ✧ An AI-Based Chatbot for Customer Service ▪ The chatbot should continuously learn from customer interactions, evolve with new features, and quickly adapt to changing customer needs. ✧ Would you choose a Plan-Driven approach or an Agile approach for this project? Why? 19 Question 3 ✧ An AI-Based Chatbot for Customer Service ▪ The chatbot should continuously learn from customer interactions, evolve with new features, and quickly adapt to changing customer needs. ✧ Agile ✧ The chatbot must continuously learn from customer interactions and adapt to new behaviors and questions. ✧ AI feature requirements will evolve as the team gains insights from user interactions. ✧ Agile enables frequent updates and iterations, improving functionality, accuracy, and user experience. ✧ Agile is ideal for integrating new AI models and testing them in real- world scenarios, ensuring adaptability to changes. 20 Software process models Chapter 2 Software Processes 21 Software process models ✧ The waterfall model ▪ Plan-driven model. Separate and distinct phases of specification and development. ✧ Incremental development ▪ Specification, development and validation are interleaved. May be plan-driven or agile. ✧ Integration and configuration ▪ The system is assembled from existing configurable components. May be plan-driven or agile. ✧ In practice, most large systems are developed using a process that incorporates elements from all of these models. Chapter 2 Software Processes 22 The waterfall model Chapter 2 Software Processes 23 1- Waterfall model phases ✧ There are separate identified phases in the waterfall model: ▪ Requirements analysis and definition ▪ System and software design ▪ Implementation and unit testing ▪ Integration and system testing ▪ Operation and maintenance ✧ Example ▪ Building a house! Construction ▪ Creating a website Chapter 2 Software Processes 24 Pothole example Chapter 2 Software Processes 25 Waterfall model problems ✧ Inflexible partitioning of the project into distinct phases. ▪ Difficult to respond to changing customer requirements ✧ Feedbacks come very late and changes can be expensive Chapter 2 Software Processes 26 Inflexible project partitioning ✧ Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. ▪ Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. ▪ Few business systems have stable requirements. Chapter 2 Software Processes 27 Expensive change requests ✧ Feedbacks come very late and changes can be expensive Chapter 2 Software Processes 28 Waterfall model summary ✧ Cons: ▪ Inflexible partitioning of the project into distinct phases. ▪ Difficult to respond to changing customer requirements ▪ Feedbacks come very late and changes can be expensive ✧ Pros: ▪ Easily manageable process ▪ The most effective method, if requirements are known ▪ Extensive documentation ✧ Is it used in: ▪ Projects where the requirements are well understood. Clearly definable projects ▪ Safety critical projects that need extensive documents Chapter 2 Software Processes 29 One more thing! ✧ The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. ▪ In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work. Chapter 2 Software Processes 30 2- Incremental Model Chapter 2 Software Processes 31 Incremental development Chapter 2 Software Processes 32 Incremental development 30/10/2014 Chapter 2 Software Processes 33 Pothole example! ✧ Planned incremental Chapter 2 Software Processes 34 Pothole example! ✧ Iterative approach! Chapter 2 Software Processes 35 Pothole example! ✧ Agile incremental (Incremental & Iterative approach!) Chapter 2 Software Processes 36 Incremental development benefits ✧ More rapid delivery and deployment of useful software to the customer is possible. ▪ Customers can use and gain value from the software earlier than is possible with a waterfall process. ✧ Early increments act as a prototype to help ▪ Elicit requirements for later increments ▪ Get feedback on system performance ▪ Final product better matches true customer needs Lower risk of overall project failure Job satisfaction is increased for developers who can see early results of their work – Can see how much has been implemented Chapter 2 Software Processes 37 Incremental development problems ✧ The process is not visible. ▪ Can be harder to plan and control than waterfall development ▪ Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. ✧ Can be more expensive than waterfall development ▪ May require more experienced staff and specialized skills and tools ▪ Higher management overhead ▪ Rework and revisions ▪ Increased Testing Efforts ▪ Scope creep ▪ System architecture must be adaptive to change ▪ System structure tends to degrade as new increments are added. Chapter 2 Software Processes 38 3- Integration and configuration ✧ Based on software reuse where systems are integrated from existing components or application systems (sometimes called COTS -Commercial-off-the-shelf) systems). ✧ Reused elements may be configured to adapt their behaviour and functionality to a user’s requirements ✧ Reuse is now the standard approach for building many types of business system ▪ Reuse covered in more depth in Chapter 15. Chapter 2 Software Processes 39 Types of reusable software ✧ Stand-alone application systems (sometimes called COTS) that are configured for use in a particular environment. ✧ Collections of objects that are developed as a package to be integrated with a component framework such as.NET or J2EE. ✧ Web services that are developed according to service standards and which are available for remote invocation. Chapter 2 Software Processes 40 Reuse-oriented software engineering Chapter 2 Software Processes 41 Key process stages ✧ Requirements specification ✧ Software discovery and evaluation ✧ Look for existing software components, libraries, frameworks, or entire systems ✧ Requirements refinement ✧ Based on the evaluation, the original requirements may be refined or adjusted. ✧ Application system configuration ✧ Setting parameters, customizing features, or other adjustments ✧ Component adaptation and integration ✧ This adaptation could involve modifying the code, extending functionality, or integrating the components with other parts of the system. Chapter 2 Software Processes 42 Advantages and disadvantages ✧ Reduced costs and risks as less software is developed from scratch ✧ Faster delivery and deployment of system ✧ But requirements compromises are inevitable so system may not meet real needs of users Chapter 2 Software Processes 43 Question 1 ✧ How would you design and develop a new AI-Based Learning Management System like Brightspace using both the Waterfall (plan-driven) method and the Agile (incremental/iterative) method? ▪ What steps would each approach involve, and what are the pros and cons of each method for this type of project? 44 Answer: 1- Waterfall - Steps ✧ Requirements Gathering: ▪ Collect all features and requirements upfront (course management, assignment submission, grading tools, etc.). ✧ Design Phase: ▪ Create a detailed design of the system architecture, user interfaces, and database structures. ✧ Implementation Phase: ▪ Develop the software according to the design, one module at a time (e.g., build user login, then course management, etc.). 45 Answer: Waterfall - Steps (cntd) ✧ Testing Phase: ▪ Perform comprehensive testing of the entire system to identify and fix any issues. ✧ Deployment: ▪ Deploy the fully developed LMS to the university’s servers or cloud environment. ✧ Maintenance: ▪ Address any bugs or issues found after deployment, but major changes require starting the process again. 46 Answer: Waterfall Pros & Cons ✧ Advantages: Clear Structure: a clear, structured process with well-defined stages, which makes it easy to manage and track progress. Predictability: easier to estimate time and cost. Suitable for Stable Requirements: works well if all requirements are clear and unlikely to change. ✧ Disadvantages: Inflexibility: difficult to make changes once a phase is completed. If the stakeholders request new features or modifications, it can be costly and time-consuming to go back and make changes. Late Feedback: Users only see the final product after all phases are completed, which means there’s a risk of building something that doesn’t fully meet their needs. 47 Answer: 2- Agile (Incremental & Iterative), Steps ✧ Incremental Planning: ▪ Instead of collecting all requirements upfront, we begin with a basic set of features, such as a simple course management module, and plan to develop them in short cycles or "sprints.“ ✧ Develop Small Increments: In the first sprint, we might build the core functionality of managing courses. ▪ In the next sprint, we could add assignment submission features. ▪ Each increment adds a small part of the system, and the product grows gradually. 48 Answer: 2- Agile (Incremental & Iterative) Steps ✧ Continuous Feedback: After each sprint, we release a functional version of the LMS to stakeholders (e.g., faculty or a small group of students) and gather feedback. ✧ Adapt and Evolve: Use feedback to prioritize and plan the next set of features or improvements. For example, if users find the interface confusing, the next sprint may focus on improving usability. ✧ Frequent Releases: New features or updates are released frequently, allowing users to experience improvements sooner. 49 Answer: 2- Agile, Pros & Cons Advantages: Flexibility and Adaptation: The Agile approach allows the team to respond quickly to changes in requirements or user feedback. Continuous Improvement: Regular feedback helps ensure the product aligns with user needs, reducing the risk of developing unwanted features. Early and Frequent Deliverables: Users start using parts of the system early, which helps in gaining trust and identifying issues sooner. 50 Answer: 2- Agile, Pros & Cons Disadvantages: Unpredictable Timeline and Cost: Because requirements can change, it can be harder to predict the total time and cost for the entire project. Requires Constant Collaboration: Agile needs frequent communication and collaboration among team members and stakeholders, which can be challenging to maintain. 51 Answer: Comparison Key Differences: The Waterfall approach requires everything to be planned out in detail upfront, which can be great for projects with very clear, unchanging requirements. The Agile approach focuses on flexibility and quick iterations, which is ideal for projects where requirements are likely to change or are not fully understood from the start. 52 Answer: Comparison Most Effective Approach: For a project like an AI-based LMS, which is complex and likely to evolve based on user needs, an Agile approach might be more effective. It allows for frequent updates and adjustments based on actual user feedback. However, a combination of both might be ideal: Initial planning for core features (Waterfall) followed by Agile iterations for additional enhancements and adjustments. This way, you benefit from the structure and predictability of Waterfall for foundational elements, while using Agile for flexibility and continuous improvement. 53 Answer: 3- Integration and Configuration Step 1: Identify Requirements and Components Requirements Gathering: Start by collecting the key features needed for the LMS (e.g., course management, assignment submission, grading, AI- driven analytics). Identify Existing Components: Search for reusable software components, open-source libraries, or third- party tools that can meet these requirements (e.g., Turnitin for plagiarism detection, a cloud-based analytics tool, etc.). 54 Answer: 3- Integration and Configuration Step 2: Component Selection Evaluation: Assess potential components based on compatibility, licensing, cost, ease of integration, and scalability. Selection: Choose the best components that align with your system architecture and meet the LMS's needs. Step 3: Design and Planning ✧ System Architecture: Design how the selected components will be integrated into a cohesive system. ✧ Interfaces and Protocols: Define the communication protocols and interfaces between components to ensure smooth data exchange. 55 Answer: 3- Integration and Configuration Step 4: Integration Component Integration: Begin integrating the selected components according to the system architecture. Configuration: Customize and configure each component to meet specific LMS requirements, such as user interface adjustments and permission settings. Step 5: Testing Integration Testing: Perform testing to ensure that all components work together seamlessly and meet the functional requirements. User Acceptance Testing: Validate that the system meets user expectations and requirements. 56 Answer: 3- Integration and Configuration Step 6: Deployment System Deployment: Deploy the fully integrated LMS to the target environment (e.g., university servers or cloud). Ongoing Maintenance: Regularly update and maintain the integrated components, ensuring they remain compatible and functional 57 Question 2 ✧ Can the Integration and Configuration method be used with both plan-based and agile approaches? If so, how would it work differently in each approach, and when might you choose one over the other? 58 Question 2 + Answer Plan-Based (Waterfall) Approach: ✧ All existing components to be integrated are identified upfront, and the integration plan is created in detail before any work begins. ▪ This includes specifying the exact components to use, their configurations, and how they will interact. ✧ The development process follows a linear path: Requirements Gathering → Component Selection → Design → Integration → Testing → Deployment. ▪ Each step is completed before moving on to the next, with minimal flexibility for changes once the process starts. ▪ This approach ensures predictability, as all integration tasks are defined and scheduled in advance. ▪ However, it can be less flexible if new requirements or changes 59 arise during the process. Question 2 + Answer Agile-Based Approach: ✧ The development team begins by integrating a few core components to create a minimum viable product (MVP) and then iteratively adds new components or features based on user feedback and changing requirements. ✧ Each iteration or sprint focuses on integrating and configuring a small set of components, testing them, and gathering feedback. The feedback informs the next iteration. ▪ The team continuously revisits and adapts the plan based on the evolving needs and priorities. ✧ Components can be swapped or reconfigured to better align with user requirements. 60 Key points ✧ Software processes are the activities involved in producing a software system. Software process models are abstract representations of these processes. ✧ General process models describe the organization of software processes. ▪ Examples of these general models include the ‘waterfall’ model, incremental development, and reuse-oriented development. ✧ Requirements engineering is the process of developing a software specification. Chapter 2 Software Processes 61 Key points ✧ Design and implementation processes are concerned with transforming a requirements specification into an executable software system. ✧ Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system. ✧ Software evolution takes place when you change existing software systems to meet new requirements. The software must evolve to remain useful. ✧ Processes should include activities such as prototyping and incremental delivery to cope with change. Chapter 2 Software Processes 62