Software Engineering Lecture 03: Software Processes-2 (PDF)

Software Engineering Lecture 03: Software Processes-2 Muhammad Haggag, Ph.D. Computer Science Department Faculty of Computers and Information Mansoura University Fall 2024 Topics covered Software process models Process activities...

Software Engineering Lecture 03: Software Processes-2 Muhammad Haggag, Ph.D. Computer Science Department Faculty of Computers and Information Mansoura University Fall 2024 Topics covered Software process models Process activities Coping with change 22  Process activities Process Activities: Concerned with the specific tasks performed during development. Software Process Models: Concerned with the overall framework and structure for managing those tasks. 23 Process activities Real software processes are inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system. The four basic process activities of specification, development, validation and evolution are organized differently in different development processes. For example, in the waterfall model, they are organized in sequence, whereas in incremental development they are interleaved. 24 The requirements engineering process 25  Software specification The process of establishing what services are required and the constraints on the system’s operation and development. Requirements engineering process Requirements elicitation and analysis What do the system stakeholders require or expect from the system? Conduct interviews, surveys, and workshops with stakeholders. Requirements specification Defining the requirements in detail Create specifications that outline functional and non-functional requirements, user stories, or use cases. Requirements validation Checking the validity of the requirements Perform testing or validation methods (e.g., prototyping , model validation ) to confirm requirements are feasible and achievable. 26 Requirements vs Specification Requirements focus on what the system should achieve. Customer need Specification focuses on how those requirements will be fulfilled Technical description Example 1: User Authentication System Requirements: The system shall allow users to create an account using an email address and password. UML used: Use Case, Activity Diagrams Specification: Account Creation: 1. Input: User inputs email and password. 2. Output: A confirmation email is sent to the user. 3. Validation: Email must be in a valid format, and password must meet complexity requirements (at least 8 characters, one uppercase letter, one number). UML used: Class, Sequence, Component Diagrams 27 Software design and implementation The process of converting the system specification into an executable system. Software design Design a software structure that realises the specification; Create design diagrams (e.g., UML diagrams) to visualize the system's structure. Implementation Translate this structure into an executable program; Write the actual source code based on the design specifications. The activities of design and implementation are closely related and may be inter-leaved. 28 A general model of the design process 29 Design activities Architectural design, where you identify the overall structure of the system, the principal components (subsystems or modules), their relationships and how they are distributed. Online Bookstore System : User Interface Module/Catalog Module/Order Processing Module Database design, where you design the system data structures and how these are to be represented in a database. Users / Books / Orders tables Interface design, where you define the interfaces between system components. Interface between User Interface Module and Catalog Module: Method: getBookList() - Parameters: None - Response: List of available books with details (ID, title, price). Component selection and design, where you search for reusable components. If unavailable, you design how it will operate. Reusable Component: Use a third-party payment processing API (e.g., Stripe) for handling payments. New Component: Design an Inventory Management Component to track stock levels and manage reordering. 30 System implementation The software is implemented either by developing a program or programs or by configuring an application system. Design and implementation are interleaved activities for most types of software system. rapid adjustments based on testing and feedback, Programming is an individual activity with no standard process. While programming can be collaborative, it often involves personal coding tasks where developers write and debug their own code. Programming practices can vary significantly between individuals and teams, leading to diverse coding styles and methodologies. Debugging is the activity of finding program faults and correcting these faults. 31 Software validation Verification and validation (V & V) is intended to show that a system conforms ‫ يتوافق‬to its specification and meets the requirements of the system customer. Verification: Ensures the product is built according to specifications (are we building the product right?). Validation: Ensures the product meets user needs and requirements (are we building the right product?). Involves checking and review processes (without executing it), and system testing. System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. Testing is the most commonly used V & V activity. 32 Stages of testing 33 Testing stages Component testing Individual components are tested independently; Components may be functions or objects or coherent groupings of these entities. System testing Testing of the system as a whole. Testing of emergent properties is particularly important. System Testing is typically performed by QA teams in a controlled testing environment. Customer testing Testing with customer data (Also known as user acceptance testing UAT) to check that the system meets the customer’s needs. (Validation) Customer Testing involves actual users in real-world scenarios and environments. 34 Testing phases in a plan-driven software process (V-model) Verification and Validation: The left side of the "V" represents verification activities (requirements, design, and coding), The right side represents validation activities (integration testing, system testing, and acceptance testing). 35 Software evolution Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change. Although there has been a demarcation ‫ ترسيم الحدود‬between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new. Technology Trends: The shift to microservices allows for more flexible evolution of applications instead of creating entirely new ones. Rapid Prototyping: Creating prototypes and iterating based on user interaction often leads to significant changes. Organizations focus on refining what they have, leading to fewer brand-new systems Refactoring: Refactoring existing code [Legacy system] for better performance or scalability is a common practice, effectively turning maintenance activities into new development efforts. 36 System evolution Rather than two separate processes, it is more realistic to think of software engineering as an evolutionary process Continuous Evolution: Ongoing Changes: Software is not static; it continually evolves to meet changing requirements, adapt to new technologies, and address user feedback. This makes maintenance an integral part of the software lifecycle. 37 Coping with change 38 Coping with change Change is inevitable in all large software projects. Business changes lead to new and changed system requirements New technologies open up new possibilities for improving implementations Changing platforms require application changes Change leads to rework so the costs of change include both rework (e.g. re-analysing requirements) as well as the costs of implementing new functionality 39 Reducing the costs of rework Change anticipation ‫توقع‬, where the software process includes activities that can anticipate possible changes before significant rework is required. For example, a prototype system may be developed to show some key features of the system to customers. Change tolerance ‫تحمل‬, where the process is designed so that changes can be accommodated with minimal disruption and cost. This normally involves some form of incremental development. Proposed changes may be implemented in increments that have not yet been developed. 40 Coping with changing requirements System prototyping, where a version of the system or part of the system is developed quickly to check the customer’s requirements and the feasibility of design decisions. This approach supports change anticipation. Incremental delivery, where system increments are delivered to the customer for comment and experimentation. This supports both change avoidance and change tolerance. 41 Software prototyping A prototype is an initial version of a system used to demonstrate concepts and try out design options. A prototype can be used in: The requirements engineering process to help with requirements elicitation and validation; In design processes to explore options and develop a UI design; In the testing process to run back-to-back tests. 42 Benefits of prototyping Improved system usability. A closer match to users’ real needs. Improved design quality. Improved maintainability. Reduced development effort. 43 The process of prototype development 44 Prototype development May be based on rapid prototyping languages or tools May involve leaving out functionality Prototype should focus on areas of the product that are not well- understood; Error checking and recovery may not be included in the prototype; Focus on functional rather than non-functional requirements such as reliability and security 45 Prototype Models Types 1. Throwaway/Rapid Prototyping Description: A quick, low-fidelity prototype created to visualize and test concepts or features. Once feedback is gathered, it is discarded, and the actual system is developed based on the insights gained. Use Case: Useful for clarifying requirements and exploring design ideas without the need for detailed specifications. 2. Incremental Prototyping Description: The final system is built as separate prototypes, or increments, which are developed and integrated over time. Each increment represents a portion of the final product, allowing for early delivery of functional components. Use Case: Suitable for large systems where different features can be developed and tested independently before integration. 46 Prototype Models Types 3. High-Fidelity Prototyping Description: A prototype that closely resembles the final product in terms of design, functionality, and user interface. It is usually interactive and provides a realistic user experience. Use Case: Useful for testing specific features or user interactions in detail, often used in usability testing. 4. Low-Fidelity Prototyping Description: Often consists of sketches, wireframes, or basic mockups that convey layout and functionality without detailed design or interactivity. Use Case: Great for early-stage brainstorming and gathering initial feedback on concepts without extensive investment in development. 47 Always start with low fidelity 48 Throw-away prototypes Prototypes should be discarded after development as they are not a good basis for a production system: It may be impossible to tune the system to meet non-functional requirements; Prototypes are normally undocumented; The prototype structure is usually degraded through rapid change; The prototype probably will not meet normal organizational quality standards. 49 https://shorturl.at/nx6nD 50 Thank you 51