[CSUSB]>> [CNS]>> [CSE]>> [R J Botting]>> bib
|| [News] || [Research]

Bibliography Retrieval Engine(Beta)

Items in bibliography identified by a string matching AGILE

Aaen03
.Open Aaen03
 Ivan Aaen
 Software Process Improvement: Blueprints versus Recipes
 IEEE Software Magazine V20n5(Sep/Oct 2003)pp86-93
 =ADVOCATES AGILE IMPROVEMENT SPI PEOPLE vs PROCEDURE
 Lists the risks of having a separate SPI team working out a blueprint/structure/standards.
 Promotes the facilitation of  improvisation plus reflection  within existing teams
.Close

AlshayebLi03
.Open AlshayebLi03
 Mohammad Alshayeb & Wei Li
 An Empirical Validation of Object-Oriented Metrics in Two Different Iterative Software Processes
 IEEE Trans Software Engineering  V29n11(Nov 2003)pp1043-1049
 =EMPIRICAL Object-Oriented  METRICS AGILE XP client-server stories vs  JDK 1.[0-4] EVOLUTION PROCESSES JAVA EDITS
 metrics={WMC, DIT, LCOM,  NLM, CTA, CTM}.
 analyses short-cycle vs long-cycle.
 The metrics with multi-linear regression predict the amount of change (and effort) well in the later cycles of an XP process.
 Not so useful in the JDK long-cycle evolution.
 |-" prediction is impossible at the beginning of the " [XP] " process because there is very little substantive design structure in the system".
  Idea: critical mass of classes needed to define metrics that predict XP effort.
.Close

Ambler01c
.Open Ambler01c
 Scott W Ambler
 Debunking Modeling Myths
 Software Development Magazine V9n8(Aug 2001)pp51-53 + letters V9n9(Sep 2001)p12
 =ESSAY MODELING
 Models are not documentation.
 You can't think everything thru first.
 Modeling can be light/agile
 You don't have to freeze requirements.
 Designs don't have to be cast in stone.
 You don't need a CASE tool.  Simple low tech do most models.
 Modeling can improve productivity.
 Models don't all revolve around data.
 It takes time to learn how to model.
.Close

Ambler02
.Open Ambler02
 Scott Ambler
 Easy Does it
 Software Development Magazine V10n3(Mar 2002)pp53-55
 =EXPERIENCE MODEL AGILE
 Use the simplest tool.
 Example: Develop on white board; take a digital snapshot, pass through image improving software through to OCR!
 Whiteboard_Photo::gadget=http://www.pixid.com.
.Close

Ambler02b
.Open Ambler02b
 Scott W Ambler
 Tools and Evidence
 Software Development Magazine V10n5(May 2002)pp65-66
 =IDEA AGILE MODEL CODE DOCUMENTATION LIFECYCLE UML
 Need to rapidly record ideas. and some ideas need to be preserved.
 Has a class diagram: source code contains comments that are a type of documentation. source code is modeled by models. Some models are in documents. Documents are a type of documentation.
 Has a state chart showing the transitions between Ideas(I), temporary models(T), and permanent models(P) : Start--->I--abandon->end, I--model-->T--keep->P--discard->end, T--update->T, P--update->P, P--version->P, T--discard->end, P--make temporary->T.
.Close

Ambler02c
.Open Ambler02c
 Scott W Ambler
 Lessons in Agility from Internet-Based development
 IEEE Software Magazine V19n2(Mar/Apr 2002)pp66-73
 =EXPERIENCE AGILE MODEL WEB/NET PROCESS UML RUP HTML PEOPLE
 Comparison of two companies.   Finding the right amount of documentation and the right kind of model for a particular situation.
 Tabulates principles and where they fitted experience.
.Box Lessons
 People matter.
 You don't need as much documentation as you think.
 Communication is critical.
 Modeling tools are not as useful as you think.
 You need a wide variety of intellectual models.
 Big up-front design was not needed.
 Reuse the wheel. Don't reinvent it.
.Close.Box
.Close

Ambler02d
.Open Ambler02d
 Scott W Ambler
 The Fragile Manifesto
 Software Development Magazine V10n8(Aug 2002)pp50-51
 =JOKE AGILE PROCESSES PEOPLE DOCUMENTATION USER TEAM
 Ironic and twisted summary of 
.See [Ambler02c]
.Close

Ambler03
.Open Ambler03
 Scott W Ambler 
 Ten Steps to a Robust DB
 Software Development Magazine V11n2(Feb  2003)pp42-43
 =EXAMPLE DATA ERD EVOLUTION REFACTORING UML
 Process:=verify need; choose best; data cleansing; write unit tests; deprecate old schema; implement change; update DBMS scripts; run tests; document; version control.
 See list of ways to refactor a data base (like Replace Column,...)
