Software Engineering 3156 - PowerPoint PPT Presentation

Loading...

PPT – Software Engineering 3156 PowerPoint presentation | free to download - id: 5f0d94-MGUyY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Software Engineering 3156

Description:

Title: Software Engineering 3156 Author: Philip Gross Last modified by: Philip Gross Created Date: 9/3/2001 7:42:56 PM Document presentation format – PowerPoint PPT presentation

Number of Views:39
Avg rating:3.0/5.0
Slides: 76
Provided by: PhilipG157
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Software Engineering 3156


1
Software Engineering 3156
  • Fall 2001 Section 1
  • 17-Sep-01
  • Class 3 Life Cycles, XML, and Tools
  • Phil Gross

2
Administrivia
  • Recitations
  • M 530-630 CEPSR 415
  • T 230-330 CEPSR 415
  • Except next Monday, 24 September
  • 615-715 IAB 410
  • Would Friday be better?

3
More Admin Stuff
  • Groups
  • Proposals in by tomorrow night
  • Advantages of the disadvantaged
  • Tight schedule

4
Review
  • Standard Model
  • Teams

5
Standard Model
  • Requirements
  • Specification
  • Design
  • Implementation
  • Integration
  • Maintentance
  • Retirement

6
Requirements
  • What are we doing and why?
  • Interviews
  • Getting a problem specification out of busy,
    threatened, very-much-not-programmer types
  • Difficult to simulate in a course, so were
    skipping
  • Prototypes and negotiation
  • Metric requirements volatility

7
Specification
  • Creating the contract
  • What it will do, not how
  • Detailed, so duration and cost can be estimated
  • Classical DFD, FSM, Petri Nets
  • OO Use cases, class modeling, state diagrams

8
Design
  • Fill in the How
  • Interaction diagrams
  • Sequence
  • Collaboration
  • Interactions determine actions
  • Determine object clients
  • Create detailed design

9
Implementation
  • Pick a language C, C, Java, Ada, COBOL, LISP,
    FORTRAN, Standard ML, Forth, PL/SQL, Assembly,
    etc.
  • Programming standards comments, meaningful
    variable names, named constants, etc.
  • Black-box and Glass-box testing

10
Integration
  • Top-down finds design faults early
  • Bottom-up finds operational faults early and
    isolates them
  • So, Sandwich Integration does both at once
  • Product and acceptance testing

11
Maintentance
  • Corrective (fix problems)
  • Perfective (improvements)
  • Adaptive (environment changes)
  • Difficult, important, programmers hate it
  • Carefully designed processes are critical

12
Maintenance Costs Money
  • Lots and lots of money
  • Far and away most expensive component
  • When doing cost-benefit analysis, anything that
    cheapens maintenance generally wins

13
Retirement
  • Diminishing returns from patching old code
  • At some point better to rip up and start fresh

14
Note Whats Not A Step
  • Testing
  • Documentation
  • Supposed to be continuous
  • Particularly Documentation

15
Capability Maturity Model
  • Not a life-cycle model
  • Set of strategies for improving the software
    process
  • SWCMM for software
  • PCMM for human resources (people)
  • SECMM for systems engineering
  • IPDCMM for integrated product development
  • SAfor software acquisition
  • These strategies are being unified into CMMI
    (capability maturity model integration)

16
SWCMM
  • A strategy for improving the software process
  • Put forward in 1986 by the SEI
  • Fundamental idea
  • Improving the software process leads to
  • Improved software quality
  • Delivery on time, within budget
  • Improved management leads to
  • Improved techniques
  • Five levels of maturity are defined
  • Organization advances stepwise from level to level

17
Level 1. Initial Level
  • Ad hoc approach
  • Entire process is unpredictable
  • Management consists of responses to crises
  • Most organizations world-wide are at level 1

18
Level 2. Repeatable Level
  • Basic software management
  • Management decisions should be made on the basis
    of previous experience with similar products
  • Measurements (metrics) are made
  • These can be used for making cost and duration
    predictions in the next project
  • Problems are identified, immediate corrective
    action is taken

19
Level 3. Defined Level
  • The software process is fully documented
  • Managerial and technical aspects are clearly
    defined
  • Continual efforts are made to improve quality,
    productivity
  • Reviews are performed to improve software quality
  • CASE tools are applicable now (and not at levels
    1 or 2)

20
Level 4. Managed Level
  • Quality and productivity goals are set for each
    project
  • Quality, productivity are continually monitored
  • Statistical quality controls are in place

21
Level 5. Optimizing Level
  • Continuous process improvement
  • Statistical quality and process controls
  • Feedback of knowledge from each project to the
    next

22
Summary
23
Key Process Areas
  • There are key process areas (KPAs) for each level
  • Level 2 KPAs include
  • Requirements management
  • Project planning
  • Project tracking
  • Configuration management
  • Quality assurance
  • Compare
  • Level 2 Detection and correction of faults
  • Level 5 Prevention of faults

24
Experience
  • It takes
  • 3 to 5 years to get from level 1 to level 2
  • 1.5 to 3 years from level 2 to level 3
  • SEI questionnaires highlight shortcomings,
    suggest ways to improve the process
  • Original idea Defense contracts would be awarded
    only to capable firms

