Slides

S1: Welcome to CS 5180

Attendance, Waiting list issues
Introductions: Instructor, T.A. and students
Goals - Learn basic concepts of software engineering
- Topics - Life-cycle >> coding ;
  - requirement, speciications, design, testing, maintenace
- Course Organization - Schedule (for lectures, hws, exams)
- Note: HW1 due next time!!!
- Textbook + Why this book?
- Homeworks (pen-N-paper and Project/Case Study.)
- How to customize the course to your needs?
Today's Topics for Discussion + Readings
- Chapter 1-3 (pp. 1-80)

S2: Software Process

Outline
- Ch#1. Scope of Software Engineering
  - 1.1-1.2 Historical & Economic Aspects
  - 1.3-1.4 Maintenance & Specification and Design
  - 1.5 Team Programming Aspects
  - 1.6-1.7 Object Orientation & Terminology
- Ch#2. Software Process and Its Problems
- Ch#3. Software Life-Cycle Models
Motivation for Software Eng.: (Movie: The NET)
- Q? Have you ever been affeted by a software error? Describe.
- Q? Are you worried about being affect in the near future? Why?
- Q? List 5 ways you can be affected by software problems.

S3: 1.1-1.2 Historical and Economic Aspects

OS/360 Project in 1960s = > "Software Crisis"
- delivered late, over budget, full of residual faults
1968 NATO Workshop: "ENGINEER"-ing as an approach!
- Pros: software life-cycle > coding
  - requirements, design, maintenance, testing, factor of safety!
- Cons: software differs from harware (bridge example)
  - (i) more complex: large number of discrete states, no continuity
  - (ii) maintenance: changes much more drastic
- Q? Has "Software Engineering" solved software crisis in 30 years?
- Economics: Total cost = coding cost + non-coding costs
- higher coding cost ok to reduce total costs!
- Example: Y2K Problem
- Q? What are the non-coding costs?

S4: 1.3-1.4 Why Maintenance, Specification and Design ?

Q? What is dominant cost in software's total cost?
- Dividing Total Costs by phases (Fig. 1.1)
  - We will discuss the phases in chapter 2
- Dominant absolute cost - see Fig. 1.2 (pp. 10)
  - maintenance (upto 60 percent)
- Choose coding techniques to reduce maintenance costs!
Relative costs of fixing errors in different phases
- See Fig. 1.4 & 1.5 (pp. 12, 13)
- Cheaper to fix errors in specification and design phases
- Another reason to invest in non-coding phases

S5: 1.5 Team Programming Aspects

Large software system is developed by a large team
- e.g. Windows 95 - several thousands team members
Other Implications
- Team organization
- Software Project Management plan, schedule, budget, ...
- Change managment - versions. configurations
- ...
Implication for Coding
- Modules, Interfaces to decompose work
- Contain affect of changes within a module
  - to reduce cost of maintenance
- Q? So what do I need to learn beyond C++/Java ?

S6: Terminology: Q? What is software?

Software = code + documentations, e.g.
- specification, design documents, test plan etc.
Product = non-trivial software
Methodology or Paradigm = a family of techniques
- Object oriented methodology
- A method to choose methods
bug vs. error
Other things to learn are
- CASE Tools for different phases
- Software Process Maturity, Life-Cycle choices, etc.

S7: 1.6 Paradigms: Object Vs. Structured

Structured Paradigm (1970s)
- Separate Data and Process/Action (Fig. 1.6/pp. 17)
- Helps large project in specification (DFD),
  - design (structure charts), coding (structured programming)
- and data-structure design (entity, relationship)
- Maintenance: reduced "Goto" but no data-encapsulation
Object Oriented Paradigm (1985 onwards)
- Object encapsulate data and action (Fig. 1.6)
- data abstraction and information hiding
  - contain effect of changes during maintenance
- Hopes of better reusability, lower maintenance costs
- less distinction b/w specification, design and coding
A combination of two methods is often used

S8: Conclusions

Q? Summarize following motivations for software engineering:
- Historic
- Economic
- Safety (e.g. Pacemaker)
- Team Management
- Legal
Q? Which of these are most relevant in Y2K crisis? Why?
Legal Aspects: Tort issues
- Q? Software engineering as a Liability-Insurance!
Q? Can object-orientation help in Y2K crisis? How?
Q? Can structured paradigm help in Y2K crisis? How?
Q? Will Y2K crisis lead to wide-spread use of software eng. ?

S9: Software Process

Outline
- Ch#1. Scope of Software Engineering
- Ch#2. Software Process and Its Problems
  - 2.1 Client, Developer and User
  - 2.2-2.9 Phases: Requirements ... Maintenance / Retirement
  - 2.10 Problems with Software Production
- Ch#3. Software Life-Cycle Models
Theater of Software Process
- Casting: Who are the good guys?
- Problems: Who are the bad guys (werewolves)?
- Script: Engineering to the rescue?

S10: Casting: 2.1 Client, Developer and User

Casting
- Client - wants the product to be developed.
- Developer - members of organization responsible for delivery.
- User - will utilize the product
Types of Software products
- Generic products - sold on the open market to any customer
- Customised products - commissioned by a specific customer
Identify 3 roles in the following situation:
- The textbook by Schach
- PC-DOS in mid-1980s
- Boeing-777, Windows 95, Linux, ...

S11: Werewolves: 2.10 Problems with Software

Complexity - Complicated /Intricate
- No one really understand a large product in entirety
- = > miscommunication b/w team members, to managers
- = > fixing an error may introduce more errors
Conformity - seems easier to adpat
- Software forced to conform to pre-designed plants/organizations
  - = > unnecessary additional complexity