.See http://www.agiledata.org/essays/databaserefactoring/catalog.html
 Example of UML documentation of changes({removal date=...} and <<trigger>>s
.Close

Ambler03b
.Open Ambler03b
 Scott W Ambler 
 Agility 2013
 Software Development Magazine V11n4(Apr 2003)pp46-47
 =FORECAST AGILE XP CRAFT SKETCHES VISUAL IDEs COBOL
.Close

AmblerS04
.Open AmblerS04
 Scott W Ambler
 Agile Database Techniques: Effective Strategies for the Agile Software
Developer
 John Wiley & Sons 2004 ISBN 0-471-20283-5
 =UNREAD AGILE DATA
  Basis on the web at
.See http://www.agiledata.org/
 (dick)|- how long does it take to add a new data item to an entity in a large existing database?
.Close

AmblerS04a
.Open AmblerS04a
 Scott W Ambler
 Are Your Models Normal?
 Software Development Magazine, Agile Modelling Newsletter (Dec 2004)
 =IDEA DOCUMENTATION MODEL NORMALIZATION DRY
 "record information as few times as possible, ideally only once."
 artifact:="any item created during a software development project including code, model, document, plan, etc".
 artifact_normalization::="placing information about systems in the best single artifact".
 Generate views.        Cross reference, links, and inclusions.
  DITA::="Darwin Information Typing Architecture", XML based  technical documentation,  Parallel to single_sourced technical documentation,  normalized data bases, and coherent modularization. 
(dick)|-"Are there cross cutting concerns?  Compare with Aspect oriented programming". 
(dick)|-(meta-data): "Documentation is data about a system and should be treated as data".
 Compare with POLL
.See [LethbridgeSingerForward03]
.Close

Ambler03
.Open Ambler03
 Scott Ambler
 Agile database techniques: effective strategies for the agile software developer
 John Wiley NY NY 2003 ISBN 0471202835  CR 0502-0163
 =HOWTO AGILE DATA REFACTOR NORMALIZE  Object-Oriented
 From
.See [Amblers04]
and
.See [Amblers03]
.Close

Ambler05
.Open Ambler05
 Scott W Ambler
 The Elements of UML2.0 Style
 Cambridge UP 2005
 =ADVERT UML AGILE STYLE
 Nice book but Not always standard and sometimes apposed by standard
.Close

Ambler07
.Open Ambler07
 Scott Ambler  
 Calculating Documentation Cruft
 Dr. Dobb's Agile Newsletter (27 Jul 2007)   
 =IDEA DOCUMENTATION METRIC CRUFT   
 CRUFT::percent= 100 - C * R * U * F * T where
.Set
 C:=`The percentage of the document that is correct`,
 R:=`The chance that the document will read by the intended audience`,
 U:=`The percentage of the document that will be understood`,
 F:=`The chance that the material contained in the document will be followed`,
 T:=`The chance that the document will be trusted`.
.Close.Set
 (dick)|- perhaps we could use Shannon Communication Theory to measure the capacity, equivocation, etc of a document in bits?
.Close

Armour06
.Open Armour06
 Phillip G Armour 
 Counting Boulders and Measuring Mountains
 Commun ACM V49n1(Jan 2006)pp17-20
 =ANALOGY ESTIMATION PLANNING Project Management WBS COCOMO SLIM-Estimate Everest    
 Argues that you don't get a good estimate of the size of a mountain by  estimating the rocks that make it up and adding up the numbers.
 WBS::="Work Breakdown Structure", count the rocks in the mountain.
 Executives then ask for a better estimate/plan.
 Scope-based implementation is more like using surveying tools and techniques to measure the mountain.
 Use the scope of the project to estimate final system size.
 Time depends on a power of system size.
 Since scope is uncertain and the estimates of size based on a given scope add uncertainty, one generates effort estimates that have a range of values.
 Quantify the uncertainties!
 No discussion of the agile approach (start climbing the mountain first, and 
change your estimates as you climb, etc.)
.Close

Armour07
.Open Armour07
 Phillip G Armour 
 Agile . . . And Offshore
 Commun ACM V50n1(Jan 2007)pp13-14   
 =INTERVIEW AGILE DISTRIBUTED PEOPLE ECONOMICS TOOLS WEB/NET GeneerAginity Ukraine  Mantis Subversion Cruise control Ncover simian 
 Agile Geneer misjudged .com crash 2000-2002 & bank foreclosed.
 Aginity offshore development (Evanston+Kiev) based on personal contact, shared achitecture, patterns, frameworks, language, & vocabulary.
 Stories, iterations, risk provocation.
 Open source groupware tools generate management data via web spaces. 
.Close

Asaravala04
.Open Asaravala04
 Amit Asaravala
 Project Management, Evo Style
 Software Development -- People and Projects newsletter(Nov 2004)
 =ARTICLE AGILE EVOLUTIONARY PROJECT MANAGEMENT 1960s ITERATIVE Evo PDCA
 Many small cycles each with Planning, Checking, Doing, and Acting --(PDCA)
 Acting changes the plans...
 See also "Evolutionary Project Management Methods," by Niels Malotaux
.See http://click.sd.email-publisher.com/maacOZiabbnXPbdngFsb/
[pdf] and
"How Quality Is Assured by Evolutionary Methods," by Niels Malotaux
.See http://click.sd.email-publisher.com/maacOZiabbnXQbdngFsb/
[pdf].
.Close

AugustinePayneSencindiverWoodcock05
.Open AugustinePayneSencindiverWoodcock05
 Sanjiv Augustine & Bob Payne & Fred Sencindiver & Susan Woodcock
 Agile Project Management: Steering from the edges.
 Commun ACM V48n12(Dec 2005)pp85-89
 =ADVERT AGILE PROJECT MANAGEMENT APM COMPLEXITY XP
 APM ::= "Agile Project Management".
 Agile methods rescue a medium sized project in 2002. Lists: 6 practices, 7
changes, 6 new activities, 6 innovations,  7  difficulties.
 sidebar p87 describes complex adaptive systems ( CAS  ).
.Close

AustinDevin03
.Open AustinDevin03
 Rob Austin & Lee Devin 
 Beyond Requirements: software Making as Art
 IEEE Software Magazine V20n1(Jan/Feb 2003)pp93-95
 =ESSAY REQUIREMENTS FORMAL vs AGILE PURPOSES QUALITIES EVOLUTION ITERATION
 Analogy with producing a play.  The requirements are like a script.  But a great performance goes beyond the script by iteration, creation, and improvisation.  So great software will go beyond the predicted requirements using creativity, iteration, and improvisation.
.Close

BaskervilleEtAl03
.Open BaskervilleEtAl03
 Richard Baskerville & Balasubramaniam Ramesh & Linda Levine & Jan Pries-Heje & Sandra Slaughter
 Is Internet-speed software development Different?
 IEEE Software Magazine V20n6(Nov/Dec 2003)pp70-77
 =COLLOQUIUM INTERNET WWW/net AGILE
 Answer=YES!
 Concurrent operation and development but no maintenance, fast releases, tools, customers in team, stable architecture, assemble and reuse components, evolve methodology, people!
.Close

Batra09
.Open Batra09
 Dinesh Batra
 Modified agile practices for outsourced software projects
 Commun ACM V52n9(Sep 2009)online
.See http://doi.acm.org/10.1145/1562164.1562200
 =THEORY AGILE DISTRIBUTED
 You have to modify agile methods when the team is not co-located.
.Close

BerczukLv10
.Open BerczukLv10
 Steve Berczuk & Yi Lv
 We're all in this together
 IEEE Software Magazine V27n6(Nov/Dec 2010)pp12-15
 =ANECDOTE SCRUM INTRODUCTION AGILE MANAGEMENT 
 Certified Scrum Masters.  
 Scrum masters shouldn't be self selected at first. Lead and coach   
 Line managers command and control so at first shouldn't be scrum masters for their team. 
 Reorganized management or left. 
 Self planning teams & managers facilitate. 
 People have to change. 
.Close

BlackEtAl09
.Open BlackEtAl09
 Sue Black & Paul P Boca & Jonathan P Bowen & Jason Gorman & Mike Hinchey
 Formal versus agile: Survival of the Fittest
 IEEE Computer Magazine V42n9(Sep 2009)pp37-45 + Correspondence V42n11(Nov 2009)p6 by William Adams 
 =SURVEY RESEARCH AGILE FORMAL MODEL CHECKING Alloy X-Machines SMV CTL KeY
 SEEFM2003::acronym="First South East Europe Workshop  on formal methods",
.See http://delab.csd.auth.gr/~bci1/SEEFM03
 XFM::="eXtreme Formal Modeling",
.See http://doi.acm.org/10.1145/1109118.1109120
 XFun::= http://delab.csd.auth.gr/~bci1/SEEFM03/seefm03_03.pdf
(PDF), Unified Process with X-Machines verified by model checking.
 KeY::method=http://i12www.iti.uni-karlsruhe.de/~key/keysymposium07/slides/haehnle-agile.pdf
 Extend TDD by including static-analysis and theorem-proving tools to extend coverage.  Example 97% of assertions checked automatically in SPARKAda toolset.
 How do formal requirements handle creep?
 Machine checked refactoring?
 Parallelism: FDR and Coverity
.See http://www.coverity.com/
 Speed and availability of tools:
.Key Rodin
.See http://rodin.cs.ncl.ac.uk/
 and 
.Key Deploy 
.See http://www.deploy-project.eu/
projects. Praxis
.See http://www.praxis-his.com/
has
.Key SPARK toolset 
as open source.
 Formal methods lite -- use math at the right times in a project.
 Argues that the total cost (effort) for a project is less with up front work getting requirements etc. right.
 Agility is not about speed but maneuverability.  Producing the highest quality in each iteration/increment. Compared to RAD.
 Controlling the technical debt.
 No real conflict... given some mutual understanding.
.Close

Boehm02
.Open Boehm02
 Barry Boehm
 Get Ready for Agile Methods, with Care
 IEEE Computer Magazine V35n1(Jan 2002)pp64-69
 =IDEA XP AGILE adaptive risk-driven plandriven  CMM
 Presents a spectrum of processes from Hacking to Inch-pebble ironbound contract.  XP is the limit of th CMM range.
 Agile processes must have involved clientele.  Plan-driven must have stable requirements.
 There exist requirements that break architectures.
 Shows graphs of risk exposure vs amount of planning for different losses that have to be traded-off at a sweet spot.
  For L:loss, risk_exposure(l) ::=P[L] * size(L).
.Close

BoehmHuang03
.Open BoehmHuang03
 Barry Boehm & Li Guo Huang
 Value-Based Software Engineering: A case Study
 IEEE Computer Magazine V36n3(Mar 2003)pp33-41
 =CASESTUDY ECONOMIC REQUIREMENTS PROCESS ESTIMATING AGILE FEEDBACK
 Software can/does fail because of business non-technical value errors. See
.See http://www.standishgroup.com/
CHAOS report.
 Need to track the business value of all tasks performed and needed and use this to adjust plans.
 initiative #(->cause_effect) ->assumptions
 EDSER::="Economics-Driven Software Engineering Research", 
.See http://www.edser.org
.Close

BoehmTurner03a
.Open BoehmTurner03a
 Barry Boehm & Richard Turner
 Using Risk to Balance Agile and Plan-Driven Methods
 IEEE Computer Magazine V36n6(Jun 2003)pp57-66
 =ADVERT one-size situation risk process agile vs planned anchor mbase rup xp spiral modules
 Based on book by same authors...
.See [BoehmTurner03b].
 Sidebar pp58-59: defines home grounds for agile and plan-based processes plus five critical factors: size, criticality, dynamism, personnel, and culture. Kiviat style polar chart.
 sidebar p60:misquotes Cockburn03. 3 levels of skill.
 figure 1 p60. idea: if situation does not fit either agile or planned then architect the project into agile and planned parts.
 p63: can focus testing on the high-risk parts.
 fig 4 p65: 3 kinds of risk: environmental, agile, plan-driven.  ranges: minimal..showstopper.
.Close

BoehmTurner03
.Open BoehmTurner03
 Barry Boehm  & Richard Turner
 Balancing agility and Discipline: A guide for the perplexed
 Addison-Wesley Longman Boston MA 2003 ISBN 0321186125
 =UNREAD =SYNTHESIS AGILE ONESIZE CR 0410-1130
 Avertized in
.See [BoehmTurner03a].
.Close

BoehmTurner05
.Open BoehmTurner05
 Barry Boehm & Richard Turner 
 Management Challenges to Implementing Agile Processes in Traditional Development Organizations
 IEEE Software Magazine V22n5(Sep/Oct 2005)pp30-39 =REPORT WORKSHOP Management Agile vs Traditional People Organizations Culture
 p34. Sidebar lists 8 nonproblems + 10problems due to size/scope + 18 significant issues.
 Authors make suggestions.
.Close

Booch10b
.Open Booch10b
 Grady Booch
 An architectural oxymoron
 IEEE Software Magazine V27n5(Sep/Oct 2010)pp96+95
 =ADVERT AGILE ARCHITECTURE REQUIREMENTS DESIGN DECISIONS
 Pointers to pages: Ambler, Wikiwiki,  Coplien, Kruchten, ...
 Need to socialize important design decisions and their rationale. 
.Close

Botting84b
.Open Botting84b
 RJ Botting
 Generalization - An Alternative to Error Messages
 Proc Western Educational Computing Conference Nov 1984( pp98-99) Western Periodicals Co N Hollywood CA.
.See ./papers/rjb84b.Generalization.html
 =DEMO USER non-sequential System PROTOTYPING EVOLUTIONARY AGILE
 History of a simple technology strapped but successful piece of software.
 Error messages show the lack of imagination of programmers.
 Software can be evolved.
.Close

Botting85c
.Open Botting85c
 RJ Botting
 Evolution of Software for a Faculty Workstation
 pp120-124 Western Educational Computing Conference1985
 =demo evolution prototypes tools System AGILE
 You can not reduce paperwork in an office by using a document driven 
software process in that office.
 Abstract
.Box
The author describes the software for a small portable microcomputer 
workstation. The development of this software did not follow conventional 
methods, but used prototyping. He argues that useful programs tend to 
survive, whereas the less successful are either modified or thrown away. 
The set of successful programs, when compared with the set of unsuccessful
programs, suggests some requirements for a faculty workstation. A second 
conclusion is the need for a new programming system which allows breadboard
systems. He gives a preliminary specification for a software breadboarding
system.
.Close.Box
.Close

CaoRamesh08
.Open CaoRamesh08
 Lan Cao & Balasubramaniam Ramesh 
 Agile requirements engineering practices: an empirical study
 IEEE Software Magazine V25n1(Jan/Feb 2008)pp60-
 =INTERVIEWS 16 FIRMS AGILE REQUIREMENTS BENEFITS CHALLENGES PURPOSES TESTS QUALITIES
 Identified 7 practices each with benefits & challenges.
.Box
 Face-to-face communication not documents.
 Iterating (requirements, priorities,  planning, reviews, & acceptance tests).
 Prototypes.
 Test driven development(TDD). 
.Close.Box
 challenges: forgotten qualities, wrong architecture, lack experience of TDD...
.Close

CeschiEtal05
.Open CeschiEtal05
 Martina Ceschi & Alberto Sillitti & Giancarlo  Succi & Stefano De Panfilis 
 Project Management in plan based and agile companies
 IEEE Software Magazine V22n3(May/Jun 2005)pp21-27 
 =POLL 20 MANAGERS PROCESS SATISFACTION AGILE 
 All use some form of incremental delivery and face similar problems with deadlines and changing requirements,
 Some nonsignificant evidence that Agile companies  tend to be more satisfied with project planning and customer relationships.
 50% of both want  developers that can work in a group.
.Close

Charles96
.Open Charles96
 John Charles
 DoD Standards Go Global and Commercial
 IEEE Software Magazine V13N3(May 1996)pp98-99
 Mil-Std498->-ANSI Trial Use Standard J-Std-016
 =REPORT STANDARDS ONESIZE AGILE
 IEEE/EIA is adapting ISI/IEC 12207 Software Life Cycle Processes->- US Commercial S L C P standard US 12207
 trends: several lifecycles(waterfall|incremental|evolutionary)+ less paper documentation and formal review+clearer distinction between true requirements and design choices
 Perry DeWeese: "A lot of the things that happen in Software development have there genesis before the sofware-development process starts"
.Close

Chaterjee10
.Open Chaterjee10
 Sutap Chatergee
 The Waterfall that won't go away 
 ACM SIGSOFT Software Engineering Notes V33n1(Jan 2010)pp9-10 
.See http://www.acm.org/sigsoft/SEN/
 =EXAMPLE MAINTAINENCE LEGACY AGILE Waterfall
 Frontend experts must treat the backend developers as stakeholders. 
 Need to transition from an agile process to a more ceremonial one as software moves from deployment to maintenance. 
.Close

ChristosPoniPalaiolgou10
.Open ChristosPoniPalaiolgou10
 Ioannis T Christou & Stavros T Ponis & Eleni Palaiogou
 Using the agile unified process in banking
  IEEE Software Magazine V27n3(May/Jun 2010)pp72-79 $CR 1106-0674(Jun 2011)p383
 =EXPERIENCE AGILE AUP RUP PROCESS UML SERVICES SOA GREEK BANKS INTEGRATED DESKTOP
 Describes phases and iterations in the AUP --agile unified process -- as tailored to a project. 
 Collision between  BDUF and emergent design of data base.
 Tools: simple -- whiteboards, sticky notes, index cards, flip charts, ...
 Produced too much documentation. 
 Use cases also need 
	business rules, HCI requirements, constraints, and nonfunctional requirements. 
 Need more than the UML. 
 Which artifacts do you really need?
 Managers like rigid but developers like flexible. 
 Work on many artifacts at once. 
 Simple just good enough artifacts. 
 People must be able to both model and code. 
 Honest open communication. Publish models. 
.Close

Cockburn03
.Open Cockburn03
 Alistair Cockburn
 Agile Software Development
 Addison-Wesley Boston MA 2001 ISBN 0-201-69969-9 US$34.99
 Reviewed  IEEE Software Magazine V20n1(Jan/Feb 2003)pp97-98 and 
.See [CR]
0305-0454  
.See [CR]
0307-0652
 =HANDBOOK IDEAS PROCESS AGILE
 Communication+collaboration+insight+study+practice+experimentation
.Close

CockburnHighsmith01
.Open CockburnHighsmith01
 Alistair Cockburn & Jim Highsmith
 what
 IEEE Computer Magazine V34n11(Nov 2001)pp131-133
 =ADVERT AGILE PEOPLE trump Process
.Close

Cohn04
.Open Cohn04
 Mike Cohn
 User Stories Applied: for agile software development
 Addison-Wesley 2004 ISBN 0-321-20568-5
 =UNREAD USER REQUIREMENTS AGILE XP
.Close

CohnFord03
.Open CohnFord03
 Mike Cohn & Doris Ford
 Introducing an agile Process to an Organization
 IEEE Computer Magazine V36n6(Jun 2003)pp74-78
 =EXPERIENCE AGILE PROCESS PEOPLE RISKS Scrum
programmer:
.Box
  initially need a balance of scepticism and enthusiasm.  Need top talent.
 Can initially classify Scrum sprints as "prototyping","requirements capture, ... "stabilization".
 Do not use a distributed development team initially.... especially after a merger.  culture clash.
 Some  initially see agile as micromanagment.
.Close.Box
Testers:  don't let them program!  If they want to then hire them as programmers!  Testing is up front and managers get involved. 
 Manager problems: promise customers what? What progress now? How does it effect xyz? When is the end of the project?
 Involve Human Resources! Performance reviews without predicted deliverables?
.Close

ConboyCoyleWang11
.Open ConboyCoyleWang11
 Kieran Conboy & Sharon Coyle & Xiaofeng Wang 
 People over Process: key challenges in agile development 
 IEEE Software Magazine V28n4(Jul/Aug 2011)pp48-57
 =POLL 27 PROJECTS AGILE PROBLEMS PRACTICES
 Good table defining agility.
 Transparency causes fear: provide alternative feedback, provide mentors, pairing.
 (dick)|-Also control big mouths!
 Every body must master all trades: pairing and rotation, allow self-assignment for learning, perhaps reintroduce specialist roles when it would help team. 
 More social skills: training using own examples, add documentation to communication.
 Lack of business/domain knowledge: enterprise training+interactive niche training modules, hire tech+business skills.
 Need to adopt agile values and principles as well as practices: many get trained or go to conference, coaching and championing, cross-team observation, assess values not practice. 
 Motivation: include motivated in each team, collect and share success stories. 
 Devolved decision-making: sharing and learning, democratic voting, manager as facilitator. 
 Need agile compliant performance evaluation: bredth not depth, 360 degree evaluation.
 Recruitment: special processes, team recruiting, put new graduates on agile projects to learn hands-on. 
.Close

ConboyFitzgerald11
.Open ConboyFitzgerald11
 Kieran Conboy & Brian Fitzgerald
 Method and Developer characteristics for agile method tailoring: a study of XP expert opinion
 ACM TOSEM Trans Software Eng & Methodology V20n1(Jan 2011)#2.1-30
.See http://doi.acm.org/10.1145/1767751.1767753
 =INTERVIEWS 16 XP EXPERTS 16 PRACTITIONERS AGILE TAILORING 
 XP is a rigid process that is never completely adopted. 
 Tailoring proceeds ad hoc and backwards -- adding practices as desired. 
 Table II. Research needed to clarify when XP is good, what parts are dependent, develop a rationale for each practice, ...
 Table III. Advice to those about to adopt a process/method
.List
 Formally analyze your situation,  before the project starts, to see if the method fits. 
 Involve all the stakeholders. 
 What are the organizational limits on adopting the process? 
 Train before you try it out. Accept/reject a practice after trying it. 
 Include practical training before tailoring. 
.Close.List
 RUP is not mentioned.   But comes with tailoring instructions.
.Close

ConstantineLockwood02
.Open ConstantineLockwood02
 Larry L Constantine & Lucy A D Lockwood
 Usage-Centered Engineering for Web Applications
 IEEE Software Magazine V19n2(Mar/Apr 2002)pp42-50
 =EXPERIENCE  =DEMO AGILE WWW/NET USECASE METHOD PROCESS CARDS
 Usage-centered design differs from user-centered design in using models(role, task, content), engineering to provide tools supporting user tasks.
 Process involves exploration and iteration.
 task cases: technology free essential abstract description of user's intentions and system's responsibilities.
 Content model aka abstract prototype  based on several canonical forms:
.See http://foruse.com/articles/cannonical.pdf
 Navigation map connects interaction contexts.
.Close

CusumanoMaccormackKemererCrandall09
.Open CusumanoMaccormackKemererCrandall09
 Michael A Cusumano & Alan MacCormack & Chris F Kemerer & William Crandall
 Critical Decisions in Software Development: Updating the State of the Practice
 IEEE Software Magazine V25n5(Sep/Oct 2000)pp84-87
 =SURVEY  PROCESS MANAGEMENT waterfall vs agile ONESIZE QUALITIES
 Revisits
.See [CusumanoMaccormackKemererCrandall03]
showing a wide range of processes and qualities.
 One size does not fit all.
 Must choose a process to fit the situation.
 Distributed development gives rise to a more modular structure and needs special learning to pay off.
 A rigid process can give higher quality but at risk of loosing innovative products.
.Close

CusumanoSelby95
.Open CusumanoSelby95
 Michael Cusumano & Rick Selby
 Microsoft's Secrets: How the world's most powerful software company creates technology& shapes markets & and manages people
 Simon & Schuster September 1995
 =REPORT MICROSOFT PROCESS PEOPLE MS-PROCESS AGILE
 See also 
.See [Keuffel95b]
,
.See [Bond95]
,
.See [MyersW95]
, and an extract in 
.See [CusumanoSelby97]
 For a view of the later Microsoft proceesses, see
.See Cusumano06
 Key observations:
.Box
MS objective was to quickly and cheaply establish and dominate a market and become de facto standards

Scale up hacker culture to many small concurrent teams with frequent synchronisation and periodic stabilization.  Aim to "Grow" rather than Design Software.
 Process::= Planning;Development;Stabilization,
 Planning::=Vision;Spec;Organize,
 Development::=(vision&spec&design&tests evolve and grow in parallel)&(first1/n; second1/n; third1/n; ...),
 n in {3,4}.
 each_1/n::=code&test&stabilise_features; integrate&test&debug;BUFFER time.
 Frequent synch/daily build.
 Stabilization::=Internal test; external test; Prepare for release.
 Fixed dates and multiple releases
 Continuous customer feedback
 Aim: large teams work like small ones.

Focus on the production of code (not design vs documentation). Minimal 
optional high level architectures.  Some implementation decisions (data 
structures) may be documented.  "One document. One. It's the Source code."

Costs:1 tester for each developer PLUS >1 customer-support engineer per 
developer
.Close.Box
 Also Warren Keuffel's notes
.See ./notes/Keuffel95b.html
on Cusmano's talk at ICSE 1995.
.Close

deJong07
.Open deJong07
 Jennifer deJong
 It's Lean, But Is It Agile?  Iterative methods are closely aligned
 SD Times  (15 Jun 2007)
.See http://www.sdtimes.com/article/story-20070615-04.html
 =ARTICLE AGILE = LEAN XP Crystal Beck Cockburn
.Close

DeMarcoBoehm02
.Open DeMarcoBoehm02
 Tom DeMarco & Barry Boehm
 The Agile Methods Fray
 IEEE Computer Magazine V35n6(Jun 2002)pp90-92
 =DEBATE AGILE METHODS
 Previous
.See [Boehm02]
 Individual skills or organizational rules?
 Also see "Duking it out" in  Software Development Magazine V10n7(Jul 2002)pp53-55
.Close

DenningEtAl08
.Open DenningEtAl08
  Peter J. Denning & Chris Gunderson & Rick Hayes-Roth
 The Profesion of IT: Evolutionary System Development
 Commun ACM V51n12(Dec 2008)pp-
.See http://doi.acm.org/10.1145/1490360.1409371
 =REPORT EVOLUTION PROCESS AGILE  USA GOVERNMENT LTEs RISKS FITNESS
 Important to understand how fast a situation is changing and make sure that software is developed and delivered before the requirements change.
 USA procurement rules allow 
.Key LTE
-- Limited Procurement Experiments --
that don't follow the BDUF waterfall.
 Reports that the W2COG was able to deliver in 18 months an 80% complete version of software using LTE ($100K) and evolution while a parallel BDUF  project delived only a concept document ($1.5M).
.Close

Doernhoefer06a
.Open Doernhoefer06a
 Mark Doernhoefer
 Surfing the Net for Software Engineering Notes: Requirements Management
 ACM SIGSOFT Software Engineering Notes V31n2(Mar 2006)pp17-25
.See  http://doi.acm.org/10.1145/1118537.1118553
 =SURVEY NET REQUIREMENTS
 Excellent survey of resources on the web
.See http://www.jiludwig.com/
.See http://cio.doe.gov/ITReform/sqse/requirements_management.htm
.See http://www.goldpractices.com/practices/mr/index.php
.See http://www.sei.cmu.edu/str/descriptions/reqtracing.html
.See http://www.agilealliance.com/articles/AgileArticlesCatSearch?category=Requirements
.See http://www.paper-review.com/tools/rms/read.php
(tools)
.See http://www.opengroup.org/architecture/togaf8-doc/arch/p2/p2_req.htm
.See http://www.rallydev.com/life_cycle_management.jsp
.See http://www.erequirements.com/app?service=page/Methodology
.See http://www-306.ibm.com/software/rational/offerings/reqanalysis.html
.See http://www.telelogic.com/
.See http://www.iceincusa.com/16CSP/content/8_requir/reqfrm.htm
plus lots more...
.Close

Dowson86
.Open Dowson86
 M Dowson(ed)
 Iteration in the Software Process
 Proc of the 3rd Int Software Process Workshop (Nov 1986)
 =PROCEEDINGS non-sequential lifecycle PROCESS ITERATION AGILE
.Close

DrobkaNoftzRaghu04
.Open DrobkaNoftzRaghu04
 Jerry Drobka & David Noftz & Rekha Raghu
 Piloting XP on four mission-critical projects
 IEEE Software Magazine V21n6(Nov /Dec 2004)pp70-75
 =EXPERIENCE XP AGILE 4 Motorola Projects
 Gained a minimum of 260% productivity vs waterfall (incremental was 162%) with 70-90% test coverage, and with a 51..75% improvement in quality (defects at system test/KAELOC)
 High morale and confidence, training easier.
 Challenges: fitting with non-XP projects and managers.  Need thorough training and coaching.
 Did an initial "blitz" software architecture rather like Unified Process.
.Close

DybaDingsoyr09
.Open DybaDingsoyr09
 Tore Dyba & Torgeir Dingspoyr
 What do we know about agile software development
 IEEE Software Magazine V26n5(Sep/Oct 2009)pp6-9 + Correspondence V26n6(Nov/Dec 2009)p8
 =SURVEY EMPIRICAL RESEARCH AGILE XP
 Agile processes can improve customer satisfaction, productivity and job satisfaction.
 They can be difficult to introduce into a large organization.
 Being the onsite customer is stressful and hard to sustain.
 A Team needs a strong focus on both the interpersonal and the team goals.
 Skill and experience helps.
 May not be the best approach for large projects.
 Need more research. 
 (William Adams)|- fads, bullets, need to match situation to method/process.
.Close

EmeryTrist60
.Open EmeryTrist60
 F E Emery & E L Trist
 Socio-technical Systems
 Management Science, Models and techniques, V2(?? 1960)pp83-97
 =ESSAY SYSTEMS PEOPLE TEAM
 Similar observations in British coal mining and Indian textile mills: a composite group/team oriented organization with complex roles and interaction outperforms a rigid hierarchical organization.  Also less rigid form ad less symptoms of stress (illness, accidents, etc).
 Managers should manage interactions between teams rather than micro-manage the internal structures of teams.
 (dick)|-probably applies to agile vs rigid processes.
.Close

ErdogmusMorisioTorchiano05
.Open ErdogmusMorisioTorchiano05
 Hakan Erdogmus & Maurizio Morisio & Marco Torchiano 
 On the Effectiveness of the Test-First Approach to Programming
 IEEE Trans Software Engineering  V31n3(Mar 2005)pp226-237
 =EXPERIMENT TESTING AGILE TFD TDD  
 Summarizes previous studies: test-first makes no difference or improves quality and may or may not improve productivity.
 This paper has a controlled experiment comparing test-first with test-last development of a series of user stories.
 Test-first programmers broke stories into a series of tests and added one test and then added code to make program pass test.  Test last coded complete story and then carried out all tests.
 Experiment: 40PCs Java JUnit ECLIPSE CVS, 35 3rd year volunteer students, 11 dropped out.
 Quality measure via hidden acceptance tests. 
 Productivity in terms of number of stories per unit time.
  Theories: Test-first may tend to increase the number of tests, the quality, and productivity.  However more tests anyway may increase quality and productivity.
 My translation of their statistics results:  
.Box
 quality >= 0.55 + tests/10.  NOTE: not a linear equation but an inequality.
 More tests increase the minimum number of tests passed in the acceptance 
testing.
 Other factors can improve quality as well as tests.
 productivity= 0.255 + 0.659 tests.
 Test-first programmers did more tests on average.
 Test-first programmers where more productive and produced the same quality code.
 30% dropped out -- "morbidity"
.Close.Box
.Close

Evans01
.Open Evans01
 Gary K Evans
 Palm-sized Process: Point-of-sale gets agile
 Software Development Magazine V9n9(Sep 2001)pp28-32
 =CASESTUDY AGILE POS ITERATIVE EVOLUTION Java PEOPLE LITE RUP UML Modeling LEGACY SYSTEM
 Unexpected complexity. 14 deliveries, one per 4 weeks, small team, good manager, cubicles+war-room w white boards.
 ()|- next project will reduce modeling further.
.Close

EvansEtal03
.Open EvansEtal03
 Gary Evans & Allen Vander Meulen & Donna L Davis & Scott Meyers & Name Withheld
 Curse of the Living Code: Five Bone Chilling Tales of IT
 Software Development Magazine V11n10(Oct  2003)pp29-31
 =ANECDOTEs  AGILE REQUIREMENTS USER RISKS COMMENTS EVOLUTION
 Agile development meets big design up front - of a database.
Godzilla meets Bambi? Management may require agile development but force a
complete set of requirements first!
 Programmer removes comments placed by colleague to preserve job security.
 User interface has 11 or more different ways to close a window.
 When a programmer chooses a bad user interface, the user and organization pays,
not the programmer.
 There is no such thing as a one-off solutions.... 
"not only did it survive, it mutated into a two-headed beast". 
.Close

FaegriHanssen07
.Open FaegriHanssen07
 Tor Erlend Faegri & Geir Kjetil Hanssen 
 Collaboration, Process Control, and Fragility in Evolutionary Product Development
 IEEE Software Magazine V24n3(May/Jun 2007)pp96-104 
 =EXPERIENCE Evo GILB EVOLUTION METRICS IMPROVEMENT   
 Reports on a two-year process of introducing and adapting Tom Gilb's Evo  (1981) Process. 
 Evo has a strict weekly schedule, defines increments in terms of measurable stakeholder needs.
 It needs efficient tools to support the rapid weekly cycle of adding requirements and testing solutions.
 May need to add "Green weeks" where system is tested without new functions being added.  May need to have some 2 week iterations.
 Evo depends on the presence of the stakeholders.
 Evo improves customer satisfaction.

 (dick)|- for a good comparison of Evo with other agile methods see
.See [Larman04]
.Close

FairleyWilshire05
.Open FairleyWilshire05
 Richard E (Dick) Fairley & Mary Jane Wilshire
 Iterative Rework: The Good, the Bad, and the Ugly
 IEEE Computer Magazine  V38n9(Sep 2005)pp34-41 =ESSAY PROCESS STATISTICS QUALITY CONTROL CHARTS REWORK EVOLUTION ITERATION RE
FACTORING REWORK AGILE ITERATIVE Too much (>20%) or too little rework(<10%) means something is wrong.   So track % rework on a statistical control chart (Shewart 1920s) with upper and lower control levels. Trends, spikes, and random walks over the same limit trigger ro
ot cause analysis and improvement.
 All types of rework can be good, bad, or ugly!
 Rework= Evolutionary_rework | Avoidable_rework.
  Evolutionary_rework::=`response  to changing world`.
Avoidable_rework::=Retrospective_rework | Corrective rework.
 Retrospective_rework ::= `work that could have been before`.
 Corrective rework ::= `work the fixes defects in current or previous versions` Distinctions are not very objective but good enough to suggest process  improvements.
.Close

Fowler03c
.Open Fowler03c
 Martin Fowler
 Who needs an Architect?
 IEEE Software Magazine V20n5(Sep/Oct 2003)pp11-13
 =ESSAY AGILE ARCHITECTURE
 So what is architecture any way?  Things you want to get right early in a project because they are hard to change later.
.Close

FowlerHighsmith01
.Open FowlerHighsmith01
 Martin Fowler & Jim Highsmith
 The Agile Manifesto
 Software Development Magazine V9n8(Aug 2001)pp28-32 + letters V9n9(Sep 2001)p12 + V9n10(Oct 2001)pp13+16 + V9n11(Nov 2001)pp13+17
 =ADVERT PEOPLE > PROCESS & METHODS AGILITY XP SCRUM Crystal
 manifesto in sidebar on p30 signed by: kent beck, mike bedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C Martin, steve Mellor, Ken Schwaber, Jeff sutherland, & Dave Thomas.
 "Helpers not tellers"
 "delivery is not release"
 Long term agility relies on maintaining technical excellence and good design.
 "Maximize what is not done"
 agile_alliance::=http://www.agileAlliance.org.
Agile_Manifesto::paraphrase=following,
.Net
 Value individuals and interactions more than process and tools.
 Value Working software more than comprehensive documentation.
 Value customer collaboration over contract negotiation.
 Value responding to change over following a plan.
 But -- some value to lesser items above.
 Highest priority early, continuous, and long term delivery of currently valuable software.
  teamwork, review, support, interaction....
 ...
 
.Close.Net
.Close

Gancarz95
.Open Gancarz95
 Mike Gancarz
 The UNIX Philosophy
 Digital Press Newton MA 1995 151 pp. $19.95 ISBN 1-55558-123-4 BNB94-25895 QA76.76.063G365 CR9511-0943
 =ADVERT UNIX METHOD AGILE
.Box
Tenets
 1. Small is beautiful
 2. Make each program do one thing well
 3. Build a prototype as soon as possible
 4. Choose portability over efficiency
 5. Store numerical data in Flat ASCII files
 6. Use software leverage to your advantage
 7. Use Shell scripts to increase leverage and portabillity
 8. Avoid Captive User Interfaes
 9. Make every program a filter
 Plus ten lesser tenets
.Close.Box
.Close

Geer10
.Open Geer10
 David Geer 
 Are companies actually using secure development life cycles
 IEEE Computer Magazine V43n6(Jun 2010)pp12-15
 =POLL SECURITY METHODS PROCESSES SDLs SDL-agile SAMM BSIMM SSDL CLASP
 Security has to be part of the development of software from the get go -- it can not be added later.  
 Can use static analysis to catch holes in code.  Most security holes are design holes.  Commonly letting in unexpected attacks.
 Need to analyze and model threats.
 Survey by Errata. 
 81% were aware but only 39% are using a "formal methodology".
 Reasons not used include time, no need, cost, ...
.Close

GermainRobillard05
.Open GermainRobillard05
 Eric Germain & Pierre N. Robillard
 Engineering-based processes and agile methodologies for software development: a comparative case study
 J. Systems & Software V75n1-2(15 Feb 2005)pp17-27 $CR 0602-0171
.See http://www.sciencedirect.com/science?_ob=JournalURL&_cdi=5651&_auth=y&_acct=C000059573&_version=1&_urlVersion=0&_userid=521812&md5=851cb8e7e96cf9a729dcab38f42f8044
 =EXPERIMENT EFFORT COGNITIVE XP vs UPEDU RUP 
 Total effort similar with a high ceremony and a low ceremony process.
 Teams drawing diagrams did said they didn't help.
 Drawing diagrams does not resolve risks of an unknown technology.
 Teams forced to code early learned new technology and taught the other teams whaen they needed it (later).
.Close

Gladden82
.Open Gladden82
 G R Gladden
 Stop the Life-Cycle: I Want to Get Off
 ACM SIGSOFT Software Engineering Notes V7n3(Apr 1982)pp35-39
.See http://doi.acm.org/10.1145/1005937.1005945
 =HARMFUL SDLC Scenarios Agile Hollywood Prototypes Mockup
 Objectives first, mock ups second.
 System requirements and design obscure the real system!
 Fiascos occur mainly because of 
.List
 non-existant, vague, incomplete, ... requirements.
 Changing requirements effect everything and occur after sytem work is in progress.
 The traditional lifeccycle gives slow feedback from designers to stakeholders.
.Close.List
.Close

Glass05b
.Open Glass05b
 Robert L Glass  
 "Silver Bullet" milestones in Software History
 Commun ACM V48n8(Aug 2005)pp15-18
 =HISTORY LANGUAGES MODULES OPERATING SYSTEMS ACADEMIC METHODS CASE TOOLS  Object-Oriented agile open source
.Close

Gorton08
.Open Gorton08
 Ian Gorton 
 XML does Real Programmers a Service
 IEEE Computer Magazine V41n9(Sep 2008)pp100+98-99
 =JOKE HISTORY QUICHE  SPECIFICATION vs CODE DCE Corba PROCESS EMPIRICAL AGILE XML SERVICES AGENTS AI
 Real Programmers write code, late at night, just before the deadline.
 Agile allows real programmers to do what they want and provide the stakeholders with what they want. 
 XP: "[...] every one prefers muffins and expresso to writing specifications." 
.Close

Gotterbarn04
.Open Gotterbarn04
 Don Gotterbarn
 UML and Agile Methods: In Support of Irresponsible Development
 ACM SIGCSE Bulletin V36n2(Jun 2004)pp11-13
 =ESSAY RISKS AGILE UML RUP vs SYSTEM
 Examples of how focusing on programming is risky.
 A focus on programming can `accidental` damage the people effected by the software because we don't think outside the box.
 Examples: cataract removal design did not include the patient.... program to open door and start car... web page ignores some of stake holders.
 "One aspect of being a professional is developing systems that improve a situation rather than make it worse."
 Need a way to express/think: "In some cases, if you develop software in this way, it `might` have this consequence."
.Close

HazzanDubinsky08
.Open HazzanDubinsky08
 Orit Hazzan & Yael Dubinsky
 Agile Software Engineering
 Springer Pub NY NY(2008) ISBN 184001983 $CR 0912-1151
 =MANUAL PEOPLE AGILE TEAMS TESTS REFLECTION HUMAN ORGANIZATIONAL TECHNOLOGY
 HOT::analysis=Human >< Organizational><Technological.
 Describes a process that helps people learn what might be taught directly in other books.
 Not clear if they are training students or teachers.
 The treatment of refactoring is completely inadequate.
.Close

HazzanLeron10
.Open HazzanLeron10
 Orit Hazzan & Uri Leron
 Disciplined and free-spirited: "Time-out behavior" at the Agile Conference
 Elsevier Journal of Systems and Software V83(2010)pp2363-2365 $CR ????-????
 =OBSERVATION ANTHROPOLOGY AGILE PEOPLE CONFERENCES INTERACTIONS COMPETITIONS PUB ETIQUETTE
.Close

HighsmithCockburn01
.Open HighsmithCockburn01
 Jim Highsmith & Alistair Cockburn 
 Agile Software Development: The Business of Innovation
 IEEE Computer Magazine V34n9(Sep 2001)pp120-122 +  letters  IEEE Computer Magazine V34n12(Dec 2001)p4
 =MANIFESTO AGILITY  PEOPLE not PROCESS ASD XP etc
.Close

HirschmanLindblom62
.Open HirschmanLindblom62
 A O Hirschman & C E Lindblom
 Economic Development, Research and Development, Policy Making: Some Converging Views
Behavioral Science V7(1962)pp211-222 &
.See [Emery69] pp351-371
 =SURVEY AGILE PROCESSES in ECONOMICS SOCIOLOGY POLITICS ORGANIZATION
 Argues that complexity, uncertainty, and value conflicts are best handled incrementally with piecemeal unbalanced development that is driven by what happens.
 "incremental meandering"
 "adjusting the ends to fit the current means"
.Close

HuntThomas04c
.Open HuntThomas04c
 Andy Hunt & Dave Thomas
 Imaginate
 IEEE Software Magazine V21n5(Sep /Oct 2004)pp96-97
 =ANECDOTE USERS PRAGMATIC RAPID COBOL AGILE
 By using old technology that works and gives the user what they want rapidly you can do what is impossible using the latest technology and methods.
 imaginate::="to instantiate into reality by pure will of imagination".
.Close

JacksonTwaddle97
.Open JacksonTwaddle97
 Michael Jackson & Graham Twaddle
 Business Process Implementation: Building Workflow Systems,
 Addison Wesley ACM Press 199? ISBN 0-201-17768-4 3rd hd58.87.j32 1997
 =EXPERIENCE SPECIFICATION MODEL OFFICE WORKFLOW PEOPLE DATA PROCESS FLEXIBLE vs BUSINESS RULES TABULAR GRAPHIC METADATA
 workflow_problem_frame ::= following,
.Net
 |-(minimal_workflow_frame):The machine supports an office that interacts with an outside world.
 |-The prime business need is to keep track of long term commitments, contracts, and obligations.
 |-There  are rigid business rules and flexible activities.
 |- activities are multitasked error correcting that proceed at a human pace.
 |- not safety critical.
.Close.Net
  theoretical_method:= data; process; tasks; workflow.
 In practice incremental and iterative delivery is feasible.
 data:=`simple ERD`, like SSADM.
 task_types:=initiated performed content 
.See [task_details].
   initiated:=X | T | P | I.  X=eXternal, T=Time, P=follows Preceeding, I=Internally.
   performed= A | M, A=Automatically, M=not A, `Manually`,
   content:= E | K| U | D | O, E=dataEntry, K=checK, U=Update, D=Decision, O=Output.
  Tasks involve entities.  
 LC:=" life cycle".
 An entity life cycle is a defined sequence of stages but an entity may not progress thru the stages in such a simple way.  Office work may backtrack, hang up, fail, or multitask parts of stages at one time.  Stages may not be omitted.  Backtracking (a `setback`) means handling side-effects: beneficent, neutral, and intolerable. cf 
.See [JSP].
   In a stage contains a task that fails then the current life cycle fails and initiates a different one instead.
   Stages determine states:  State = ("In" | "Failed" | "Awaiting" | "Halted" ) stage.
    Within a Stage many tasks can execute in parallel.  some can spawn (one|many (inclusive | exclusive)) subtasks (sometimes). One subtask can be spawned by many tasks, and a subtasks can restart their parent tasks (in a loop).
    Task states = null; start; (n/a | run | failed | passed).  passed states do not spawn subtasks, run states must start their subtasks.  Task states determine life-cycle states.
  There are rules for assigning tasks to stages.
  One life cycle can depend on another one.  Changing stage depends on one(or all) other linked entities of a given type is|are past a certain stage.  Tasks can start and halt other life cycles.
  Entities are placed in classes. Classes form a `heterarchy` -- multiple inheritance.  Also classification entities -- classes of objects each defining a class of object!
  Entities play roles in entity life cycles.  roles require only a subset of the attributes,  Also several types of entity can play the part in a single role.
  Datasets are structured  navigation paths between entity types.  `from A access one B and many Cs`.  They are chosen to fit tasks.
 Programs support tasks - within task context and using task content. actions include SET_RESULT, START_LC, SUSPEND_LC, RESUME_LC, CANCEL_LC, SETBACK_LC, WAIT..., SIMPLE_CHECK, COMPLEX_CHECK, SIMPLE_SET, APPLICABLE_WHEN.  Some tasks must not be repeated, others may be repeated when backtracking.
 Decision Tables!
 Tasks and life cycle work mainly define wrong sequences.  Work flows help get good things done.   Work flows are about scheduling, options, menus, and efficiency.  Work flows are based on a relational data base:
 task_details:=Net{
 Each task is in a stage of a life cycle of an entity.
 Each task has a task_type that has a program, data set, and a set of skills.
 Tasks are related to users who can/should do them by Skills and by stages and departments for example. 
}.
  Detailed reporting and so tuning of the workflows.
 Life cycle definitions and the office workflow are also held in the data base. "Process representations become data".  Process data is PLANs and FEATUREs. 
 The only purpose of documentation is understanding.... but if documentation is in a data base is also useful to the software.
 dick:`the office workflow frame fits agile software development process.`
.Close

JanzenSaiedian05
.Open JanzenSaiedian05
 David Janzen & Hossein Saiedian
 Test-Driven Development: Concepts,Taxonomy, and future directions.
 IEEE Computer Magazine  V38n9(Sep 2005)pp43-50
 =SURVEY TEST-DRIVEN PROCESS TDD XP SCRUM AGILE EDUCATION
 Well written survey of history and literature on test-driven development.
 Predicts that TDD will not go away.
 Refs
.See [Beck01]
.See [Reifer02]
.See [ErdogmasMorisioTorchiano05]
.Close

JaspanEtAl09
.Open JaspanEtAl09
 Ciera Jaspan & Michael Keeling & Larry Maccherone & Gabriel L. Zenarosa & Mary Shaw 
 Software mythbusters explore formal methods
 IEEE Software Magazine V26n6(Nov/Dec 2009)pp60-63
 =REPORT DISCUSSION EXPERIENCE MYTHS FORMAL METHODS AGILE FSM LOGIC MATHEMATICS
 Reference a list
.See [Hall90]
of seven myths
 Formal methods are richer than in 1990.
 They are now used in requirements to get precision and understanding.  
They are embedded in tools and environments reducing the need for mathematical maturity. 
 They enable communication and evolution and so support agility. 
 An FSM model for understanding lead to better code. 
 Must match the method to the problem cost-effectively.
 Formal methods are being domesticated.   
.Close

Jenkins06
.Open Jenkins06
 Stephen B Jenkins 
 Musings of an "old-school" programmer
 Commun ACM V49n5(May 2006)pp124-126 + letter V49n6(Jun 2006)pp11-12
 =ESSAY TECHNICAL MINIMALISM agile  multi-language TOOLS Vim/Emacs bash no debugger UML IDE
 Projects that are small enough to be tackled by an individual do not need complex tools or extensive documentation -- just a vision and iterating towards that vision.
 Like chopping a bike or crafting an essay, 
.Close

KarlstromRuneson05
.Open KarlstromRuneson05
 Daniel Karlstrom & Per Runeson 
 Combining agile methods with Stage--Gate Project Management
 IEEE Software Magazine V22n3(May/Jun 2005)pp43-49 
 =EXPERIENCES SD SDLC+XP AGILE PROCESS MANAGEMENT ABB Ericsson Vodafone 
 Engineers are ready for agile processes but managers fear them.  Success needs both!
 XP leads to better quality.
 The SDLC documentation should be treated as another XP User Story.
 Agile process handles the day-to-day process of development and lets managers concentrate on the overall progress.
.Close

Kerner10
.Open Kerner10
 Sean Michael Kerner
 Mozilla Firefox Gets More 'Agile' with Lorentz
 developer.com (Jan 22 2010)
.See http://www.developer.com/open/article.php/3860226/Mozilla-Firefox-Gets-More-Agile-with-Lorentz.htm
 =NEWS MOZILA AGILE LORENTZ RELEASES
.Close

KlasNakaoElberzhagerMunch10
.Open KlasNakaoElberzhagerMunch10
  M Klas & H Nakao & F Elberzhager & J Munch
  Support planning and controlling of early quality assurance by combining expert judgment and defect data--a case study
  Empirical Software Engineering V15n4(?? 2010)pp423-454 $CR
 =EMPIRICAL ESTIMATION REQUIREMENTS OUTSOURCED QUALITY ASSURANCE EFFORT EXPERTS STATISTICS SQA
 Shows that expert opinion improves predictions using history. 
  Case study only of requirements. But probably same hybrid method will work with other artifacts.
  Models only apply to independent validation and verification. 
  (dick)|-Probably not needed with an agile process.
.Close

Knight09
.Open Knight09
 Allan Knight
 Facilitating the integration and impact measurement of technologies and media that augment learning environments
 Thesis Defense CSci UCSB(Sep 8th 2009)
 =THESIS WWW/NET EDUCATION TECHNOLOGY PEOPLE CULTURE DATA PERFORMANCE USER EVOLUTION
 New devices, social media, and connectivity. 
 Turning up in classrooms. Opportunities or distractions in the classroom?
 Stakeholders: teachers + students + researchers.
 |-We can create computer systems that facilitate integration of the new into the learning as well as support research.
 Four projects: DeCAF(event streams/producers/consumers), AutoCap(captioned audio), DataCafe(research data), PAIRwise(Plagiarism)
 Lessons learned:
 (DataCafe): relational database didn't scale. Flatter files fast enough. Interface difficult to use.
 (PAIRwise):  Evolved in purpose and implementation.   Installation simplified. Initial version fragile. 
.Close

Kobryn02
.Open Kobryn02
 Chris Kobryn
 Will UML  2.0 Be Agile or Awkward
 Commun ACM V45n1(Jan 2002)pp107-110
 =HISTORY UML 1.* =ESSAY on UML 2.0
 Second system effect: 
.See [Brooks95]
 UML2.0 will have 4 parts: infrastructure, superstructure, OCL, and Diagram Interchange
 Resources
.See http://www.omg.org/uml
.See http://www.uml-forum.com/
.See http://www.telelogic.com/publications/uml_models/
.Close

KrautStreeter95
.Open KrautStreeter95
 Robert E. Kraut<robert.kraut@cmu.edu> & Lynn A Streeter <lstreet@advtech.uswest.com>
 Coordination in Software Development
 Commun ACM V38n3(Mar 1995)pp69-81
 =EXPERIENCES POLL LARGE PROJECTS AGILE
 No single cause
 Coordination problems increase as project size and uncertainty increase
 Communication problems are very common
.See http://csci.csusb.edu/dick/notes/KrautStreeter95.html
 Provides evidence for agile values before the agile manifesto.
.Close

Krill06
.Open Krill06
 Paul Krill
 Agile programming has fallen short, conference told
 Infoworld(13 Mar 2006)
.See http://ww6.infoworld.com/products/print_friendly.jsp?link=/article/06/03/13/76420_HNmcconnell_1.html
 =REPORT McConnell BEST & WORST IDEAS Agile RISKS REQUIREMENTS ITERATION INCREMENTAL EVOLUTION REUSE ONESIZE
 Importance of people, evolution, risk, estimation, management,...
 One size does not fit all: different projects need different processes
 Next
.See [Krill10]
.Close

Krill10
.Open Krill10
 Paul Krill
 Agile programming 10 years on: Did it deliver?
 Infoworld(Nov 2 2010)
.See  http://infoworld.com/d/developer-world/agile-programming-10-years-did-it-deliver-761
 =INTERVIEWS AGILE EXPERIENCE XP Scrum LEAN PROCESSES Kanban RUP DSDM
 Agile depends on professional programming. It is no silver bullet. 
 Agile opened up this debate: is it better to document the requirement or to implement an approximation and iterate towards what is actually needed?
 Compare
.See [Krill06]
"Agile programming has fallen short..."
.Close

Larman04
.Open Larman04
 Craig Larman
 Agile and iterative development: a manager's guide
 Pearson Education Boston MA 2004 ISBN 0-13-111155-8 QA76.76.D47L39 2003
 =SURVEY=HISTORY AGILE METHODS Evo Gilb Scrum XP RUP   MANAGEMENT PROCESS
 Best summary of AGILE METHODS to date.
  Tackle riskiest non-functional requirement first!
.Close

LarmanBasili03
.Open LarmanBasili03
 Craig Larman & Victor R Basili
 Iterative and Incremental development: A Brief History
 IEEE Computer Magazine V36n6(Jun 2003)pp47-56 + correspondence V36n8(Aug 2003)pp5-6 from  Rita Creel
 =HISTORY AGILE METHODS IID evolution1950-2002 non-sequential processes
 IID::="iterative and Incremental Development" -- projects that avoided a single-pass sequential document-driven gated-step approach.
 Projects/People include 1950s:X-15, Mercury, Los Angeles MIS, IBM, Royce70 (!), Mills, IBM FSD, TRW, LAMPS, Gilb76, Trident, space shuttle, SDC, 1980s: weinberg, McCraken JacksonM, Swartout Balzer, Booch,  Boehm Spiral, Brooks86, ParnasClements86, CCPDS-R, Cleanroom, DOD-Std-2167A(!), Gilb88,
1990s: Mil-Std-498 replaces 2167A, Scrum, Shashimi, RAD, DSDM, CAATS, RUP, XP, FDD, CHAOS, 
2000: DoD 5000.2, Agile Alliance, ...
 Much evidence that IID works better.
 Creel corrects standards history.
.Close

Lindvall04
.Open Lindvall04
 Mikael Lindvall & Dirk Muthig &Aldo Dagnino& Christina Wallin & Michael Stupperich & David Kiefer & John May & Tuomo Kahkonen
 Agile Software Development in large organizations
 IEEE Computer Magazine  V37n12(Dec 2004)pp26-3
 =POLL AGILE TECHNICAL PROCESS ONESIZE XP ABB DaimlerChrysler Motorola Nokia
 Reports on meetings where several pilot XP projects were discussed 
 XP adopted in large organizations for the same business reasons as small ones: need to increase productivity without losing quality .
  Problems with specifications becoming obsolete before project finished.
 XP always needed  customization.
 It produced good or better software more quickly.
  Changes were handled faster.
  Morale was better.
  But XP doesn't fit well with existing practices in large organizations and so has to be tailored.
 Make it look like a CMM process.
 Change control boards do not work well with refactoring, continuous integration, Problems when XP team is not in one place.
  Problems with interfaces between XP team and Traditional team.
 Architecture is important.
 Clash between up-front top-down planning and XP planning game.
  Requirements were already inaccurate when XP started and were not user stories.
 Continuous testing vs an added round of acceptance tests done by a different team.
  XP pairing vs formal reviews for SQA.
  Management and QC want the old documentation and XP doesn't do documentation.
(dick)|- write a user story for each required piece of documentation and do the planning game on it.  "That will take us 2 days work, ..."
.Close

LippertEtal03
.Open LippertEtal03
 Martin Lippert & Petra Beck-Pechau & Jorn Koch & Andreas Kornstadt & Stefan Roock & Axel Schmolitzky & Henning Wolf & Heinz Zullighoven
 developing complex Projects using XP with Extensions
 IEEE Computer Magazine V36n6(Jun 2003)pp67-73
 =EXPERIENCE AGILE XP one-size IT-workplace-solutions
.Close

Little04
.Open Little04
 Todd Little
 Value creation and capture: a model. of the software development process
 IEEE Software Magazine V21n3(May/Jun 2004)pp48-53
 =EXPERIENCE AGILE  ECONOMICS ROI  
 Notes
.Close

Little05
.Open Little05
 Todd Little 
 Context-adaptive agility: managing complexity  and uncertainty
 IEEE Software Magazine V22n3(May/Jun 2005)pp28-35 
 =PRACTICE ONESIZE PROJECT -> PROCESS AGILE landmark
 Classify projects as Skunks, Dogs, colts,Cows and Bulls.
.Table Project	Simple	Complex
.Row Uncertain	Colt	Bull
.Row Certain	Skunk/Dog	Cow
.Close.Table
 A Skunk is typically a prototype but a Dog is a mature project.
 Projects change state. 3 common trajectories. Skunk->Colt->Dog, Skunk->Colt-> Bull->Cow->Dog, Bull->Cow->Dog.
 Fit the process to the animal.
Core practices + adaptions.
 Core Practice: product plan,prioritize requirements, quality targets, continuous integration, involve experts users, Project Dashboard.
 Project_dashboard:=`web-based project status updated weekly`.
 Colts benefit from short iterations, daily stand up meetings, and automated testing.
 Cows need more rigorous management tools and procedures: CPM, subprojects, teams coordinated by Scrum, functional specs of interfaces,...
 Bulls need BOTH Colt and Cow practices.  They need the best experienced managers.
 Has several process and project metrics.
.Close

LuqiZhangBerzinsQiao04
.Open LuqiZhangBerzinsQiao04
 Luqi & Lin Zhang & Valdis Berzins  & Ying Qiao
 Documentation driven development complex real-time systems
 IEEE Trans Software Engineering  V30n12(Dec 2004)pp936-952
 =DEMO TOOL CAPS-PC AUTOMATE DOCUMENTATION REQUIREMENTS DESIGN CODE TIMING FSA/STD CARA AGILE STAKEHOLDERS LATTICES METRICS
 DDD ::= "Documentation Driven Development".
 Central dynamic data base with automatic translation between requirements, architecture, and components plus translations and executable prototypes for stakeholders.
 Process management. Risk assessment. metrics: requirements volatility, organization efficiency, product complexity, technology maturity (temperature) , ...
 CARA blood pressure maintenance IV for army stretcher.
.Close

LycettEtal03
.Open LycettEtal03
 Mark Lycett & Robert D Macredie & Chaitali Patel & Ray J Paul
 Migrating Agile Methods to Standardized Development practice
 IEEE Computer Magazine V36n6(Jun 2003)pp79-85
 =EXPERIENCE AGILE embedded in SEQUENTIAL PLANNED PROCESS RUP in CMM PATTERNS one-size
 disclaimer: authors from my Alma Mata.
 Problems with embedding iterative RUP into a hierarchical planned organization pursuing CMM certification.
 Proposed situational process model to evolve catalog of situation><practice patterns because CMM audit needs documented practices.
 Used RUP UML process modeling.
.Close

MaidenJones10
.Open MaidenJones10
 Neil Maiden & Sara Jones
 agile requirements -- can we have our cake and eat it to?
  IEEE Software Magazine V27n3(May/Jun 2010)pp87-8
 =ESSAY AGILE REQUIREMENTS HISTORY CARDS TOOLS CDs JISC CONVERSATION SPACE
 Too much documentation is wasted effort. 
 Lack of documentation leads to predictable problems: Ignored nonfunctional requirements, inducting new members, evolving application, etc. 
 Alternatives to paper work:
(1)  Cards?
(2) PDF requirements on CD was ignored. 
(3) Perhaps something like
.See [Cook10]
with digital tools?
 JISC::="joint information systems committee".
.Close

MargariaSteffen10
.Open MargariaSteffen10
 Tiziana Margaria & Bernhard Steffen
 Simplicity as a driver for agile innovation
 IEEE Computer Magazine V43n6(Jun 2010)90-92
 =HISTORY TECHNOLOGY MATURITY DAIMLER AUTOMOBILE ANALOGY IT KISS STANDARDS COMPONENTS INFRASTRUCTURE PROCESSES
 Bad roads, bespoke technology, no support structure, no standard parts, no standard interface. 
So early cars needed professional chauffeur to repair tires and maintain the engine.
Which limits the market. 
 Cost of updates.  
 Maturity leads to standards and simplicity. 
 Slogan: "IT simply works"
.Close

Martin03
.Open Martin03
 Robert C Martin (Uncle Bob)
 Agile Software Development: Principles, Patterns, and Practices
 Prentice Hall PTR UpperSaddle River NJ 2003 ISBN 01235974445 CR 0502-0167
 =UNREAD =ADVERT AGILE PATTERN  Object-Oriented UML TECHNICAL DESIGN CODE
.Close

Martin09
.Open Martin09
 Robert C Martin
 Clean Code: A Handbook of agile software craftsmanship
 Pearson Education 2009 Boston MA ISBN 0-13-2350088-2 $CR 0912-1114 and 1003-0222
 =HOWTO CODE TECHNICAL QUALITY WRITING JAVA
 Demands study but tends to change the way you look at code.
 All examples are Java 6 but it changed my C++ standards.
 Stresses the iterative and evolutionary nature of code -- enhancement and refactoring as the constant change.
 90% is well known advice dating back 30 years.
 Some of it is startling
.List
 Comments should be reduced in favor of more better named  functions and variables.
 Objects and data structures are different:
Objects hide data and provide functions, but 
data structures give access to data and have no other function!
 Writing tests is a good way to learn an API and pays for itself by proving documentation.
 Refactoring an SQL class leads to a functional decomposition of classes into subclasses.
 "Inversion of Control" and "Dependency Injection" -- dependencies are created at run time.
 Use Domain Specific Languages at the systems level.
.Close.List
 Good list of smells and heuristics in Chapter 17.
 Notes and recommend an interesting property of Java 5 "enum"s 
-- can specify functions that return different values for each value in the enum.
Better than "switch".
.Close

MathiassenNgwenyamaAaen05
.Open MathiassenNgwenyamaAaen05
 Lars Mathiassen & Ojelanki K Ngwenyama & Ivan Aaen
 Managing Change in process improvement
 IEEE Software Magazine V22n5(Nov/Dec 2005)pp84- 91
 =CASE STUDY 4 DANISH COMPANIES VARIED SPI IMPROVEMENT
 All had limited success: software process was improved,none achieved as much as they wanted initially.
 SPI is organizational change.
 (above) |- need to use change management techniques.
.Set
 Understand context: source, organization structure,existing processes and needs.
 Create (and communicate) vision
 Manage commitment
 Plan
 Stay agile
 Monitor improvement
.Close.Set
 One size does not fit all.  For example,
.Box
 maintenance does not follow a development process.
 Small and simple projects do not need all the procedures and data recording of a complex or large project.
.Close.Box
 In all 4 projects nobody expected that management would have to change!
.Close

MillerR03
.Open MillerR03
 Roy Miller
 Managing Software for Growth: without fear, control, and the manufacturing min
dset
 Addison-Wesley Longman, Boston MA 2003 ISBN 0321117433 $CR 0409-1014
 =UNREAD EVOLUTION ITERATION PROCESS AGILE COMPLEXITY
 Software is not a product to be manufactured (predictable and repeated process
 and end point)
.Close

MillingtonStapledon95
.Open MillingtonStapledon95
 Don Millington & Jennifer Stapledon
 Developing a RAD Standard(DSDM)
 IEEE Software Magazine V12n5(Sep 1995)pp54-55
 =ADVERT DSDM AGILE
.Box
DSDM::=Dynamic Systems Development Method.

60 organisations including commerce and academe.

DSDM Consortium Secretariat, The Coach House, Church Hill, Kingsworth, Ashford, KENT TN23 3EG, UK.

Key success factors: easy access to users, stable nd skilled development team, a commercial appliation with clearly defined user group and flexible requirements.

Also:
 business requirements>quality
  what not how
  motivate team to business goals
  integrate testing thru out
  base estimates and risks assessment on functions of end product not development actions
  Baseline high level requirements.

Use time box scheduling:  "Given this personnel-time, how much functionallity can be completed?"

Three phases, each iterative

.Close.Box
.Close

MoeDingsoyrDyba09
.Open MoeDingsoyrDyba09
 Nils Brede Moe & Torgeir Dingsoyr & Tore Dyba
 Overcoming barriers to self-management in software teams
 IEEE Software Magazine V26n6(Nov/Dec 2009)pp20-26
 =EMPIRICAL 5 TEAMS PEOPLE AGILE Scrum PROCESS MANAGEMENT
 Letting a team manage itself leads to efficiency ... But ...
 Avoid specialisms, get generalists, encourage working together,and collocate the team. 
 Assign people to only one team at a time. 
 Build trust and commitment by avoiding unneeded control, under resourcing, etc.  
.Close

Molokken-OstvoldMagne Jorgensen05
.Open Molokken-OstvoldMagne Jorgensen05
 Kjetil Molokken-Ostvold & Magne Jorgensen
 A Comparison of Software Project Overruns -- flexible versus sequential development Models
 IEEE Trans Software Engineering  V31n 9(Sep 2005)pp754-766 $CR 0703-0266
 =POLL INTERVIEWS 18 COMPANIES COST TIME ESTIMATION vs PROCESS AGILE SEQUENTIAL EVOLUTION ITERATION NORWAY
 Effort. Sequential projects had bimodal estimates either accurate or 100% low. Flexible  projects had estimates distributed about accurate.
.Close

MorrisSegal12
.Open MorrisSegal12
  Chris Morris & Judith Segal
  Lessons learned from a scientific software development project
  IEEE Software Magazine V29n4(Jul/Aug 2012)pp9-12
.See http://www.computer.org/software
  =EXPERIENCE AGILE SCIENTIFIC  PROJECT LIMS LABORATORY INSTRUMENTATION BIOLOGY DATA
  Consider the software from the user's point of view. 
Clients are not always users. 
  Users didn't give good descriptions of what was needed. 
  High level goals stated at the start of the project may conflict with users actual needs. 
  You have to understand the users.
  Start with what the users do now.
  If you have to write a guide so user can use the UI -- you've got a bad UI. 
The UI should reflect current systems. 
  Personas help understanding. 
  Communications within the team is vital. 
Teams spread across branches of the enterprise and world need special training. 
  Plan for maintenance from the start. Who will pay?  
  If adopting the software changes work practices you have an extra challenging project. 
.Close

Mountain10
.Open Mountain10
 Gwaredd Mountain
 Game Development in a Post-Agile world
 Gwaredd Space (Feb 5 2010)
.See http://gwaredd.blogspot.com/2010/02/game-development-in-post-agile-world.html
 =POLEMIC ANTI-Scrum PEOPLE vs PROCESS GAMES 
 Game_production::= Pre_production; Production; Post_prod.
 Pre_production:=Organic+creative+exploration; answers & technology.
 Production:=make content & spend money
 Post_prod:=alpha; beta.
 alpha:=polish game play;
 beta:=bug fixing;
 "We can change our approach throughout a project lifecycle; we do not always have to stick to the same thing throughout."
 Compare with the Rational Unified Process with its adjusting mix of disciplines and 4 phases.
.Close

Mugridge08
.Open Mugridge08
 Rick Mugridge  
 Managing Agile project requirements with storytest-driven development
 IEEE Software Magazine V25n1(Jan/Feb 2008)pp68-75
 =DEMO REQUIREMENTS TESTS FIT TABULAR SCENARIOS 
 FitLibrary::=http://sourceforge.net/projects/fitlibrary/.
 FitNesse::=http://www.fitness.org/.
 Also see
.See ./samples/methods.html#Fit
.See [MartinMelnick08]
.Close

NerurBalijepally07
.Open NerurBalijepally07
 Sridar Nerur & VenuGopal Balijepally 
 Theoretical Reflections on Agile Development Methodologies
 Commun ACM V50n3(Mar 2007)pp79-83       
 =SURVEY Philosophies   AGILE
 Makes the case that agile mthods fit well with recent developments in architectural, cybernetic, and management thinking.
.Close

OlaguEtAl07
.Open OlaguEtAl07
 Hector M Olague & Letha H Etzkorn & Sampson Gholston & Stephen Quattlebaum 
 Empirical validation of three software metrics suites to predict fault-proneness of Object-Oriented Classes developed using highly iterative or Agile Software Development Processes
 IEEE Trans Software Engineering V33n6(Jun 2007)pp402-419 
 =EMPIRICAL OPEN-SOURCE AGILE BUGS METRICS CK Chidamber-Kemerer QMOOD MOOD Rhino Javascript   
 Showed that bad CK scores are associated with modules that need fixing.
 Showed a slight tendency for metrics to be less useful in older projects.
.Close

Orr04
.Open Orr04
 Ken Orr
 Agile Requirements: Opportunity or Oxymoron
 IEEE Software Magazine V21n3(May/Jun 2004)pp71-73
 =POLEMIC AGILE REQUIREMENTS PURPOSES 
 States that systems analysis has been underplayed recently but is still important.
 Distinguishes primary outputs from "constraints".  Ignores non-functional requirements.
 Praises prototypes as a way to involve user. 
 Suggests that other engineering fields have developed tools that take rigorous requirements directly and cheaply to product.
 (dick)|- Primary purpose: that purpose that if not met makes all other purposes valueless.  For example: producing payroll payments is primary and producing W2s is secondary.
.Close

PalmerFelsing02
.Open PalmerFelsing02
 Stephen Palmer & John M Felsing
 A Practical Guide to Feature-Driven development
 Prentice Hall 2002
 =HANDBOOK METHOD AGILE USER PURPOSE DOMAIN MODEL FDD
 process: do(overall_model; features_list; plan_by_feature; design_by_feature; build_by_feature).
 class ownership of code, chief programmer, domain expert, ...
 feature::= `<action> the <result> of a <object>`.
.Close

Patton02
.Open Patton02
 Jeff Patton
 Hitting the target: adding interaction design to agile software design
 OOPSLA 2002 (Nov 2002)pp1-ff $CR 0406-0747
 =UNREAD EXPERIENCE AGILE USER
.Close

PiperPiper02
.Open PiperPiper02
 Ian C Piper & Angela M E Piper
 Agile Techniques from Arthritic Sources, or Teaching a New Dog Old Tricks
 
.See [SCI2002]
(Jul 2002)
 =EXPERIENCE QUALITY DRIVEN NET/WWW PERFORMANCE DATA PROCESS TEAM REQUIREMENTS IKIWISI
 Working solution to providing online advertising developed by rejecting 
certain axiomatic techniques: relational data -> bitmaps, system libraries
reinvented, no place to go for detailed requirements: IKIWISI
.Close

PolliceAugustineLoweMadhur03
.Open PolliceAugustineLoweMadhur03
 Gary Pollice & Liz Augustine & Chris Lowe & Jas Madhur
 Software development for Small teams: a RUP-Centric Approach
 Addison Wesley Longman Redwood City CA  2003 ISBN 00321199502 CR 0502-0169
 =UNREAD RUP PSP SMALL TEAM PROJECT PROCESS TOOLS AGILE
.Close

Poppendieck02
.Open Poppendieck02
 Mary Poppendieck
 Wicked Problems
 Software Development Magazine V10n5(May 2002)pp72-75
 =ESSAY MANAGEMENT CLIENT USER SYSTEM SITUATION ANALYSIS
 Traces definition of Wicked problem (vs tame problem) to 1973 article by Horst Rittel and Melvin Webber "Dilemmas in a General Theory of Planning", Policy sciences V4, Elsevier.
.See [DeGraceStahl90]
 Wicked problems are embedded in a dynamic and conflict ridden situation that will reject all attempted solutions.  Hence death matches IKIWISI....
 Describes how to recognize wickedness.
  Warns against defining and solving problems.
  First tame the wickedness by discussion and debate.  Then use agile or 
adaptive  methods -- eg scrum 
.See [RisingJanoff00]
-- to rapidly learn as you solve.
.Close

Rajlich06
.Open Rajlich06
 Vaclav Rajlich 
 Changing the paradigm of software engineering
 Commun ACM V49n8(Aug 2006)pp67-70 
 =SURVEY AGILE ITERATIVE EVOLUTION REFACTORING incremental change
 Ideas are from practitioners. Need research on the new ideas.
 (dick)|- I think that some forms of software development are not a kind of engineering -- low risk, exploring unknown territory, small scale changes,...
.Close

RameshCaoMohanXu06
.Open RameshCaoMohanXu06
 Balasubramamaniam Ramesh & Lan Cao & Kannan Mohan & Peng Xu 
 Can Distributed software development be agile?
 Commun ACM V49n10(Oct 2006)pp41-46   
 =CASE STUDIES 3 DISTRIBUTED AGILE PROCESS ORGANIZATION REALITY 
 Describes 5 challenges( e.g. people vs process) and 5 practices.
 Improve communication by: overlapping work hours,formal cahnnels for informal communication,...
 Facilitate knowledge sharing: repository, focus on well understood first, short cycles but not time-boxed.
 Trust but verify
 Continuously adjust process. Iterations to finalize requirements and designs, document requirements at different levels of formallity.
 Build trust: visits, culture,...
 Appoint a point of con tact for each location.
.Close

Read03
.Open Read03
 Daniel Read
 Software Design and Programmers
 developer.*  March 20, 2003
.See http://www.developerdotstar.com/mag/articles/read_designprog.html
 =SURVEY CODING vs DESIGN XP 
 Notes that some see programmers as coders -- no design involved.
 Others argue that code always includes design decisions.
 Notes that agile methodists tend to think in terms of the design evolving
or emerging from the code+test+refactor+test cycle.
 Also see
.See [WhittakerAtkin02]
that argues that software engineering texts do not mention code!
 Compare
.See [Holmes09]
.Close

Reifer02
.Open Reifer02
 Donald J Reifer
 How Good are Agile Methods
 IEEE Software Magazine V19n4(Jul/Aug 2002)pp16-18
 =POLL XP AGILE METHODS
 32 organizations mostly at CMM level >= 2, 28 firms, 14 using agile methods because of poor record of success. Mostly small projects.
 Consensus that Agile includes many (client->spec->build->test) iterations.
 15-23% increase in productivity, 5-7% cost reduction, 25-50% less time to market, some have data showing no change in defects.
 Recommend: define agile, make business case, expect organizational change, provide support and training.
.Close

ReiferMaurerErdogmus03
.Open ReiferMaurerErdogmus03
 Donald J Reifer & Frank Maurer & Hakan Erdogmus
 Scaling Agile Methods 
 IEEE Software Magazine V20n4(Jul/Aug 2003)pp12-14
 =REPORT AGILE ONE-SIZE
 How can agile methods be used on large projects.
 7 significant and unresolved issues
.List
 Projects that have to mix trad and agile processes.
 What to do away from a one-site 20 person project.
 New practices?
 Legacy code and COTS software is not test-first!
 Handling product lines across enterprises.
 Dispersed teams.
 Customers writing acceptance tests is vital, but not realistic in large organizations.
.Close.List
 7 conclusions
.List
 It's going to happen
 Keep releases short and time-boxed: 1 week better than 1 month.
 Daily meetings of team leaders.
 Some up front investment will help.
 Federate your customers! Know who speaks/writes on particular issues.
  Wrap COTS in demos/unit tests.
 Expect less.
.Close.List
.Close

RigbyEtAl12
.Open RigbyEtAl12
 Peter C Rigby & Brendan Cleary & Frederic Painchard & Margaret-Anne Storey & Daniel M German
 Contemporary Peer Review in Action: Lessons from Open Source Development
 IEEE Software Magazine V29n6(Nov/Dec 2012)pp56-61
 =EXPERIENCE SQA F/OSS OPEN SOURCE PEER REVIEW INSPECTIONS TOOLS PROCESSES Fagan 
 Traditional reviews are dreaded by both authors and reviewers vs the integrated code review in Open Source.  Why?
 Aynchronous reviews: You don't need a meeting.
 Frequent Reviews: The earlier the better. And a close to continuous as possible.
 Incremental Reviews: Review many small independent changes.
 Invested and experienced reviewers: Those who understand the context of the change.
 Empower experienced reviewers: Let experts choose changes but assign the unchosen changes.
 Lightweight tools: Tracebillity and integrated. Email. diff. inline discussion. hide and show context. version control. centralise code and discussion. dashboard vies. metrics.
 Nonintrusive metrics.
 Easier to implement in an agile environment.
 OSS allows reviews to solve problems.
.Close

RobertsonRobertson05
.Open RobertsonRobertson05
 Suzanne Robertson & James Robertson
 Requirements-led project management: discovering David's Slingshot
 Addison-Wesley 2004 ISBN 0321180623 $CR 0512-1289
 =UNREAD =HOWTO MANAGE INCREMENTAL REQUIREMENTS AGILE PROTOTYPES STORIES SIMULATION INVENTION
.Close

RosenbergStephensCollins-Cope05
.Open RosenbergStephensCollins-Cope05
 Doug Rosenberg & Matt Stephens & Mark Collins-Cope
 Agile development with ICONIX process
 Apress  2005 ISBN 1-59059-464-9 QA76.76.D47R666
 =DEMO AGILE  Object-Oriented Prefactor MODEL ROBUSTNESS UML ArcGIS
 Demonstrates using robustness models to disambiguate use cases and then design code.
 Prefactor ::= `Use models to design code that needs less refactoring`.
 Includes demos of ICONIX used with Test-driven development(TDD) and Cooper's personas.
 Also see a series of articles
.See RosenbergScott00
.See RosenbergScott01
.See RosenbergScott01b
.See RosenbergScott01c
.See RosenbergScott01d
in Software Dev. Mag.
.Close

Ruping03
.Open Ruping03
 Andreas Ruping
 Agile Documentation: A Pattern guide to producing lightweight documents for software projects
 John Wile & Sons NY NY 2003 ISBN 0470856173 $CR 0610-0996
 =UNREAD HOWTO DOCUMENT AGILE LIGHTWEIGHT PATTERNS
.Close

SchatzAbdelshafi05
.Open SchatzAbdelshafi05
 Bob Schatz & Ibrahim Abdelshafi 
 Primavera Gets Agile: A successful transition to agile Development
 IEEE Software Magazine V22n3(May/Jun 2005)pp36-42 
 =EXPERIENCE Scrum AGILE PROCESS =ADVERT TOOL
 Consequence: higher morale, customer reported defect/KLOC drops 30%, able to deliver one release 4 months early.
 Need for executive sponsor and external coach.
 Focus on developing teamwork.
 40.hour week.
 Learn to negotiate and set expectations.
 Needed a process that takes accusal suggestion by a product owner into a new requirement.
 Then added test-driven development and re-emphasized code quality. Defect rate per item dropped 75%!
.Close

Schorer77
.Open Schorer77
 Peter Schorer
 The Open Channel 
 IEEE Computer magazine V10n8(Aug 1977)pp70-71
.See doi:10.1109/C-M.1977.217827
 =EXPERIENCE ADVOCATE AGILE PROCESS USER ITERATIVE EVOLUTIONARY
 Early description of an agile process. 
 A Question to ask in interaction design: What other information does a user need to know to use the new system?
.Close

Schuh05
.Open Schuh05
 Peter Schuh
 Integrating agile development in the real world
 Charles river media 2005 ISBN1-58450-364-5 QA76.76
 =HOWTO agile
.Close

Schwaber00
.Open Schwaber00
 Ken Schwaber
 Against a Sea of Troubles: Scrum Software Development
 Cutter  IT Journal V13n11(Nov 2000)pp34-39
 =EXPERIENCE Scrum AGILE PROCESS
 `rugger`
 the perfect storm.
 p35. "commonsense, simple practices, and paying attention yield tremendous benefits."
 scrum_meeting::="a daily 15.min meeting for sharing status and obstacles for management to remove".
 scrum_team ::="cross functional 8..15 people focussed on building a product".
 scrum_sprint::="an iteration, about 30 calendar days, adding demonstrable functionallity".
 scrum_sprint is followed by a sprint review by developers and stake holders 
leading to a new sprint.
A sprint review is not a scrum_meeting, some take all day
 Sprints allow progress through chaotic situations.
 Track the backlog of unfinished functionality.
 Remove cubicals and replace by team rooms.
.Close

Selic09
.Open Selic09
 Bran Selic
 Agile documentation anyone?
 IEEE Software Magazine V26n6(Nov/Dec 2009)pp11-12
 =ESSAY DOCUMENTATION vs CODE ARCHITECTURE 
 Documentation has no value to the producer but can be valuable to others. 
 Code does not provide  Rationales and Architectual specifications.  
 Documentation must be closer to the user's domain than the code is.  
.Close

Shao10
.Open Shao10
 Zhong Shao 
 Certified Software
  Commun ACM V53n12(Dec 2010)pp56-66  
.See http://doi.acm.org/10.1145/1859204.1859226
 =IDEAS DEPENDABLE CORRECT PROOF CHECKER ASSEMBLER MACHINE CODE TOOLS EXAMPLES Coq METALOGIC FUNCTIONAL NONSEQUENTIAL 
 Minimize the components that can damage the dependability of the system. 
 Both proofs and specifications can be represented by executable programs. Example using CoQ
(Wikipedia)|- Coq implements a dependently typed functional programming language...
.See en.wikipedia.org/wiki/Coq
 "huge cost in constructing ... specifications and proofs"
 Dynamic validation - add a check after an unproved step and use a proved component if the check fails. 
 "time to market is likely terrible"
 PCC - proof-carrying code -  give executable code with a proof of safety to a host that checks the proof. 
 Proof checking is automated and about as difficult as type checking. 
 FPCC - Foundational PCC.
 CAP - certified assembly programming - using a mechanisable Metalogic. 
 Modular reasoning. Separation logics. CSL - concurrent separation logic. 
 Domain specific logics. 
 There exist certified garbage collectors, thread libraries, compilers, and certifying compilers, 
etc.
 (dick)|-How to handle changing requirements and specifications?  Can proofs be agile?
.Close

ShawM09
.Open ShawM09
 Mary Shaw (CMU)
 Continuing prospects for an Engineering Discipline of Software
 IEEE Software magazine V26n6(Nov/Dec 2009)pp64-67
 =ESSAY ENGINEERING SOFTWARE
 Review of
.See [ShawM90]
"Prospects for an Engineering Discipline of software"
 History of programming practices by decade originally 1960-1990 now extended to 2010.
 Three new trends: abstract architecture (1990+-5), Democratization on the Internet (2000+-5),
Vanishing system boundaries.
 Notes conflict between high-ceremony (CMM) vs agile and open-source processes.
 Production and Craft ~~> Commercial, Commercial and Science ~~> Engineering.
 Need for documented for routine ways to solve precedented problems.
Being satisfied by open documents on the web.
 More specialisms are emerging.
.Close

Shore04
.Open Shore04
 Jim Shore
 Continuous Design
 IEEE Software Magazine V21n1(Jan/Feb 2004)pp20-22
 =ANECDOTE AGILE CODE EVOLUTIONARY EMERGENT DESIGN
 Continuously take advantage of opportunities to improve code.
 Feature by feature: develop, test, refactor -> design.
 Three hard (cross cutting) problems: security, transaction processing, Internationalization.
 Good code makes it easier to distribute a crosscutting concern.
 Criteria:=
.Set
 DRY: Don't Repeat Yourself.
 Explicit code: says what it is for with few if any comments.
 Simple but not simplistic.
 Specific solutions are better than generic ones.
 Cohesion.
 Decoupling.
 Isolate third party code behind a common interface.
 YAGNI: don't code for future needs -- yet.
 No hooks: Unless needed now, avoid interfaces, factory methods, even handling and things to extensibility.
.Close.Set
  Security: pass around status objects and check them near the system boundaries.
 Transactions: easy because there was a Connection object that executed code black sent from other objects.  A DRYer design.
 Internationalization: Input and out put was already (DRY) centralized.  Better because a generic HTML framework was not in the way.
 .Net can force duplicated code. duplication leads to tedious work.
 Fixing a misconceived preconception can be more expensive than ding Just In Time.
  One size does not fit all: continuous design needs automated tests, team ownership of code, and commitment.
.Close

Skowronski04
.Open Skowronski04
 Victor Skowronski
 Do Agile Methods Marginalize Problem Solvers?
 IEEE Computer Magazine  V37n10(Oct 2004)pp120+118-119
 =ESSAY PROBLEM SOLVING vs AGILE
 Agile environment may block the preparation; incubation; illumination;verification cycle.
 No time to incubate when producing code?
 Problem solvers tend to be thing-oriented and without people-skills.
 Perhaps it would be best to note use agile methods when their are several unsolved problems in a project!
 (dick)|- Note: no data presented.  Not even anecdotal. Should stir up some discussion!
.Close

SmithMillerHuangTran09
.Open SmithMillerHuangTran09
 Michael Smith & James Miller & Lily Huang & Albert Tran
 A More Agile Approach to Embedded System Development
 IEEE Software Magazine V26n3(May/Jun 2009)p50-57
 =CASESTUDIES 4 XP TDD TESTING Embedded-Unit XPI E-Race
 Stages:= Vision; Prototyping; initial_production; full_production.
 Run a parallel system to monitor for race hazards.
.Close

Sommerville05
.Open Sommerville05
 Ian Sommerville 
 Integrated Requirements engineering: A Tutorial
 IEEE Software Magazine V22n1(Jan /Feb 2005)pp16-23 =Tutorial HISTORY Requirements engineering nonsequential agile Components COTS open-target
.Close

Spinellis11b
.Open Spinellis11b
 Diomedis Spinellis 
 Agility Drivers 
 IEEE Software Magazine V28n4(Jul/Aug 2011)pp96+95
 =ESSAY ONE SIZE SITUATION TECHNOLOGY AGILE PROCESS
 Notes that UK government has adopted "agile ICT delivery methods".
 Lists reasons that agile methods now work better:
.List
 Operating systems provide support for more functions. 
 Data base management systems. 
 Bigger libraries. With free add-on components. Open source code. 
Findable on the web. 
.Key Programming-by-googling.
 (dick)|-Post-modern mash ups. 
 Application inter-operability.
 Web service interfaces. 
 Standardized presentation layers like Ajax. 
 Programing and scripting languages. With lite documentation. 
 All supported by faster hardware. 
 Infrastructure: wikis. Version control, instant messaging, bug tracking.
 GUI IDEs that also support unit testing.
 Software developers are not math or physics majors any more. 
 Management culture has shifted from task oriented to people oriented.  
 Stakeholders expect more functionality  (Google) but at a just-good-enough level (Twitter).
.Close.List
.Close

StarkCrocker03
.Open StarkCrocker03
 John A Stark & Ron Crocker
 Trends in Software Process: The PSP and Agile Methods
 IEEE Software Magazine V20n3(May/Jun 2003)pp89-91
 =EXPERIENCE PSP AGILE PROCESS
 Both PSP and Agile methods worked (on different projects).
 One case: 2 projects customized PSP and where "the most effective projects" out of 16 on record.
 The other case: agility overcame risk tired to developing hardware.  Used Strata: cross cutting concerns that effected many subsystems/teams.  Strata developed independently and integrated... across subsystems.
.Close

Stepanek05
.Open Stepanek05
  G. Stepanek
 Software project secrets: Why Software Projects Fail
 APress, Berkeley, CA, 2005.  $CR 0702-0150
 =ADVERT AGILE EVOLUTION MANAGEMENT COSTS XP RUP PMBOK
 Continuous development, SWAT, Feature trade off, Triage,  Subteam encapsulation, scoping study
.Close

StephensRosenberg03
.Open StephensRosenberg03
 Matt Stephens & Doug Rosenberg
 Extreme Programming Refactored: The case against XP
 Academic Press 2003? ISBN: 1590590961 
 =UNREAD =POLEMIC XP AGILE vs FRAGILE
.Close

Taft10
.Open Taft10
 Darryl K Taft
 Agile Development Hitting the Mainstream, Report says
 eWeek (01/22/10)
.See http://www.eweek.com/c/a/Application-Development/Report-Agile-Development-Hitting-the-Mainstream-539452/
 =ARTICLE AGILE 
.Close

TeasleyCoviKrishnanOlson02
.Open TeasleyCoviKrishnanOlson02
 Stephanie D Teasley & Lisa A Covi & M S Krishnan & Judith S Olson
 Rapid Software development through Team Collocation
 IEEE Trans Software Engineering  V28n7(Jul  2002)pp671-683
 =EXPERIENCE TEAM PROCESS RSDC WAR-ROOM
 Using a "war room" for team and customer reps.
 RSDC:=6 war rooms.
 Customers, sponsors, and the team were very satisfied.
 Product was produced quicker than normal as well.
 Note. cf claims of agile manifesto.
 problems  with loss of flow caused by overhearing what others are saying.
 9 kinds of work: discussion with customer, politics, white-board problem solving, status review, team building, training, parallel sessions, solo work, private conversation.
 Problem - sprint leads to burn out.
.Close

Thomas05
.Open Thomas05
 Dave Thomas 
 Agile Programming: Design to accommodate change
 IEEE Software Magazine V22n3(May/Jun 2005)pp14-16 
 =ADVERT TABULAR decision tables states FSM/STD Spreadsheets 
 Convert changing code into data + table and let the users supply the data. 
.Close

ThomasHunt04
.Open ThomasHunt04
 Dave Thomas & Andy Hunt
 Nurturing Requirements
 IEEE Software Magazine V21n2(Mar/Apr 2004)pp13-15
 =ANALOGY REQUIREMENTS BUILDING CONSTRUCTION AGILE
 Distinguishes needs from wants.  Needs are comparatively stable and easy to elicit.  Wants are unstable and hard to elicit.
 In building you can walk through the unfinished building and negotiate changes. Requirements are not engineered but nurtured.
.Close

Turner11
.Open Turner11
 James Turner
 Process kills developer passion
 Radar OReilly (May 20 2011)
.See http://radar.oreilly.com/2011/05/process-kills-developer-passion.html
 =BLOG =HARMFUL PROCESS PEOPLE AGILE SCRUM
 Quotation
.Box
The underlying feedback loop making this progressively worse is that 
passionate programmers write great code, but process kills passion. 
Disaffected programmers write poor code, and poor code makes management add
more process in an attempt to "make" their programmers write good code. 
That just makes morale worse, and so on.
.Close.Box
.Close

WagstromHerbsleb06
.Open WagstromHerbsleb06
 Patrick Wagstrom & James Herbsleb 
 Depency forecasting in the distributed agile organisation
 Commun ACM V49n10(Oct 2006)pp-   
 =EXPERIENCE TOOL SOURCE DEPENDENCY  
 People who have recently worked on the same artifact need to communicate.
A tool can generate this information from a version control system.
 Similarly two files changed because of the same modification request are linked together. Probably means a depency. 
.Close

Walker12
.Open Walker12
 Joseph Walker
 Computer Programmers Learn Tough Lesson in Sharing
 WSJ (Aug 26 2012)
.See http://online.wsj.com/article/SB10000872396390443855804577599993053055030.html?mod=WSJ_Tech_TECHEDITORSPICKS_1
 =ARTICLE PAIR PROGRAMMING QUALITY AGILE FACEBOOK
 "Workplace 'Pairing' Brings Tech Couples Close Together; 'Just Grunt and Point'"
  Discussed at
.See http://developers.slashdot.org/story/12/08/28/1413207/the-programmers-go-coding-two-by-two-hurrah
(SlashDot).
.Close

Williams03
.Open Williams03
 Laurie Williams 
 The XP Programmer: The Few-Minutes Programmer
 IEEE Software Magazine V20n3(May/Jun 2003)pp16-20
 =EXPERIENCES XP iterative incremental agile pair-programming
 Describes XP practices.
 Compares XP to "The One-Minute Manager": rapid consistent simple feedback -- from requirement  to test to code to client very rapidly.
 Save time on big early phases by keeping them small and use the saved time to incrementally grow to what the user wants, even as the user learns what they need and moves the target...
  Anecdotes claim that growing a big working system one story at a time costs no more than trying to get the whole thing right first.  Research in progress.
.Close

Williams12
.Open Williams12
 Laurie Williams
 What agile teams think of agile principles
 Commun ACM V55n4(Apr 2012)71-76
.See http://doi.acm.org/10.1145/2133806.2133823
 =POLL AGILE PRACTIONERS 
 Teams agree with the agile manifesto
.See http://agilemanifesto.org/
and its principles
.See http://agilemanifesto.org/principles.html
.Close

WilliamsCockburn03
.Open WilliamsCockburn03
 Laurie Williams  & Alistair Cockburn (eds)
 Agile software development: It's about feedback and change
 IEEE Computer Magazine V36n6(Jun 2003)pp39-43
+  correspondence V36n8(Aug 2003)pp5-6 from Paul Jorgensen
 =HISTORY AGILE METHODS 1990-2003 DSDM XP Scrum Crystal ASD FDD CMM
 Introduces special edition V36n6(Jun 2003)pp39-85
 claims that engineers distinguish defined from empirical processes.
  A `defined process` can run to completion and produce predicted results automatically.
  Other processes need  short "inspect-adapt" feedback cycles.
  Jorgensen claims that some non-agile projects have been susccessful but doesn't quote any.  
.Close

ZhangPatel11
.Open ZhangPatel11
 Yuefeng Zhang & Shailesh Patel 
 Agile model-driven Development in practice
 IEEE Software Magazine V27n6(Mar/Apr 2011)pp84-91
 =EXPERIENCE Motorola AGILE MDD SIFT SLAP SCRUM ITERATIONS MODELS INCEMENTAL FUNCTIONS SPRINTS UML ASN iSL CODE GENERATION COMPONENTS DAILY PLAN 
 Correlates Model driven practices with agile practices.  Thus: pair modeling rather than pair programming.  Thus continuous early testing of models with tools and simulators.
 Tools generate code from models.
 The architecture, design, and code all iterate.
 Low level design starts with sequence diagrams with no data and when tested the data is added (and verified).
 1 iteration = 3 sprints.
 Monitor `sprint velocity` to detect process problem and plan corrections.
 Must automate as many steps in process as possible.
 Stream line and integrate systems engineering, design, and coding.
.Close

Search for bibliographic items containing a matching string.


(Search uses POSIX regular expressions and ignores case)

To see the complete bibliography (1Mb+) select:[Bibliography]