1 / 37

Software Engineering

Software Engineering. How many lines of code?. Average CS1004 assignment: 200 lines Average CS4115 project: 5000 lines Corporate e-commerce project: 80,000 lines Microsoft Windows Vista: 50,000,000+ lines. What is Software Engineering ?. NOT just programming

makala
Download Presentation

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. Software Engineering

  2. How many lines of code? • Average CS1004 assignment: • 200 lines • Average CS4115 project: • 5000 lines • Corporate e-commerce project: • 80,000 lines • Microsoft Windows Vista: • 50,000,000+ lines

  3. What is Software Engineering? • NOT just programming • NOT just programming [part of] a large software system • NOT just programming as a member of a large team

  4. What is Software Engineering? “The practice of creating and maintaining software applications by applying technologies and practices from engineering, computer science, project management, application domains and other fields.” -Wikipedia

  5. Over 50% of software projects fail Fred Brooks : IBM’s OS/360 “was late, took more memory than was planned, costs were several times the estimate, and it did not perform very well until several releases after the first”

  6. Why do software projects fail? Difficult to accurately estimate how long something will take

  7. Why do software projects fail? Developers typically overestimate/overstate their productivity

  8. Why do software projects fail? Requirements are not always clearly defined

  9. Why do software projects fail? Requirements are not always realistic

  10. Why do software projects fail? Requirements are always changing

  11. Software development = tradeoffs • Cost vs Scope vs Quality vs Time • Security vs Performance • Specialization vs Generalization • Specificity vs Flexibility

  12. Software Engineering • Processes: • Project management (resources, time, etc.) • Requirements gathering & management • Software design & architecture • Software development • Testing and quality assurance • Tools: • Software design, development, and testing • Communication • Requirements and defect tracking • Version control

  13. Why Study Software Engineering? • Writing a program is easy • Program = code (possibly with comments) • Developing a software system is harder • System = program plus technical documentation sufficient such that someone other than original developers can maintain, typically involving environmental interoperation (beyond just UI and file system) • Developing a software product is very hard • Product = system plus customers, fulfilling the business needs of those customers, with customer-oriented documentation and support

  14. Why Study Software Engineering? • Software Engineering aims at supporting the development of high-quality software products • High-quality software products are more robust, efficient and effective • High-quality software products are easier to use, understand, modify, and compose with other high-quality software products

  15. But I just want to learn Java!!!

  16. Software Engineering is still important! • “Software Engineers” aren’t the only ones who should know about software engineering • Creating high-quality software is necessary in any case in which you or someone else will need to maintain and/or modify your code

  17. System Engineering Process Selection and Training Requirements Eliciting Analysis Recording Technology Selection and Training Design Architecture Components Modules Coding Unit Testing Debugging Integration Build Integration Testing Configuration Management System Testing Performance Testing & Optimization Acceptance Testing Beta Testing Deployment Delivery Installation Operations System Management Maintenance Upgrades Support Activities Project Planning and Tracking Customer Interaction Process Improvement Training Documentation Personnel Management Software Engineering Activities

  18. In the Beginning…

  19. Build First Version Modify until Customer satisfied Operations Retirement Code-and-Fix

  20. Discussion of Code-and-Fix • Really Bad • Really Common • Advantages • No Overhead • No Expertise • Disadvantages • No means of assessing progress • Difficult to coordinate multiple programmers • Useful for “hacking” single-use/personal-use programs: start with empty program and debug until it works

  21. Requirements Validate Design Verify Implementation Test Operations Retirement Waterfall

  22. REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE More Detailed Waterfall

  23. Discussion of Waterfall • Articulated by Win Royce, ~1970 • Widely used today • Advantages • Measurable progress • Experience applying steps in past projects can be used in estimating duration of “similar” steps in future projects • Produces software artifacts that can be re-used in other projects • The original waterfall model (as interpreted by many) disallowed iteration • Inflexible • Monolithic • Requirements change over time • Maintenance not handled well • The “waterfall with feedback” model was, however, what Royce had in mind

  24. REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE Waterfall*

  25. Prototyping Initial Concept Design and Implement Initial Prototype Refine Prototype Until Acceptance Complete and Release Prototype

  26. Discussion of Prototyping • Mock-ups allow users to visualize an application that hasn't yet been constructed • Used to help develop requirements specification • Useful for rapidly changing requirements • Or when customer won’t commit to specification • Once requirements “known”, waterfall (or some other process model) used • Prototypes discarded once design begins • Prototypes should not be used as a basis for implementation, since prototyping tools do not create production quality code • Customer (and management) may need to be “educated” about prototypes: a prototype is not 80-90% of the final product, usually not even 10%

  27. Requirements Validate Architectural Design Detailed Design, Implement, Test, Deliver Feature Set Verify Operations Retirement Incremental (Staged)

  28. Discussion of Incremental • Iterations are classified according to feature sets • e.g., features 1 and 2 will be delivered in this iteration, features 3 and 4 are next • Series of increasingly “complete” releases

  29. The Basic Problem: Risk • Some modern approaches view “risk” as the main problem of software development • Schedule slips • Business changes • Staff turnovers • New technologies • …

  30. EVALUATE ALTERNATIVES DETERMINE GOALS, AND RISKS ALTERNATIVES, Risk analysis Constraints 4 CONSTRAINTS 4 Risk analysis Constraints 3 3 4 Alternatives Risk analysis Constraints 2 3 2 Alternatives 2 Alternatives Risk analysis Proto - Proto - Proto - Constraints 1 Alternatives type type type Prototype Budget 2 3 4 Budget Budget Budget 1 1 3 4 1 1 2 start Detailed Requirements, Concept of Software design life-cycle plan operation design Software requirements Development Integration Validated plan Code requirements and test plan Validated, verified design Unit test System test Acceptance Implementation test plan Spiral Model PLAN DEVELOP AND TEST

  31. Discussion of Spiral Model • Proposed by Barry Boehm, ~1986 • Similar to Incremental Model, but each iteration is driven by “risk management” and/or customer feedback • Determine objectives and current status • Identify risks and priorities • Next iteration addresses (current) highest risk and/or highest priority items • Repeat

  32. Initial Concept Next Iteration Requirements and Iteration Planning Design and Implement Acceptance Testing and Delivery Operations Agile Programming

  33. Discussion of Agile • Each iteration a mini-project • Each iteration’s deliverable is not a prototype, but an operational system • Understand risk vs. business value in planning iterations • Put some working functionality into user’s hands as early as possible • Timeboxing: • Set the date for delivering an iteration • Date cannot change • Only functionality (scope) can change • Short duration iterations (weeks, not months)

  34. eXtreme Programming

  35. eXtreme Programming • Created by Kent Beck in late 1990s • “Takes best practices to extreme levels” • Focuses on five values: • Communication • Simplicity • Feedback • Courage • Respect

  36. What does this mean for me?

  37. Software Engineering in CS1007 • The programs you write in this class will graded as much on their “quality” as on their functionality • This means that they should be: • Well-designed • Robust and well-tested • You need to come up with your own personal “software process” to ensure the quality of the code you write

More Related