1. Jean-Jacques Gras
2. End-to-end Defect Modelling
3. IEEE Software Magazine V21n5(Sep /Oct 2004)pp98-100
4. =EXPERIENCE MOTOROLA DEFECTS SQA BN BAYES NETWORKS
5. Evidence for usefulness Bayesian Networks [FentonKrauseNeil02] [FentonNeil99] in predicting defects, and for adapting model to actual defect rates. Also BNs useful for eliciting, comparing and combining causal models

1. Andy Hunt & Dave Thomas
2. Imaginate
3. IEEE Software Magazine V21n5(Sep /Oct 2004)pp96-97
4. =ANECDOTE USERS PRAGMATIC RAPID COBOL AGILE
5. 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.
6. imaginate::="to instantiate into reality by pure will of imagination".

1. Suzanne Robertson
2. Requirement sand the Business Case
3. IEEE Software Magazine V21n5(Sep /Oct 2004)pp93-95
4. =ESSAY BUSINESS REQUIREMENTS SCOPE GOALS PURPOSE STAKEHOLDERS
5. SGS::model=cycle (scope -> stakeholders -> goals ->).
6. Scope = scope of product >< scope of investigation.
7. Goals lead to the basis for making choices about and in the project.
8. Stakeholders are the sources of requirements.
9. Scope helps organize and trace business requirements.
10. Notes

1. Neil Maiden & Alexis Gizikis & Suzanne Robertson
2. Provoking Creativity: Imagine what your Requirements Could Be Like
3. IEEE Software Magazine V21n5(Sep /Oct 2004)pp68-75
4. =EXPERIENCE REQUIREMENTS WORKSHOP CREATIVITY CORA RESCUE Pre-USE CASE
5. Describes theoretical basis for creative thinking: Diverge; Converge. Prepare, incubate, illumination, verification. Cf. CORT TEC Target-Expand-Contract
6. RESCUE::="Requirements Engineering with Scenarios for User-centered Engineering".
7. CORA::="COnflict Resolution Assistant", for air-traffic Control. Cf. TCAS projects.
8. Used other domains and analogies to explore requirements. Analogy via a common abstraction.
9. Combine random stimuli(eg toy frog) and combinations of requirements.
10. Transform problems by relaxing constraints.
11. Helps to understand the difficulty of creativity.
12. Encourage playfulness.
13. Groups and plenary sessions. Ideas on cards.
14. Analogies need a step-by-step guidance.
15. It takes time to incubate analogical ideas,
16. Structure workshops about ideas rather than creative processes.
17. Record the rationale behind ideas.
18. Time to let off steam...
19. Plan plan and then plan alternatives.
20. Need a champion for workshops.
21. See Gottesdiener, DeBono, Wickelgreen, ...

1. Amrit Tiwana
2. Beyond the black box: knowledge overlaps in software Outsourcing
3. IEEE Software Magazine V21n5(Sep /Oct 2004)pp51-58
4. =POLL 209 GLOBAL PROJECTS COMMUNICATION vs NOVELTY PQRST
5. Split analysis & design from (outsourced) implementation by a requirements document.
6. Classify projects by concept & process novelty.
7. If both high, need communication between teams to succeed.
8. If both low, no need to communicate to succeed.
9. If just the concept is novel, then implementors must understand the business domain.
10. If just the process is novel, then analysts must understand implementation.

Keuffel04

1. Warren Keuffel
2. Spinning the Semantic Web
3. Software Development Magazine, Web Services Newsletter (Nov 2004)
4. =Article Semantics Web/net ontology OWL RDF XML
5. Where to find meaning?
   
   1. Experts. Ontology Working group
   2. Users. Emergent Semantics. Sony Paris. Steffen Staab.
   3. Language. Computational semiotics. Alexander Maedche
   
   

AmblerS04a

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

BrowneMenon04

1. Glen J Browne & Nirup M Menon
2. Network Effects & social dilemmas in Technology Industries
3. IEEE Software Magazine V21n5(Sep /Oct 2004)pp44-50
4. =Theory Markets Economics

MiddletonLeeIrani04

1. Peter Middleton & Ho Woo Lee & Shahruck A Irani
2. Why culling Software Colleagues is popular
3. IEEE Software Magazine V21n5(Sep /Oct 2004)pp28-32
4. =Simulation Process People
5. erratic performance has an intuitively bad effect on downstream work.
6. Many small consistently timed work products improved whole stream.
   
7. (dick) |- elementary queuing theory!

Shore04a

1. Jim Shore
2. Fail Fast
3. IEEE Software Magazine V21n5(Sep /Oct 2004)pp21-25
4. =DEMO TECHNICAL DEBUGGING
5. Write code to detect bad data & fail with a helpful exception.
6. Many comments should be assertions!

Harrison04

1. Warren Harrison
2. Propaganda and software development
3. IEEE Software Magazine V21n5(Sep /Oct 2004)pp5-7
4. =ESSAY PEOPLE CHANGE MOTIVATION
5. 3 Tricks. Bandwagon. Link old to enemy. Simplified ideas in unqualified positive statements.

SamoladasEtAl04

1. Ioannis Samoladas & Ioannis Stamelos & Lefteris Angelis & Apostolos Oikonomou
2. Open source software development should strive for even greater maintainability
3. Commun ACM V47n10(Oct 2004)pp83-87
4. =analysis open source technical qualities maintainability
5. Maintainability similar to closed source, & decaying in a similar way.

Armour04a

1. Phillip G Armour
2. Not-Defect: the Mature Discipline of Testing
3. Commun ACM V47n10(Oct 2004)pp15-18
4. =ESSAY TESTING IGNORANCE
5. Testing is about discovering what we don't know.