Software Engineering

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

Writing a program is easy Program = code (with comments) Developing a software system is harder System = program plus technical documentation sufficient such that someone other than original developers can maintain Developing a software product is very hard Product = system plus customers, fulfilling the business needs of those customers, with customer-oriented documentation and support

“__________ 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”

“IBM 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” -Fred Brooks, 1975

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

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

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

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

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

Why do software projects fail? Requirements are not always realistic

Why do software projects fail? Requirements are always changing

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

Software Engineering Processes: Tools: 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

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

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

But I just want to learn Java!!!

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

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

In the Beginning…

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

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

Waterfall Requirements Validate Design Verify Implementation Test Retirement Operations Test Implementation Verify Design

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

Waterfall* REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING [Royce 1970] - DoD contracts PROS: Focuses attention Easy to explain to customers Intermediate products are made explicit CONS: Does not really reflect how software is produced Imposes PM structure - no explanation of how artifact from one stage is transformed in the next Failure to treat software as problem-solving process SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

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

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%

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

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

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

Spiral Model DETERMINE GOALS, ALTERNATIVES, CONSTRAINTS Requirements, life-cycle plan Budget 1 Alternatives Constraints Risk analysis 2 3 4 Prototype Proto - type Concept of operation Software requirements Validated Development plan Integration and test plan design Validated, verified design Detailed Code Unit test System test Acceptance Implementation start DETERMINE GOALS, ALTERNATIVES, CONSTRAINTS EVALUATE ALTERNATIVES AND RISKS [Boehm 88] Viewed in light of risks involved Combine development with risk MGT PLAN DEVELOP AND TEST

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

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

Discussion of Agile Each iteration a mini-project Timeboxing: 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)

eXtreme Programming

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