1 / 59

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 1

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 1. Stefan Andrei. Software Engineering. CPSC-4360-01 and CPSC-5360-01 are 3 credits points modules: Midterm exam (Monday, March 14, 10:00am): 20% CPSC-4360-01 :

garth
Download Presentation

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 1 Stefan Andrei CPSC-4360-01, CPSC-5360-01, Lecture 1

  2. Software Engineering • CPSC-4360-01 and CPSC-5360-01 are 3 credits points modules: • Midterm exam (Monday, March 14, 10:00am): 20% • CPSC-4360-01: • Project: 30% (10% - Analysis & Design – Report, 20% - Implementation & Test – Demonstration) • CPSC-5360-01: • Project: 15% (5% - Analysis & Design – Report, 10% - Implementation & Test – Demonstration) • Paper Presentation: 15% • Written final exam (May 9, 11:00am-1:30pm): 50% CPSC-4360-01, CPSC-5360-01, Lecture 1

  3. Software Engineering • Module homepage • http://galaxy.lamar.edu/~sandrei/CPSC-4360-01/ • Teaching • Lectures: Monday, Wednesday, Friday, 10:10-11:00, MA111 CPSC-4360-01, CPSC-5360-01, Lecture 1

  4. Course Etiquette • Code of conduct • no copying • for details, see webpage • You are encouraged to attend to all lectures, tutorials, and so on. • You are encouraged to ask questions. • You are encouraged to offer answers. CPSC-4360-01, CPSC-5360-01, Lecture 1

  5. Consultation and Recommended Books • Dr. Stefan Andrei, sandrei@cs.lamar.edu (please send an email to make an appointment - MA2, #69) • Lectures based of the book (chapters available at the course website): • Bimlesh Wadhwa, Stefan Andrei, Soo Yuen Jien. Software Engineering: An object-oriented approach. McGraw Hill, 2007, ISBN: 978-007-126610-9 • Recommended books: • Mark Priestley: Practical Object-Oriented Design with UML, McGraw Hill, 2004 • Ian Sommerville: Software Engineering, Pearson – Addison Wesley, 7th Edition, 2004 • Craig Larman: Applying UML and Patterns, Pearson – Prentice Hall, 2005 • Robert Binder: Testing Object-Oriented Systems, Addison Wesley, 2000 CPSC-4360-01, CPSC-5360-01, Lecture 1

  6. Overview of This Course • Software Development Process • Modelling with Objects • Analysis Model • Use Case Modelling • Analysis Class Modelling • Object States • Design Model • Design Class Modelling • Object Interactions • Implementation Issues • Testing and Integration • Design Patterns • Software Life Cycle Models / Methodologies CPSC-4360-01, CPSC-5360-01, Lecture 1

  7. Tutorials Objectives • Purposes • for self-assessment • use material from lectures • answer questions • help deep understanding • prepare projects • save your time! CPSC-4360-01, CPSC-5360-01, Lecture 1

  8. The Project • Students are given a problem specification • Vague, misleading, ambiguous, conflicting • It has two parts: • Report • Sort out what to do - analyse • Sort out how to do it - design • Demonstration • Do it ! - code • Verify - test • Group size is 3 or 4. • Strict deadline – the last week of teaching. CPSC-4360-01, CPSC-5360-01, Lecture 1

  9. Recommendations • For CPSC-4360-01 and CPSC-5360-01: • Walkthrough the software development process: • Lectures give the theory background; • Tutorials allow you to explore the theory; • Project gives the opportunity to apply what you have learned; • Furthermore, CPSC-5360-01 students need to present a research paper presentation. • Best way to appreciate the course: • Read up relevant topics; • Attend the lectures and tutorials; • Do the relevant part for the project right after. CPSC-4360-01, CPSC-5360-01, Lecture 1

  10. Useful Software • Pre-requisites software: • Java Programming Language (http://java.sun.com/). • Recommended software: • ArgoUML (http://argouml.tigris.org/) is a UML design tool with cognitive support, released on September, 2003; • JUnit (http://junit.sourceforge.net/) is a simple framework to write repeatable tests, released on August, 2002. CPSC-4360-01, CPSC-5360-01, Lecture 1

  11. Lecture Structure • Reminder of last lecture • Overview • Content (new notions + examples) • Summary • Reading suggestions • Coming up next CPSC-4360-01, CPSC-5360-01, Lecture 1

  12. Overview of This Lecture • Overview of Software Engineering • SE definitions • Quality of Good Software • Overview of Software Process • Activities and associated stages • Overview of Software Engineering Method • Structured Analysis • Object-Oriented Method CPSC-4360-01, CPSC-5360-01, Lecture 1

  13. 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/) CPSC-4360-01, CPSC-5360-01, Lecture 1

  14. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  15. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  16. Software Development Problems • “Software is not constrained by materials, or governed by physical laws, or by manufacturing process” ---- (Sommerville, Software Engineering) • 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). CPSC-4360-01, CPSC-5360-01, Lecture 1

  17. 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… CPSC-4360-01, CPSC-5360-01, Lecture 1

  18. Famous Software Disaster • Ariane 5 expendable launch system: • Spacecraft launching system improved from Ariane 4. • First test flight took place on June 4, 1996. CPSC-4360-01, CPSC-5360-01, Lecture 1

  19. Famous Software Disaster (cont) • US $5 hundred millions worth of payload destroyed. • Reason: • Main Navigation Computer crashes after 37 seconds. • Caused by a conversion overflow: converting floating point number to integer number. • Reuse of specification of Ariane 4 without taking into consideration the new capability. CPSC-4360-01, CPSC-5360-01, Lecture 1

  20. More Software Disasters • Denver Airport Automated Baggage System. • Therac-25: Massive overdose of radiation. • Link to History's Worst Software Bug: http://wired.com/news/technology/bugs/0,69355-1.html?tw=wn_story_page_next1 • http://www.comlab.ox.ac.uk/archive/safety.html • http://www.csl.sri.com/risks.html CPSC-4360-01, CPSC-5360-01, Lecture 1

  21. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  22. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  23. 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 CPSC-4360-01, CPSC-5360-01, Lecture 1

  24. 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 CPSC-4360-01, CPSC-5360-01, Lecture 1

  25. 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 CPSC-4360-01, CPSC-5360-01, Lecture 1

  26. Software Engineering Myths • A general statement of objectives is sufficient to begin writing programs - we can fill in the details later. • Poor Up-front definition is the major cause of failed software efforts. • If we get behind schedule, we can add more programmers and catch up. • Brooks Law: “Adding people to a late project makes it later.” CPSC-4360-01, CPSC-5360-01, Lecture 1

  27. Software Engineering Myths • Project requirements continually change, but change can be easily accommodated because software is flexible. Cost Impact Severe Moderate Minor Occurrence of Change Planning Design Implementation CPSC-4360-01, CPSC-5360-01, Lecture 1

  28. Software Process • The steps involved in creating a software system  Software Process. • The guideline or overall principle used during the Software Process  Software Engineering Method. CPSC-4360-01, CPSC-5360-01, Lecture 1

  29. Software Process • The set of activities and associated results 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 (lecture 2). CPSC-4360-01, CPSC-5360-01, Lecture 1

  30. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  31. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  32. 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 CPSC-4360-01, CPSC-5360-01, Lecture 1

  33. 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). CPSC-4360-01, CPSC-5360-01, Lecture 1

  34. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  35. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  36. Simple Software Process Example • In the simplest cases, code is written directly from some statements of requirements. Process Artifact CPSC-4360-01, CPSC-5360-01, Lecture 1

  37. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  38. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  39. A More Complex Software Process • It is better to design before you code. • On larger projects, intermediate pieces of documentation are produced. CPSC-4360-01, CPSC-5360-01, Lecture 1

  40. 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. CPSC-4360-01, CPSC-5360-01, Lecture 1

  41. A More Complex Software Process • Software Specification: • Analyze Requirement → Requirement Documentation • Software Development: • Design: • Structure Chart of the functions/modules/classes • Programming: • Write Code → Source Code • Debugging • Software Validation: • Compare against sample outputs • Software Evolution: • Not applicable. CPSC-4360-01, CPSC-5360-01, Lecture 1

  42. Modeling the System • The structure chart is an example of system model. • A powerful and useful technique. • Give abstract view of the actual system • Usually in graphical notation • Easier to understand • Easier to manipulate • The semantic, usage and notation used in modeling is part of Software Engineering Method, described next. CPSC-4360-01, CPSC-5360-01, Lecture 1

  43. Software Engineering Method • A strategy for successfully developing software. • A guiding principle throughout the Software Process. • Based on the idea of developing graphicalmodels (abstract representation) of a system, which can be used as specification or design. • No bestmethod: depends on type of system. • Two popular methods are described next. CPSC-4360-01, CPSC-5360-01, Lecture 1

  44. Stack Stack with New Value Push Value on to Stack New Value Structured Analysis • One of the earliest methods, developed in 1970s. • Essence: • Function Oriented: Identify process (function) that transform data. • Good match for procedural languages like C, Pascal, Fortran, etc. • Example (Data Flow Diagram - DFD): CPSC-4360-01, CPSC-5360-01, Lecture 1

  45. Structured (Procedural) Methods • Structured methods = structured analysis and structured design. • Characteristic model = data flow diagram (description of the system’s data and how the data interact with the system). • Structured methods refer to software systems where data are processed by functions external to data. • In other words, the system’s data are stored in one place, and functions (operations) are essentially separated by the data. • Structured methods are appropriate for the design of data-rich systems (e.g., relational databases). CPSC-4360-01, CPSC-5360-01, Lecture 1

  46. Stack -Items: Integer[ ] +push(value: integer) Object-Oriented Methods • Recently developed in 1990s. • Essence: • Object-Oriented: Identify entity (object) that contains natural collection of both data and the process (function) that operates on them. • Good match for OO languages like C++, JAVA, SmallTalk, etc. • Example (UML Class Diagram): CPSC-4360-01, CPSC-5360-01, Lecture 1

  47. Object-Oriented Methods • Most operations in real-world only use a small fraction of the total data of the system, and most pieces of data will be accessed by a small number of operations. • So, there was a need to split the data repository and integrate pieces of data with the operations that directly manipulate those data = object-oriented approaches. • Example: scanners and printers are (in) separate (rooms), as they provide different operations. CPSC-4360-01, CPSC-5360-01, Lecture 1

  48. Structured and Object-Oriented Methods: Comparison • Compared with structured approaches, in the object-oriented approaches the operations are localized together with the data that they affect, instead of being part of a large and global structure. • Programs using object-oriented structures are easy to understand and maintain (incremental software development). • In the structured approach, each operation has the responsibility of choosing the necessary data from the central repository (i.e., global place where the data is stored). CPSC-4360-01, CPSC-5360-01, Lecture 1

  49. What’s in CPSC-4360 and CPSC-5360? • Subsequent lectures resemble a walkthrough of the software development process using Object-Oriented Method. Software Specification Software Development Software Validation Software Evolution • Domain Analysis • Requirements Gathering and Analysis • Requirements Specification • Requirements Validation • Feasibility Study • Architectural Design • Abstract Specification • Interface Design • Component Design • Data Structure Design • Algorithm Design • Component Testing • System Testing • Acceptance Testing • Maintenance • Redevelopment • Those in Bold Font will be covered by lectures and project. CPSC-4360-01, CPSC-5360-01, Lecture 1

  50. What’s NOT in CPSC-4360 and CPSC-5360? • Aspects of Project Management: • Scheduling • Risk Assessment • Quality Assessment • Documentation • Human Resource Management • Etc…. • Communication and Inter-Personal Skills: • Other than communicating with your team mate and tutor • Not formally covered. CPSC-4360-01, CPSC-5360-01, Lecture 1

More Related