software engineering 3156 fall 2001 section 1 17-sep-01 class #3: life cycles, xml, and tools phil...
Post on 19-Dec-2015
214 Views
Preview:
TRANSCRIPT
Software Engineering 3156Fall 2001 Section 1
17-Sep-01
Class #3: Life Cycles, XML, and Tools
Phil Gross
2
Administrivia
Recitations M: 5:30-6:30 CEPSR 415 T: 2:30-3:30 CEPSR 415 Except next Monday, 24 September
– 6:15-7:15 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 we’re 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 What’s 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
– SW–CMM for software– P–CMM for human resources (“people”)– SE–CMM for systems engineering– IPD–CMM for integrated product development– SA–for software acquisition
These strategies are being unified into CMMI (capability maturity model integration)
16
SW–CMM
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 (1987–90)
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
SW–CMM
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
Brooks’s 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 Doesn’t 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 don’t 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 phase
—never the design phase Comparison:
– Waterfall model—try to get it right first time– Rapid prototyping—frequent 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 architecture—maintenance 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 version—pieces 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
Microsoft’s life-cycle model Requirements analysis—interview 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 day—synchronize (test and debug) At the end of the build—stabilize (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
<?xml version="1.0"?> <note>
<to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Don't forget me this weekend!</body>
</note>
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 We’re 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 You’ll also be notified if checking in a wrong
version
top related