1 / 34

An Introduction to Software Engineering

An Introduction to Software Engineering. CSCI 3033 Data Structures. Acknowledgement. Dr. Yue Krishani Abeysekera Wei Ding Charles Moen. What is Software Engineering?.

telma
Télécharger la présentation

An Introduction to Software Engineering

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. An Introduction toSoftware Engineering CSCI 3033 Data Structures

  2. Acknowledgement • Dr. Yue • Krishani Abeysekera • Wei Ding • Charles Moen

  3. What is Software Engineering? • IEEE definition “Software Engineering: (1) The application of a systematic, disciplines, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1).”

  4. System Cost • The relative cost of hardware and software changed drastically in the last 60 years. % Cost hardware software Time

  5. Consequences • Cost: • Software cost ↓ • Hardware cost ↓↓: Moore’s Law, much faster. • Earlier day: optimizing hardware usage. • Assembly language • C

  6. System Speed • Moore Law for hardware. • No Moore Law for software? • Cloud computing. • Wirth Law: software speed is decreasing more quickly than hardware speed is increasing. • This is why efficient programs are always needed.

  7. Consequences • Hardware is now relatively ‘free’? • Selling software, not hardware: Microsoft. • Some software is becoming relatively ‘free’? • Selling service, advertisement instead of software: Google.

  8. Software Crisis (1965-1985) • Budget and Cost Overrun • Cancelled Projects • Damaged properties • Injury and death

  9. Software Engineering Software Life Cycle Models • Abstraction of the software life cycle • Some examples • Waterfall model (Royce)‏ • Spiral model (Boehm)‏ • Rational Unified Process (Booch, Jacobson, Rumbaugh)‏ • Extreme Programming • SWEN 4432 Software Engineering

  10. Waterfall Model In Royce's original waterfall model, the following phases are followed perfectly in order: • Requirements specification • Design • Construction (aka: implementation or coding) • Integration • Testing and debugging (aka: verification) • Installation • Maintenance

  11. Waterfall Model 2 • Some drawbacks: • Difficult to make revisions due to unforeseen problems: no feedback loop • Focus on paper documents and distrustful customer-contractor relationships • Major contributions: identify key activities.

  12. Key Software Activities • 5 Phases of Software Life Cycle: Phase 1: Problem Analysis and Specification Phase 2: Design Phase 3: Implementation (Coding) Phase 4: Testing, Execution and Debugging Phase 5: Maintenance

  13. Phase 1: Problem Analysis and Specification Easy in CS courses, not always in the real world. Computer Science programming assignment - specific statement of problem quantitative description clearly defined requirements: input, output, calculations, test data

  14. Phase 1: Problem Analysis and Specification “Real World” request - general statement of problem qualitative not quantitative precision missing for input, output, processing

  15. Statement of specifications The program should display on the screen a prompt for an amount to be depreciated and the number of years over which it is to be depreciated. If should then read these two values from the keyboard. Once it has the amount and the number of years, it should compute the sum of the integers 1, 2, . . . up to the number of years. It should then display on the screen a table with appropriate headings that shows the year number and the number and the depreciation for that year, for the specified number of years. ® the formal statement of the problem’s requirements ® the major reference document ® a benchmark used to evaluate the final system Sometimes stated precisely using a formal method.

  16. CS courses small systems few hundred lines of code simple, straightforward self-contained “Real” world large systems Tens of thousands of lines of code complex many components Phase 2: Design

  17. OOD: Object-Oriented Design • Identify the objects in the problem's specification and their types. • Identify the operationsof the objects (methods) needed to solve the problem. • Arrange the operations in a sequence of steps, called an algorithm, which, when applied to the objects, will solve the problem.

  18. Phase 3: Implementation (Coding) • Select language of implementation • Encode the design • Verify integration • Combining program units into a complete software system. • Insure quality • programs must be correct, readable, and understandable, that is, well-structured, documented, and stylistic.

  19. Phase 4: Testing, Execution, and Debugging • Validation: "Are we building the right product?" • The software should do what the user really requires • check that documents, program modules, etc. match the customer's requirements. • Verification:"Are we building the product right?" • The software should conform to its specification • check that products are correct, complete, consistent with each other and with those of the preceding phases.

  20. Errors can occur anytime • Specifications don't accurately reflect given information or the user's needs/requests • Logic errors in algorithms • Incorrect coding or integration • Failure to handle boundary data or test values

  21. Different kinds of tests required • Unit tests: • Each individual program unit works? • Program components tested in isolation • Integration tests : • Units combined correctly? • Component interface and information flow tested • System tests: • Overall system works correctly?

  22. The "V" Life Cycle Model

  23. Unit testing • Probably the most rigorous and time-intensive • Surely the most fundamental and important • Kinds of errors tested: • syntax • linking • run-time • logic • Two major types: Black-box and White-box tests

  24. Black box or functional test • Outputs produced for various inputsare checked for correctness without considering the internal structure of the program component itself. • Program unit is viewed as a black box that accepts inputs and produces outputs, but the inner workings of the box are not visible.

  25. White box or structural test • Performance is tested byexamining code’s internal structure. • Test data is carefully selected so that specific parts of the program unit are exercised. • Boundary test: test data with boundary values • Statement coverage test: test cases that cover all the statement in a program • Conditional statement coverage test: test cases that test all the conditions in the conditional statements.

  26. Phase 5: Maintenance • Large % of computer center budgets • Large % of programmer's time • Largest % of software development cost • Why? • Includes modifications and enhancements • Due to poor structure, poor documentation, poor style • less likely to catch bugs before release • make fixing of bugs difficult and time-consuming • impede implementation of enhancements

  27. Some Lessons • Implementation (Coding) • A small part of the software lifecycle. • Easy to outsource (or out-shore) than requirement analysis and design. • A program is not successful if it gives some output. • Course assignments are usually not a good training for the whole software life-cycle.

  28. Iterative Process • Waterfall model: no visible feedback loop. • Iterative models/overlapping phases: • Spiral model • Rational Unified Process

  29. Rational Unified Process An example of an iterative process

  30. New Factors • The Internet age (1994-2003) • Browsers as the universal client agents. • Web 2.0 (~2004-present) • New software distribution: software as a service • perpetual beta • Machine to machine interaction

  31. New Trends: Lightweight Methodologies • Examples: • Extreme Programming • Agile Software Development • Scrum list for software project management

  32. What should we do? • Aware of the software life-cycle. • Aware of the new forces affecting software development. • Aware of the new software methodologies. • Eventually need to learn: • Modeling Language: e.g. UML • Software Process

  33. Relevance to our course • Software will always need to be correct and efficient: • Need to learn data structures and algorithms well.

  34. Questions?

More Related