25
Experience (contd)
  • Profitability
  • Hughes Aircraft (Fullerton, CA) spent 500K
    (198790)
  • Savings 2M per year, moving from level 2 to
    level 3
  • Raytheon moved from level 1 in 1988 to level 3 in
    1993
  • Productivity doubled
  • Return of 7.70 per dollar invested in process
    improvement

26
Other SPI Initiatives
  • Other software process improvement (SPI)
    initiatives
  • ISO 9000-series
  • ISO/IEC 15504

27
ISO 9000
  • Set of five standards for industrial activities
  • ISO 9001 for quality systems
  • ISO 9000-3, guidelines to apply ISO 9001 to
    software
  • There is an overlap with CMM, but they are not
    identical
  • Not process improvement
  • Stress on documenting the process
  • Emphasis on measurement and metrics
  • ISO 9000 is required to do business with the E.U.
  • Also by many U.S. businesses, for example, GE
  • More and more U.S. businesses are ISO 9000
    certified

28
ISO/IEC 15504
  • Original name Software Process Improvement
    Capability dEtermination (SPICE)
  • International process improvement initiative
  • Started by British Ministry of Defence (MOD)
  • Includes process improvement, software
    procurement
  • Extends and improves CMM, ISO 9000
  • Framework, not a method
  • CMM, ISO 9000 conform to this framework
  • Now referred to as ISO/IEC 15504
  • Or just 15504 for short

29
Process Improvement Data
  • SEI report on 13 organizations in the original
    study
  • They used a variety of process improvement
    techniques, not just SWCMM

30
Process Improvement Data (contd)
  • Results of 34 Motorola projects

31
Democratic Teams
  • Egoless programming
  • Social engineering
  • Please find bugs in my code
  • Problem I order you all to be egoless

32
Chief Programmer Teams
  • Brookss approach
  • Chief Programmer
  • Back-up Programmer
  • Secretary
  • Just Plain Programmers

33
Chief Programmer Problems
  • Chief supposed to be manager and programmer
  • Back-up Programmer just waiting for Chief
    Programmer to be hit by a truck
  • Cf. Vice President of the USA
  • Secretary does paperwork all day
  • Doesnt scale to 100 programmers

34
Typical Modern Team
  • Programmers have a Technical Leader and a
    separate Team Manager
  • Manager is administrative only
  • Tech Lead is Technical only
  • Can increase the hierarchy

35
Microsoft Model
  • Synchronize and stabilize
  • Programmers can do whatever they want, but have
    to check in their code on time every day for
    integration
  • Lets hackers run (relatively) free
  • Good model for firms that can attract the very
    best programmers

36
Extreme Teams
  • Code in pairs
  • No specialization
  • A writes test cases, then B writes code while A
    watches
  • Designed to be turnover-resistant
  • Not for those who dont like to be watched

37
Your Teams
  • Probably a mix of democratic and specialized
  • Need to inventory skills of team
  • Probably some manager type is a good idea
  • Call people if stuff is late
  • Watch big picture
  • Not everyone needs to be coder
  • Lots of documentation needed

38
More On Project
  • Three main parts
  • Client
  • Server
  • AI
  • Each group will work on one of the three
  • http//www.gamasutra.com
  • http//www.gameai.com

39
Client
  • Graphical tile-based UI
  • Network communication with server
  • Running animations
  • Sending commands from user to server
  • Displaying what the server tells it to
  • Editor mode
  • Untrusted

40
Server
  • Network communication with client
  • Modeling of entire game world
  • Combat
  • movement
  • Management of game clock
  • Storage to LDAP server

41
AI
  • Determine NPC/Monster actions
  • Determine shortest path between points
  • Scripting
  • Conversation

42
Overview
  • Build-and-fix model
  • Waterfall model
  • Rapid prototyping model
  • Incremental model
  • Extreme programming
  • Synchronize-and-stabilize model
  • Spiral model
  • Object-oriented life-cycle models
  • Comparison of life-cycle models

43
Software Life-Cycle Models
  • Life-cycle model (formerly, process model)
  • The steps through which the product progresses
  • Requirements phase
  • Specification phase
  • Design phase
  • Implementation phase
  • Integration phase
  • Maintenance phase
  • Retirement

44
Build and Fix Model
  • Problems
  • No specifications
  • No design
  • Totally unsatisfactory
  • Need life-cycle model
  • Game plan
  • Phases
  • Milestones

45
Waterfall Model (contd)
  • Characterized by
  • Feedback loops
  • Documentation-driven
  • Advantages
  • Documentation
  • Maintenance easier
  • Disadvantages
  • Specifications
  • Joe and Jane Johnson
  • Mark Marberry

46
Rapid Prototyping Model
  • Linear model
  • Rapid

47
Three Key Points
  • Do not turn into product
  • Rapid prototyping may replace specification
    phasenever the design phase
  • Comparison
  • Waterfall modeltry to get it right first time
  • Rapid prototypingfrequent change, then discard

