CS251 – Software Engineering Lecture 3: Process and Life Cycle

1. CS251 – Software EngineeringLecture 3: Process and Life Cycle www.acadox.com/join/563R9V

2. حكمة اليوم • أفلم يسيروا في الأرض فتكون لهم قلوب يعقلون بها أو آذان يسمعون بها • فإنها لا تعمى الأبصار ولكن تعمى القلوب التي في الصدور

3. Assessment • Midterm exam (10%) • Final exam (60%) • Project: 18~20% + 4% • Assignments: 10~12%

4. Course TAs and Page • http://www.acadox.com/class/2604 • TAs • دسوقى عبد القوى d.abdelqawy@fci-cu.edu.eg • مصطفى سعد m.saad@fci-cu.edu.eg • عمرو سمير a.samir@fci-cu.edu.eg • دينا محمود dina.mahmoud@fci-cu.edu.eg • خالد على o.khaled@fci-cu.edu.eg • محمود خضير m.khodier@fci-cu.edu.eg • أمنية سامىomnia.samy@fci-cu.edu.eg • يمنى مجدىyomna@fci-cu.edu.eg

5. Lab Objectives • Help you get deeper understanding • Train you on the concepts explained in the lectures. • Prepare and follow up project work • Answer questions • Save your time!

6. The Project • Students are given a problem description • It has three Phases • Requirements and Plan • Iteration 1 • Iteration 2 • Group size is 3 or 4. • Topics will posted ASAP • Strict deadlines

