Software Engineering 1 Lecture 5 PDF

Software Engineering 1 Dr. Nesma Mahmoud  Lecture 5 (Undergraduate – FAI- Level 2) Process Activities & Intro to Requirements Engineering 2 Hint This lecture is based on “Ch...

Software Engineering 1 Dr. Nesma Mahmoud  Lecture 5 (Undergraduate – FAI- Level 2) Process Activities & Intro to Requirements Engineering 2 Hint This lecture is based on “Chapter 4 – Requirements Engineering” from the book namely “Software Engineering, 10th Edition by Ian Sommerville” In this lecture We will know: SDLC activities  SDLC Process activities 30/10/2014 Chapter 2 Software Processes 5 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 (1) specification, (2) development (design and implementation), (3) validation (Testing) and (4) 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. 30/10/2014 Chapter 2 Software Processes 6 (1) Software specification The process of establishing what services are required and the constraints on the system’s operation and development. 30/10/2014 Chapter 2 Software Processes 7  The requirements engineering process Requirements engineering process Requirements elicitation and analysis - What do the system stakeholders require or expect from the system? Requirements specification - Defining the requirements in detail Requirements validation - Checking the validity of the requirements 30/10/2014 Chapter 2 Software Processes 8  System stakeholders Any person or organization who is affected by the system in some way and so who has a legitimate interest Stakeholder types End users System managers System owners External stakeholders 30/10/2014 Chapter 4 Requirements Engineering 9 Stakeholders Example (Uber system) End Users (Riders and Drivers): System Owners (Uber Executives and Investors): Uber Executives: Make strategic decisions about Riders: Individuals who use the Uber features, growth, and the business model. app to book rides. Investors and Shareholders: Financial stakeholders interested in the company’s growth, profitability, and Drivers: People who use the app to market value. find riders and offer transportation. External Stakeholders: System Managers: Regulatory Authorities: Government and local authorities that impose regulations, such as Operations and Support Staff: Teams transportation licensing, safety standards, and data privacy laws. responsible for maintaining the app's Partners and Vendors: Partners like map providers uptime, troubleshooting technical (e.g., Google Maps), payment processors, and issues, and providing customer maintenance services that contribute to the system’s functionality. support. The Public and Local Communities: People indirectly Regional Managers: Those who affected by the presence and operations of Uber in their cities, concerned with impacts on traffic, manage operations in different pollution, and local employment. geographic regions, handling local Competitors: Other ride-sharing companies and public issues and regulations. transportation agencies impacted by Uber's market presence and strategies. Stakeholders Example (Mentcare system) Patients whose information is A medical ethics manager who recorded in the system. must ensure that the system meets Doctors who are responsible for current ethical guidelines for assessing and treating patients. patient care. Nurses who coordinate the Health care managers who obtain consultations with doctors and management information from the administer some treatments. system. Medical receptionists who manage Medical records staff who are patients’ appointments. responsible for ensuring that system information can be IT staff who are responsible for maintained and preserved, and installing and maintaining the that record keeping procedures system. have been properly implemented. (2) Software development (design and implementation) The process of converting the system specification into an executable system. Software design Design a software structure that realises the specification; Implementation Translate this structure into an executable program; 30/10/2014 Chapter 2 Software Processes 12  A general model of the design process Architectural design, where you identify the overall structure of the system, the principal components (subsystems or modules), their relationships and how they are distributed. Database design, where you design the system data structures and how these are to be represented in a database. Interface design, where you define the interfaces between system components. Component selection and design, where you search for reusable components. If unavailable, you design how it will operate. 30/10/2014 Chapter 2 Software Processes 13 Design activities - Architectural design 30/10/2014 Chapter 2 Software Processes 14 Design activities - Database design 30/10/2014 Chapter 2 Software Processes 15 Design activities - Interface design 30/10/2014 Chapter 2 Software Processes 16 3. Software validation (Testing) Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. Involves checking and review processes 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. 30/10/2014 Chapter 2 Software Processes 17  Stages of testing 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. Customer testing Testing with customer data to check that the system meets the customer’s needs. 30/10/2014 Chapter 2 Software Processes 18 Testing stages - Component testing Example 30/10/2014 Chapter 2 Software Processes 19 4. 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. 30/10/2014 Chapter 2 Software Processes 20 System Evolution 30/10/2014 Chapter 2 Software Processes 21 Recap: Process activities The four basic process activities of (1) specification, (2) development (design and implementation), (3) validation (Testing) and (4) evolution 30/10/2014 Chapter 2 Software Processes 22