48
Waterfall and Rapid Prototyping Models
  • Waterfall model
  • Many successes
  • Client needs
  • Rapid prototyping model
  • Not proved
  • Has own problems
  • Solution
  • Rapid prototyping for requirements phase
  • Waterfall for rest of life cycle

49
Incremental Model
  • Divide project into builds

50
Incremental Model (contd)
  • Waterfall, rapid prototyping models
  • Operational quality complete product at end
  • Incremental model
  • Operational quality portion of product within
    weeks
  • Less traumatic
  • Smaller capital outlay, rapid return on
    investment
  • Need open architecturemaintenance implications
  • Variations used in object-oriented life cycle

51
Incremental Model (contd)
  • Problems
  • Build-and-fix danger
  • Contradiction in terms

52
Incremental Model (contd)
  • More risky versionpieces may not fit
  • CABTAB and its dangers

53
Extreme Programming
  • Somewhat controversial new approach
  • Stories (features client wants)
  • Estimate duration and cost of each story
  • Select stories for next build
  • Each build is divided into tasks
  • Test cases for task are drawn up first
  • Pair programming
  • Continuous integration of tasks

54
Unusual Features of XP
  • Computers are put in center of large room lined
    with cubicles
  • Client representative is always present
  • Cannot work overtime for 2 successive weeks
  • No specialization
  • Refactoring

55
Evaluating XP
  • XP has had some successes
  • Good when requirements are vague or changing
  • Too soon to evaluate XP

56
Synchronize-and Stabilize Model
  • Microsofts life-cycle model
  • Requirements analysisinterview potential
    customers
  • Draw up specifications
  • Divide project into 3 or 4 builds
  • Each build is carried out by small teams working
    in parallel

57
Synchronize-and Stabilize Model (contd)
  • At the end of the daysynchronize (test and
    debug)
  • At the end of the buildstabilize (freeze build)
  • Components always work together
  • Get early insights into operation of product

58
Spiral Model
  • Simplified form
  • Waterfall model plus risk analysis
  • Precede each phase by
  • Alternatives
  • Risk analysis
  • Follow each phase by
  • Evaluation
  • Planning of next phase

59
Simplified Spiral Model
  • If risks cannot be resolved, project is
    immediately terminated

60
Full Spiral Model
  • Radial dimension cumulative cost to date
  • Angular dimension progress through the spiral

61
Full Spiral Model (contd)
62
Analysis of Spiral Model
  • Strengths
  • Easy to judge how much to test
  • No distinction between development, maintenance
  • Weaknesses
  • For large-scale software only
  • For internal (in-house) software only

63
Object-Oriented Life-Cycle Models
  • Need for iteration within and between phases
  • Fountain model
  • Recursive/parallel life cycle
  • Round-trip gestalt
  • Unified software development process
  • All incorporate some form of
  • Iteration
  • Parallelism
  • Incremental development
  • Danger
  • CABTAB

64
Fountain Model
  • Features
  • Overlap (parallelism)
  • Arrows (iteration)
  • Smaller maintenance circle

65
Conclusions
  • Different life-cycle models
  • Each with own strengths
  • Each with own weaknesses
  • Criteria for deciding on a model include
  • The organization
  • Its management
  • Skills of the employees
  • The nature of the product
  • Best suggestion
  • Mix-and-match life-cycle model

66
XML
  • Structured form of communication
  • How components will communicate
  • Freeform HTML
  • Grammar and validation
  • DOM and SAX

67
History
  • First came SGML
  • Then HTML
  • HTML became hugely successful
  • XML is an attempt to recapture most of the power
    of SGML, without all the hassle

68
Example XML Message
  • Note lots of examples from either
    http//www.w3schools.com or http//www.w3.org

lt?xml version"1.0"?gt ltnotegt lttogtTovelt/togt ltfro
mgtJanilt/fromgt ltheadinggtReminderlt/headinggt ltbodygt
Don't forget me this weekend!lt/bodygt lt/notegt
69
Differences From HTML
  • Stricter
  • All tags closed
  • Tags are case sensitive
  • All attributes must be quoted
  • Avoid attributes, except for
  • IDs
  • True tag modifiers

70
Grammar Specification
  • DTD
  • Schema
  • Were using schemas
  • Much nicer
  • Consistent XML themselves
  • Grammars explain structure to developers
  • Can also be used for automated validation
  • Sloooooow

71
XML Tools
  • Many
  • Apache tools among the most popular
  • Open source
  • C and Java versions available
  • Xerces
  • DOM suck into memory, give back tree structure
  • SAX parse sequentially, return events

72
More XML
  • JDOM
  • XSLT
  • SOAP

73
CVS
  • First, a word on race conditions
  • Two threads within one program
  • Both want to increment a variable
  • Both read
  • One writes
  • The other writes
  • Result one increment, value clobbered

74
More On CVS
  • The same can happen with your coding process
  • Two people working on same piece of code
  • RCS simple system for versioning and locking
  • CVS fancier, networkable system for checking out
    entire dev snapshots
  • And then selectively committing changes

75
CVS, Continued
  • No locking
  • Conflicts are marked inside the code
  • Youll also be notified if checking in a wrong
    version
About PowerShow.com