7. What is ‘Software Engineering’?... • A term used occasionally in 1950s, 1960s • Popularized in 1968 at NATO Software Engineering Conference (http://homepages.cs.ncl.ac.uk/brian.randell/NATO/)

8. What is Software? • More than computer programs. • The collection of programs, documentation and configuration data that ensures correct execution. • Three major types: • Generic Product: Stand alone, Sold on open market. • Customized Product: For specific customer. • Embedded Product: Built into hardware.

9. The Nature of Software • Intangible: • Opposite of physical artifacts, e.g., Computer vs Windows XP • Hard to understand the development process. • Easy to Reproduce: • Costly design and construction, cheap manufacturing. • Malleable: • Easy to change, even without full understanding. • Untrained people can “hack” something together.

10. Software Development Problems • “Software is not constrained by materials, or governed by physical laws, or by manufacturing process” ---- (Sommerville) • Allows almost unbounded complexity: • Exponential growth of complexity w.r.t. to the size of a program: twice the size, four times the complexity; • Example: Windows XP has 40millions lines of source code (estimation).

11. Software Development Problems • Difficulty in understanding and managing the complexity causes: • Late completion: • “vaporware” that are announced but never produced • Overrunning Cost: • Denver Airport Automated Baggage System, 2 billions US dollar over budget • Unreliable • Difficult to maintain • Etc…

12. What is Engineering? • Systematically identify, understand, and integrate the constraints on a design to produce a successful result. • Constraints may include: • available resources, • physical or technical limitations, • flexibility for future modifications and additions, • cost, manufacturability, and serviceability. • Deduce specifications from the limits. • Ethical Practices.

13. Quality of Good Software • Usability • Easy to learn and use. • Efficiency • Does not waste resources such as CPU time and memory. • Dependability • Reliable, secure and safe. • Maintainability • Easily evolved (modified) to meet changing requirement. • Reusability • Parts can be reused, with minor or no modification.

14. Quality of Good Software • Can be quite different based on your viewpoint: Customer: - Solves problems at acceptable cost (time and resource). User: - Easy to learn - Efficient to use - Get work done Developer Manager: - Sells more and pleases customers - Costing less to develop and maintain Developer: - Easy to design and maintain

15. So, ‘Software Engineering’ is IEEE Standard 610.12: • The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software. • “Designing, building and maintaining large software systems”. - I. Sommerville • “Multi-person construction of multi-version software”. - D. L. Parnas

16. What is Software Engineering?... • “Technological and managerial discipline of software products that are developed and modified on time and within cost estimates”. – R. Fairley • “Software development is not simply a case of sitting down at a terminal and typing in the program code”. – M. Priestley • A discipline that guides the process of solving customers’ problems by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints. – our definition

17. CPSC-4360-01, CPSC-5360-01, Lecture 1

18. Course Contents • Overview of Software Engineering ½ Week • Software Disasters ½ Week • Review of OOP 1 Week • Software Lifecycle and SW Engineering Processes 1 Week • Requirements Eng. (SRS, use cases, storyboards) 1 Week • Software Modeling and Analysis and UML 3 Weeks • Software Patterns 1 Week • Software Architecture 1 Week • Software Construction 1 Week • Software Quality and Testing 1 Week • Software Configuration and Project Management 1 Week

19. 2. Software Life Cycle • Conception • Feasibility Study • Requirements’ Gathering • Overall Design • Detailed Design • Development (Coding, Programming) • Testing (Unit, Integration, Acceptance) • Deployment / Training • Maintenance and Evolution

20. Process of Building a House Same life cycle Different Process

21. 2. Software Life Cycle Specification • Conception • Feasibility Study • Requirements’ Gathering • Overall Design • Detailed Design • Development (Coding, Programming) • Testing (Unit, Integration, Acceptance) • Deployment / Training • Maintenance and Evolution Development Validation Evolution

22. Important Terms • Software life-cycle • Phases • Development cycle and evolution cycle • Software process • Discipline, activities, roles, and artifacts • Iterations • Milestones

23. 2. Software Life Cycle (As in RUP) Inception • Conception • Feasibility Study • Requirements’ Gathering • Overall Design • Detailed Design • Development (Coding, Programming) • Testing (Unit, Integration, Acceptance) • Deployment / Training • Maintenance and Evolution Elaboration Construction Transition

24. CS251 – Software EngineeringLecture 3: Process and Life Cycle www.acadox.com/join/563R9V

25. Inception Elaboration Construction Transition T I M E Phases of the Development Cycle Inception - Define the scope of project Elaboration - Plan project, specify features, baseline system Construction - Build the product Transition- Transition the product into end user community

27. Software Process • The set of activities and associatedresults that produce a software product. • Four fundamental process activities: • Software Specification • Software Development • Software Validation • Software Evolution • Can be organized in different ways, described at varying level of details → different software development process models

29. 6.3. What is a Lifecycle Model? Definition. A (software/system) lifecycle model is a description of the sequence of activities carried out in an SE project, and the relative order of these activities.

31. Activity 1: Software Specification • Customers and Software Engineers • Define the software to be produced • Define the constraints on its operations • Typical Stages: • Feasibility Study: • Is it possible with the current technologies + within budget? • Domain Analysis: • What is the background for the software? • Requirements Gathering and Analysis: • What is it that the user wants? • Requirements Specification: • Formal documentation on User and System requirements. • Requirements Validation: • Check for realism, consistency, and completeness.

32. Activity 2: Software Development • Consists of Design and Programming • System Analysts • Design: decide how the requirement can be implemented. • Programmers • Coding: translate high level design into real code in a chosen programming language.

33. Activity 2: Software Development • Typical Stages (Design): • Architectural Design: Split into subsystems • Abstract Specification: High level specification on the services and constraints for each subsystem • Interface Design: Interface with other subsystems are defined • Component Design: Split the services and allocate to components within a subsystem • Data Structure Design: Choose appropriate data structure • Algorithm Design: Design and specify algorithm used to provide services High Level Low Level

34. Activity 2: Software Development • Typical Stages (Programming): • Data structure and algorithm design (from the design stage) may be delegated to the programmer. • Personal activity. Usually without a predefined process. • Debugging: Low level testing of code. Reveals program defects (bugs).

35. Activity 3: Software Validation • Software Engineer (or dedicated tester) and Customer: • Check the software to ensure it meets the customers’ requirements. • Typical Stages: • Component Testing: Independent testing of individual components in subsystem. • System Testing: Testing of integrated components. Can be multi-levels, e.g., subsystem → system. • Acceptance Testing: Tested with customer supplied data. Final test before operation. • Interactive activity that feedback to previous stages: • E.g., an error in component testing triggers re-coding.

36. Activity 4: Software Evolution • Customers and Software Engineers: • Define changing requirements. • Modify the software system to adapt. • Typical Work: • Update the system for minor new requirements, e.g., changing the telephone number from 7 digits to 8 digits, changing the date representation (the Millennium Bug). • Could be drastic, more like redevelopment, e.g., windows95 →windows98 → windowsXP.

37. Simple Software Process Example • In the simplest cases, code is written directly from some statements of requirements. Process Artifact

38. Simple Software Process Example • Two processes: • ‘Analyze requirements’ • ‘Write code’ • Two artifacts: • ‘Requirements specification’ • ‘Source code’ • ‘Requirements specification’ can be written as: • an informal outline or • a highly detailed description.

39. Simple Software Process Example • Software Specification: • Analyze Requirement → Requirement Documentation • Software Development: • Design: • Data structure and algorithm • Programming: • Write Code → Source Code • Debugging • Software Validation: • Compare against sample outputs • Software Evolution: • Not applicable.

40. A More Complex Software Process • It is better to design before you code. • On larger projects, intermediate pieces of documentation are produced.

41. A More Complex Software Process • One new process: • ‘Design module structure’ - splitting the program into modules and subroutines • One new artifact: • ‘Structure chart’ – is based on the information contained in the ‘requirements specification’ • Both the ‘requirements specification’ and the ‘structure chart’ are used when writing the final code.

42. A More Complex Software Process • Software Specification: • Analyze Requirement → Requirement Documentation • Software Development: • Design: • Design of the functions/modules/classes • Programming: • Write Code → Source Code • Debugging • Software Validation: • Compare against sample outputs • Software Evolution: • Not applicable.