- Alternative: Co-design of software and plants/organizations
Changeability - seems easy to edit
- Frequent and drastic maintenace increase complexity
Invisibility - hard to visualize or comprehend all aspects
- data flow, control flow, def-use dependency, time sequence, ...
Challenge: "...building software will always remain hard.
- There is inherently no silver bullet." - Brooks.

S12: Script: 2.2-2.9 Phases

Borrowing Practices From Engineering
- Activties beyond implementation/coding
- Have been followed in large engineering projects
2.2 Requirement Elicitation: What client needs
- Product functionality needed, budget, deadlines, ...
- Avoid: "This is what I asked for, ... not what I wanted"
  - Rapid prototyping, requirements testing (App. C, pp. 486)
- Q? How can one derive requirements for a generic product?
- 2.3 Specification document as a contract
- Describe product functionality and client constraints
- Avoid ambiguities, incompleteness, etc. (App. D, pp. 497)
2.4 Planning schedule, budget, riskd, ... (App. F, pp. 501)
- Software Project Management Plan (IEEE Standard)
Q? Can we code now? Please!

S13: 2.2-2.9 Phases (Contd.)

2.5 Design (Ex. App. G, pp. 507)
- Architectural: Decompose product into modules
- Detailed: Select data-structures and algorithms
  - specify module interfaces and functionality
- 2.6-2.7 Implementation & Integration
- Coding of individual modules
- Unit testing, Code review
- integrate modules, product testing, acceptance testing
2.8 Maintenance and Retirement
- Corrective change to address reported errors
- Perfective, Adaptive, other maintenance
- Retirement, e.g. mainteance cost is too high

S14: Summary

Q? Identify the effects of 4 werewolves in Y2K crisis?
Q? Which werewolves are addressed by object paradigm?
Q? Consider phases of requirements, specification, design
- and integration. Identify the phase where
- A. software can first be tested using real data.
- B. Linking units to build a software is carried out.
- C. Rapid prototype is used to explore product functionality
- D. structure chart showing module hierarchy is created:

S15: Software Process

Outline
- Ch#1. Scope of Software Engineering
- Ch#2. Software Process and Its Problems
- Ch#3. Software Life-Cycle Models
  - 3.1-5 Build N Fix, Waterfall, Rapid Prototyppe, Incremental, Spiral
  - 3.6 Comparison
  - Q. How to improve a software process?
  - 3.7-3.8 Capability Maturity Model / ISO 9000

S16: Ch#3. Software Life-Cycle Models

"The software process is the way we produce software" (pp. 30)
- The software process ... incorporates the ... life-cycle model
- ... the tools we use ... and the individuals" (pp. 30)
- Life-Cycle Models
- "The life-cycle history of every product is different" (pp. 52)
  - Ex.: 67% maintenance is only an average
- is conceptual and management structure of software process
- links together the phases of a software project
- May start with a bright idea ...
  - If we develop free email, we'll make a lot of money
- May end with either a product ... or a flop!
Let's look at some common life-cycle models . . .

S17: 3.1-3.2 Build N Fix, Waterfall

Build N Fix (See Fig. 3.1)
- keep hacking on it until it works
- the "natural" way to develop software ??
- may work well on small projects ( 1000 lines)
- unsatisfactory for products of any reasonable size
  - SIs a large project in Csci 5180 needed?
- The Waterfall Model (Fig. 3.2, pp. 54)
- Classic model, Best for large projects with teams
- Note the verify or test step in each phase
  - SQA and client both must verify
- Written documentation is produced in each phase
  - helps in maintenance phase
- Note the feedback loops
has well-known strengths & weakness
- Weakness: This is what I asked for, ... not what I wanted

S18: 3.3 Rapid Prototyppe, 3.4 Incremental

prototype: a working model that performs
- a subset of the functions desired.
- The process: (Fig. 3.3 , pp. 59)
- requirements analysis phase == > rapid prototyping phase
- Amount of feedback is much reduced (see Fig. - why?)
- Refining the prototype into implementation is risky
  - as prototypes are built as fast as possible
  - without regard to good programming practice
- Not well understood!
Incremental Life-Cycle (See Fig. 3.4 / pp. 61)
- Product functionality is delivered piece by piece
  - Typical number of builds: 10-50
  - easier for client to ramp up its use;
  - easier to spend $ as product is delivered early and often
- Serious redesign required midway through the process?
- = > there is more burden on the design

S19: 3.5 Risk and Spiral Models

Risk management: a principal task of a manager
- risk is a measure of the uncertainty of the outcome
- High-risk activities cause schedule and cost overruns
- Risk = f(amount and quality of available information)
  - The less information, the higher the risk
- Waterfall has
- High risk for new systems, specification and design problems
- Low risk: well-understood project and technology
Rapid Prototyping
- Low risk for new applications,
  - specification and program stay in step

S20: 3.5 Spiral Model

Phases of the spiral model (Fig. 3.7, pp. 67)
- Objective setting
- Risk assessment and reduction
- Development and validation
- Planning for next round of spiral
What is distinctive?
- various prototypes and plans, risk analyses
- At every phase, maybe the project should be terminated?
  - (cf. "don't throw good money after bad,")
- Considers reuse options, early error elimination
- Puts quality objectives up front
- Integrates development and maintenance
- But, requires risk assessment expertise
- Needs refinement for general use

S21: Q. How to improve a software process?

GOAL: Improved software quality via improving process
3.7 Capability Maturity Model
- Five levels of maturity
  - Initial - ad-hoc process
  - Repeatable - basic project management
  - Defined - process definition
  - Managed - process measurement
  - Optimizing - process control
- Specific certification procedures
3.8 ISO 9000 certification
- Emphasizes documentation, measurements, training
- Specific certification procedure
- Popular in Europe