1. Software Engineering

2. 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

3. 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

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

5. “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

6. 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

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

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

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

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

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

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

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

14. 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

15. 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

16. 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

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

18. 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

19. 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

20. In the Beginning…

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

22. 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

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

24. 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

25. 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

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

27. 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%

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

29. 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

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

31. 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

32. 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

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

34. 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)

35. eXtreme Programming

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