[Skip Navigation] [Text Version] [Remove Frame] [Home] blog Sat Jun 28 09:41:59 PDT 2008
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).

Contents

    RJBottings Web Log

      2008-06-28 Sat Jun 28 09:06 Expensive user mistakes

       Who should pay if the user mistypes a number and the interface does not do "Sanity checking" that would have found the error?

      OlsenK08

      1. Kai A Olsen
      2. The $100,000 Keying error
      3. IEEE Computer Magazine V41n4(Apr 2008)pp108+106-107 + Correspondence V41n6(Jun 2008)p7
      4. =EXPERIMENT RISK USER INPUT ERROR Fossbakk
      5. System accepted an extra digit in an account number and sent money to wrong account.
      6. In experimental web-based simulation with "confirm" 124/1,778 transactions had errors.
      7. 29% of wrong number had extra digits in a sequence of repeated digits. Modulo 11 would find all but 3.
      8. Always spot and highlight too many over-long input -- (Sanity check)
      9. Confirmation does not catch common errors.
      10. Need other checks of all user input. Example: modulo 11 CRC.
      11. (Alan Quirt)|-typed comma for period and multiplied ayment by 100 times.
      12. (dick)|-give a picking list rather than expecting user to input digits.

      2008-06-27 Fri Jun 27 13:06 Positive demonstrations

      The literature of software development is full of papers and articles demonstrating a new idea, methid, technique or technology ad make large claims as to the value of the idea... It is only in the lat five or six years that solid experimental and exmpirical work has started to appear to back up these ideas.

      So here are two positive and plausible ideas... (1) use Aspects to implement Features in an iterative "feature-driven" process. (2) Use tools that combine text and diagrams in a seamless way.

      ApelLeachSaake08

      1. Sven Apel & Thomas Leach & Gunter Saake
      2. Aspectual Feature Modules
      3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp162-180
      4. =DEMO FEATURES FOP + ASPECTS AOP ITERATION PRODUCT LINES AFM
      5. AFM::="Aspectual Feature Module", combines iterative Feature Oriented Programming (FOP) with Aspect Oriented Programming(AOP).

      Dori08

      1. Dov Dori
      2. Words from Pictures for Dual-Channel Processing
      3. =DEMO TOOL GRAPHIC NATURAL LANGUAGE SYSTEM DESIGN MODELLING OPM OPD OPL OPCAT FSM
      4. Commun ACM V51n5(May 2008)#7pp47-52
      5. Claims that automatically linking diagrams to text makes process more intuitive. [MillerJ02]

      2008-06-26 Thu Jun 26 11:06 Standards for Small Enterprises

      More evidence (also see [OktabaEtAl07] ) that software develpment standards do not fit all companies equally.

      LaporteAlexandreRenault08

      1. Claude Y Laporte & Simon Alexandre & Alain Renault
      2. Developing International Standards for Very Small Enterprises
      3. IEEE Computer Magazine V41n3(Mar 2008)pp98-102
      4. =STANDARDS SMALL ENTERPRISES VSE ONESIZE ISO/IEC WG24
      5. Survey shows that small enterprises don't implement ISO standards because (1) no resources, (2) not required, & (3) standards are difficult bureucratic and don't fit small businesses.
        Working Group 24 is developing special standard profiles and packages for small enterprises.
      6. Some enterprises will try out the new standards -- real soon now.
      7. See [ index.html ] [ indexEN.php3 ]
      8. (dick)|-This might fix the problems recently reported with ISO/IEC standards [Glass07a]

      2008-06-25 Wed Jun 25 11:06 No Silver Bullets Again

      One or two papers make a gigantic impact on software engineering. Fred Brookes's 1987 article "No Silver Bullets" is one of these... ten years later people are still discussing it's thesis:
    1. Software development is in essence difficult.

      FraserManci08

      1. Steven Fraser & Dennis Manci
      2. No Silver Bullet: Software Engineering Reloaded
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp91-94
      4. =REPORT OOPSLA PANEL HISTORY STATUS Brookes Werewolf
      5. Fred Brookes + David Parnas + Linda Northrop + Aki Namioka + Dave Thomas + Ricardo Lopez + Martin Fowler.
      6. Guess who turned into a werewolf!
      7. Video on YouTube!
      8. All because of [Brooks87]
      9. Also see [Cox90a] [Harel92]

      2008-06-24 Tue Jun 24 14:06 Cones and acronyms

      A couple of essays on software development. Both refer to the idea of the cone of uncertainty. One has too many acronyms, but summarizes a lot of accumulated wisdom.

      Boehm08

      1. Barry Boehm
      2. Making a Difference in the Software Century
      3. IEEE Computer Magazine V41n3(Mar 2008)pp32-38
      4. =ESSAY IDEAS ACRONYMIC CATCHPHRASES ONESIZE OSUFA BITAR IKIWISI DAVAS SISOS TANIA
      5. Rapid change vs
      6. THWADI::="Thats How We've Always Done It".
      7. Uncertainty and Emergence. Cone of Uncertainty. [Armour08]
      8. BITAR::="Buy Information To Avoid Risk", Do extra things to reduce uncertainty.
      9. IKIWISI::="I'll know it when I see it". So Iterate.
      10. Dependability
      11. DAVAS::="Dependability As Value Assured to Stakeholders". Example of conflicting values in a well known failed project.
      12. Diversity.
      13. OSUFA::="One Size Fits All". Culture makes a difference in the adoption of process standards.
      14. SISOS::="Software Intensive Systems of Systems". OSUFA leads to failure
      15. Interdependence.
      16. TANIA::="There Are No Islands Anymore". No part of a system or of a process is isolated.
      17. Figure 5, p36: Activities >< Phases >-> Level_of_activity, CF RUP.
      18. SISOS need more time for Architecture and Risks.

      Armour08

      1. Phillip G Armour
      2. The inaccurate conception
      3. Commun ACM V51n3(Mar 2008)pp13-16
      4. =ESSAY ESTIMATION UNCERTAINTY LIFECYCLE
      5. Cone_of_uncertainty::=map[t:time]([1/f(t) .. f(t)]* actual ), for some dcreasing function f. "Describes how estimates get more accurate as a project proceeds". At that start of new product estimates are between [0.25 .. 4.0] times the actual value. Tightens as uncertainties are removed.
      6. Express estimates as a distribution mapping qualities to probability of success. S shaped curve.
      7. commitment is not an estimate.

      2008-06-23 Mon Jun 23 16:06 Experiments on TDD and Pair programming

      Two recent ideas in programming are (1) test driven development [Beck01] [Reifer02] [ErdogmasMorisioTorchiano05] and (2) Pair programming. I've documented quite a few papers and articles about these particular tricks. In test-driven design you write the tests before you write the code and in pair programming changes to code are made by one person while another person watches and makes comments. These two following experiments try to find out how these two techniques work.

      JanzenSaidian08

      1. David S Janzen & Hossein Saidian
      2. Does Test-Driven Development Really Improve Software Design Quality?
      3. IEEE Software Magazine V25n2(Mar/Apr 2008)pp77-84
      4. =EXPERIMENT TEST TDD CODE TECHNICAL QUALITITIES
      5. Evidence that TDD is associated with simpler and better tested modules.
      6. Two myths: TDD means (1) write all tests first or (2) automate all the testing. [JanzenSaiedian05]
      7. TDD::process=High-level design; TDD_design_and_code; test.
      8. TDD_design_and_code::= unit_test; code; refactor; O(TDD_design_and_code).

      LiuChanNosek08

      1. Kim Man Lui & Keith C C Chan & John Teofil Nosek
      2. The Effect of pairs in program design Tasks
      3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp197-211
      4. =EXPERIMENT PAIR PROGRAMMING vs LONE PROGRAMMING APTITUDE
      5. Used aptitude tests to act as a surogate for programming and eliminate language skill effects.
      6. Pairs substantially outperformed individuals in procedural/algorithmic design tasks.
      7. Pairs substantially outperformed individuals in deductive problem solving.
      8. Fewer errors. Faster time.

      2008-06-21 Sat Jun 21 08:06 VBScript Samples

      I've just been asked
        canyou providesample vb scripts

        From: Nsunil

      Nsunil didn't give me an EMail address to reply to, so I'll reply here.

      This site does have examples of code in many languages but nearly all of them have been written by students as part of their course work. See [ samples/ ] for these. When I have written up a language it is to help me learn the language. So far nobody has tackled any members of the VB (Visual Basic) family. [click here [socket symbol] VB if you can fill this hole]

      By the way -- this site does not host answers to home work questions.

      2008-06-20 Fri Jun 20 14:06 Toulmin Arguments Rebuttals

      I've been researching the work of Stephen Toulmin and its use in Reqirements Engineering. I've reworked [HaleyLaneyMoffettNuseibeh08] a little as a result and have added a new pair of directives (.But and .Close.But) to my MATHS language. Here is the background reading. See [ChesnevarMaguitmanLoui00] for a history.

      Toulmin58

      1. Stephen Edelston Toulmin
      2. The uses of argument.
      3. Cambridge [Eng.] University Press, 1958 BC177
      4. =THEORY INFORMAL LOGIC ARGUMENT RATIONALE
      5. Developed into text [ToulminRiekeJanik78]

      ToulminRiekeJanik78

      1. Stephen E Toulmin & Richard Rieke & Allan Janik
      2. An introduction to reasoning
      3. Macmillan, c1979. New York BC177 .T59
      4. =TEXT INFORMAL LOGIC ARGUMENT RATIONALE GRAPHIC
      5. Based on [Toulmin58]
      6. Toulmin_argument::=data "--->" O(qualifier) claim ", " warrant O(backing) O(rebuttal) . 
                 Backing
                   |
                Warrant
                   |
         Data -------------> (Qualifier) Claim
                                  |
                               Rebuttal
      7. Toulmin_argument::=following
        Net
        1. Claim::Utterance, conclusions
        2. Data::Utterance, facts
        3. Warrant::Utterance, general rule linking the data to the claim.
        4. Backing::Utterance, credentials when the warrant is not convincing enough.
        5. Rebuttal::Utterance, restrictions which apply to the claim.
        6. Qualifier::Phrase, possibly, likely, probably, certainly, presumably, necessarily.

        (End of Net)


        But
          [Loui08] [HaleyLaneyMoffettNuseibeh08]

        (Close But )

      Loui08

      1. Ronald P. Loui
      2. A Modest Proposal for Annotating the Dialectical State of a Dispute
      3. SCRIPTed V5n1(2008)#176 [ loui.asp ]
      4. =ESSAY REBUTS Toulmin diagrams KISS RATIONALE

        [ToulminRiekeJanik78]

      5. Just list the data for a conclusion underneath the conclusion with the rebuttals etc ?(hidden) beside them.
      6. Or use a simple tree diagram: children support parents and rebuttals have a heavy horizontal link to what they rebut.

      2008-06-18 Wed Jun 18 15:06 Design as Iteration

      Here is a collection of papers and articles on the topic of how to design software. First DenningYaholkovsky08 bewail the lack of tools that help people become a team that can solve a wicked problem. WirfsBrock08 suggests some steps to help design. Glass08b notes the impossibility of supporting a single designer's intuitive process with current technology. He notes that design is iterative... a common theme. HadarLeron08 show that object-oriented design is not obvious but has to be overlaid on top of intuitive ideas. HallRapanottiJackson08 propose POSE -- a new way to manage and document the design process. This is the first method that has explicit backtracking steps the replace previous designs by better ones. Also one which seems to be able to work with many and all notation. Finally Patton08a praise iterative design methods that test early and test often.

      DenningYaholkovsky08

      1. Peter J Denning & Peter Yaholkovsky
      2. Getting to "We"
      3. Commun ACM V51n4(Apr 2008)pp19-24
      4. =ESSAY TOOLS PEOPLE TEAM WICKED PROBLEMS SYNERGY DESIGN Charettes
      5. Collaboration is when people create synergistic solutions|strategies
      6. Notes that tools support communication, coordination and cooperation rather than collaboration.

      Wirfs-Brock08

      1. Rebecca J Wirfs-Brock
      2. Design Strategy
      3. =ESSAY DESIGN PROBLEMS TECHNIQUES TEAM
      4. IEEE Software Magazine V25n3(May/Jun 2008)pp14-15
      5. Design is hard -- you need to choose your battles. Focus on What??
      6. First share/note stories about hopes,wishes, fears, convictions, ... .
      7. Sort out certainties, unknowns, nagging concerns.
      8. In meeting all (write; read; note) stories.
      9. Find out stakeholder priorities and desired qualities -- it can drive design.
      10. Distinguishes: core design work | revealing design problems | the rest.
      11. Revealing problems tend to be wicked.
      12. Focus on the core first.
      13. Don't forget domain models.

      Glass08b

      1. Robert L Glass
      2. Software design and the Monkeys brain
      3. =ESSAY DESIGN ITERATION CREATION
      4. Commun ACM V51n6(Jun 2008)pp- 2008)pp21-22
      5. Research showed mental design process: understand problem; create solution; do(test; modify); tests OK.
      6. Tools & methods slow process down.
      7. Unless can record directly the designers brain!

      HadarLeron08

      1. Irit Hadar & Uri Leron
      2. How Intuitive is Object-Oriented Design
      3. =EXPERIMENT STUDENTS LEARNING OO DESIGN
      4. Commun ACM V51n5(May 2008)pp- 2008)#7pp41-46
      5. Distinguishes two different modes of thought: S1 and S2.
      6. S1: fast, automatic, effortless, unconcious, and inflexible.
      7. S2: slow, concious, effortful, but relatively flexible.
      8. S2 acts a s amonitor and critic of S1.
      9. Inheritance is backward(S1).
      10. Surface features (S1) lead to bad OODs.
      11. Confusing abstract and concrete classes (S1).
      12. Identifying coding with development (S1).
      13. It is hard to replace S1 with S2.

      HallRapanottiJackson08

      1. Jon G Hall & Lucia Rapanotti & Michael A Jackson
      2. Problem Oriented Software Engineering: Solving the Package Router Control Problem
      3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp226-241
      4. =DEMO POSE METHOD ENGINEERING DESIGN ANALYSIS ARGUMENTS RATIONALE ITERATION PROCESS
      5. POSE::="Problem Oriented Software Engineering", based on Jackson's Problem Frames [Jackson01] , using informal or formal satisfaction arguments that target stakeholders, refinement, iteration, backtracking, etc.,
      6. Models a problem+solution as a set of Domains+Solution+Requirements 
         	D[1],...D[2], S |- R
      7. A Gentzen Sequent!
      8. Domains have a name(N) and description(E) that mentions phenomena: controlled(c), observed(o), and unshared(p): 
         	D(p)[o]^c = N : E
      9. Solutions are a domain.
      10. Requirements have a name and description that constrains(c) certain phenomena and refers (r) to other phenomena: 
         	R[r]^c = N : E.
      11. Progress is made by transforming problems (like inference rules in SOS or Natural Deduction). Each transformation has NAME and an adequacy argument.
      12. Arguments have a Justification, Includes, Concerns, Phenomena, and Resulting Problems (if any).
      13. Sample of Problem Transformations
        1. CONTEXT INTERPRETATION Justify a new description of a domain.
        2. REQUIREMENT INTERPRETATION Justify an expanded requirement
        3. SOLUTION INTERPRETATION Justify the expansion of the solution. Example: nSep. Separation into independent parts. Example: applying the MVC pattern. Example: Using an analogic model.
        4. SEPARABLE PROBLEM Explain how one problem becomes a set of independent problems
        5. PROBLEM PROGRESSION Changes requirements
        6. SOLUTION EXPANSION Moves known components into environment and generates a set of problems to be solved.
        7. Backtracking. Justify the abandonment of a previous solution and replacement by a new one.

      14. Has been tested in a safety critical system -- avionics -- using Alloy.
      15. Development involves learning about the context of the problem as well as about the requirements and solutions.
      16. Justifications must satisfy the stakeholders. Different stakeholders will need different justifications.
      17. Development is an iterative activity. Concerns lead to backtracking.

      Patton08a

      1. Jeff Patton
      2. Getting Software RITE
      3. =ADVERT RAPID ITERATIVE TEST EVALUATION RITE vs FORMAL TESTING
      4. IEEE Software Magazine V25n3(May/Jun 2008)pp20-21
      5. RITE::="Rapid Iterative Testing and Evaluation".
      6. RITE_iteration::=do(test; fix).
      7. Problem: your shiny new software confuses your stakeholders.
      8. Solution: Acceptance testing.
      9. Defines formal testing.
      10. Compares to lite testing of paper low-tech prototypes initially.
      11. RITE -- pool of users, lots of iterations, electronic share prototypes.
      12. Not specs but prototypes.

      2008-06-17 Tue Jun 17 10:06 Mathematicians and Movies

      I guess it all starts with Archimedes running naked through the streets of Syracuse [ math.html ] , bearing in mind that the ancient Greek athletes were naked....

      But then you have "A Beautiful Mind" showing the peril of a mind that can see patterns anywhere... and then "Proof" where the daughter of a dead and insane mathematician may just be starting to show the same brilliance and possible instability. In both cases the movies are very well made and the acting most excellent. But do you really have to be crazy to do mathematics -- I hope not.

      But it is peculiar how you can suddenly see something that becomes in retrospect entirely obvious -- especially in a field that you know well.

      So last night at 3am I realized that my MATHS system may be capable of expressing Russell's Paradox.... and then at 6am that I'd already noted the danger of eXtreme BNF -- -- --(XBNF)
      defining sets that can not exist. Hence an update to [ papers/rjb08.xbnf.html ] a old seminar paper.

      By the way, but not unrelated, I just revized the wikipedia entry on Russell's "Axiom of Reducibility".

      2008-06-16 Mon Jun 16 16:06 Finding Defects in software

      One of the topics I researched and wrote up while with the British Civil Service (1968-82) was Software Quality Assurance -- how can youi be sure that a piece of software has zero defects, even though it is written by people who make mistakes. We had a half-a-dozen techniques including Desk Checking, Peer Review, Walkthroughs, and Fagan's Inspections.

      Fagan's technique [Fagan76] was one of the few software techniques that generated evidence of its effectiveness. Here are the key properties of Fagan Inspection:

      1. Can be carried out on any artifact.
      2. Looks for major defects that cause the software to misbehave and minor defects which lead to lower quality but no bug.
      3. Is organized by a moderator.
      4. Work is driven by check lists of things to look for.
      5. Inspectors first work alone and then have a meeting to review and collate what they have found.
      6. The producers of the artifact do not take an active part in the hunt for bugs.
      7. ...
      8. The moderator collects statistics on the defects found and tunes the check lists, the rate of inspection, etc. for find as many defects per unit time.

      Shull and Seaman have recorded how this evidence helped the technique be adopted in NASA.

      ShulSeaman08

      1. Forrest Shull & Caroline Seaman
      2. Inspecting the History of Inspections: an example of evidence-based technology diffusion
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp88-90
      4. =HISTORY INSPECTION NASA SQA TECHNICAL CODE QUALITY
      5. How evidence of effectiveness and adaption of method moved Fagan inspections from IBM to throughout NASA during the late 80's and early 90's.

      2008-06-14 Sat Jun 14 10:06 Catching up on some reading

      If I had had a proper course on logic then I would have learned of Ramsey's work on the foundations of mathematics when I needed it -- 40 years ago. As it happened, I've just finished studying the following which shines a brilliant light on a book ("Principia Mathematica") that has had a very powerful influence on my thinking. The line of thinking lead to MATHS. The good news is that Ramsey's work does not invalidate MATHS.

      RamseyFP60

      1. Frank Plumpton Ramsey (ed R B Braithwaite)
      2. Foundations of mathematics and other Logical Essays
      3. Littlefield Adams, Paterson NJ 1960
      4. =ESSAYS PHILOSOPHY LOGIC MATHEMATICS TYPES PROBABILITY
      5. Essays, papers, reviews, and notes dating from the 1920s.
        1. Published
          1. The Foundations of Mathematics 1925
          2. Mathematical Logic 1926
          3. On a Problem of Formal Logic 1928
          4. Note on the preceeding paper 1926
          5. Facts and Propositions 1927

        2. Unpublished
          1. Truth and probability 1926
          2. Further Considerations 1928
          3. Last Papers 1928

        3. Appendix: Critical Notice of L Wittgenstein's "Tractatus Logico-Philosophicus"

      6. PM::="Principia Mathematica", [WhiteheadRussell63].
      7. Dispenses with PM's pphilosophical axiom of reducibility by using Wittgenstein's Tractatus Logico-Philosophicus.

          PM gives a syntactic definition set of special predicative truth functions to avoid paradoxes and then has to assume that all sets (for example) of objects of a given type can be expressed using one of these functions.
          Ramsey uses a semantic definition from Wittgenstein that makes any truth function predicative.
      8. Argues for the need for a theory of types.
      9. Does not discard axioms of infinity and selection.
        1. PM's Axiom of infinity asserts the existence of an infinite domain, Needed to define infinite numbers. Because, in PM, numbers measure the size of sets of objects of a particular type. Indeed a number is a set of all sets with the same size of that type. So the largest number for a given type is = to the size of the type.
        2. PM's Axiom of selection is equivalent to the Axiom of Choice [ wikipedia ]

      2008-06-13 Fri Jun 13 15:06 Workload and workflow

      Understanding (=? documenting) the work needed for various tasks is a useful step in developing software. Here are two articles on the two uses of the information.

      SmithAJ07

      1. Alan J Smith
      2. Workloads (Creation and use)
      3. Commun ACM V50n11(Nov 2007)pp43-54
      4. =ESSAY PERFORMANCE QUALITIES BENCHMARK

      GilDeelmanEtAl07

      1. Yolanda Gil & Ewa Deelman & Marc Ellisman & Thomas Fahringer & Geoffrey Fox & Dennis Gannon & Carole Goble & Miron Livny & Luc Moreau & Jim Myers
      2. Examining the challenges of Scientific Workflows
      3. IEEE Computer Magazine V40n12(Dec 2007)pp24-32
      4. =REPORT CONFERENCE NSF DATA PROCESS DFD MODELS SCIENCE

      Does anybody know why the Innoculate update process downloads a complete new executable and runs at normal priority? Is it just one of the usual suspects for bad software:

    2. {stupudity, ignorance, malice, ...}.

      2008-06-12 Thu Jun 12 17:06 Fear and loathing of upgrades -- and bugs

       Below you will find [ 2008-05-30 Fri May 30 10:05 Fear and Loathing of Upgrades Part 2 ] [ 2008-05-27 Tue May 27 20:05 Fear and Loathing of Upgrades ] the previous episodes in the saga of upgrading my Palm Tungsten -- I may finally have got the handheld and its two laptops to agree on a collection of categories for Contacts. It only took a couple of weeks.

      Meanwhile here are some statistics about bugs: (1) bugs don't fit a Pareto distribution. (2) You can't tell if a change is clean or buggy by looking at its statistics. Perhaps Kim&Whitehead&Zhang should try the time of day when the change was made. The folk theorem is that work done after 4pm on Friday always needs fixing.

      Zhang08

      1. Hongyu Zhang
      2. On the Distribution of Software Faults
      3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp301-302
      4. =EXPERIMENT STATISTICS PROBABILITY FAULTS BUGS DEFECTS MODULES Eclipse For x:[0..], Pareto(x)::= 1-(γ/x)**β.
      5. Weibull(x)::=1 -exp(-(x/γ)**β).
      6. Weibull predicts % of faults in % of modules better than Pareto in Eclipse.

      KimWhiteheadZhang08

      1. Sunghun Kim & James Whitehead Jr & Yi Zhang
      2. Clasifying software changes: Clean or Buggy
      3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp181-196
      4. =STATISTICS OPEN SOURCE CHANGES SVM
      5. Has a definition of a buggy change -- a change that is later changed and described as a bug/fix etc.
      6. Analyses a dozen open source projects.
      7. Doesn't find a simple way to recognise a change that contains a bug vs a clean change.

      2008-06-11 Wed Jun 11 15:06 Map -- Sort -- Reduce

      DeanGhemawat08

      1. Jeffrey Dean & Sanjay Ghemawat
      2. MapReduce: Simplified Data Processing on Large Clusters
      3. Commun ACM V51n1(Jan 2008)pp107-113
      4. =EXPERIENCE FUNCTIONAL PROGRAMMING Google DATA C++ LIBRARY FP
      5. Very large numbers of problems have been programmed to run on large clusters. Each is written as two (2) functions:
      6. map: Key><Value -> List(Key>< Value),
      7. reduce: Key><List(Value) ->List( Value),
      8. System applies map to some data, sorts data by key and passes it to reduce.
      9. map ->sort -> reduce
      10. All the concurrency, distribution, fault tolerance etc. Is provided by the system not the programmer.
      11. Note: the idea uses functions in LISP and FP(Jim Bachus) and standard in MATHS. Similar techniques used in UNIX/Linux scripts.

      2008-06-10 Tue Jun 10 17:06 Language Design -- English XML BPEL DynAlloy

      I designed my first language before I was taught to program. It was a way of recording operations for a manual calculator. This must have been in the summer of 1963 or 1964. In my first year at college I learned my first programming language (something more primitive than FORTRAN I) and designed my second language as a way to encode flowcharts for input into a computer. Very primitive. Never implemented. The next attempt was a combination of logic and programming mostly done while commuting from Clapham to Uxbridge later in the 1960's. It was inspired by LISP -- but with fewer parentheses. In my graduate work I developed a language for drawing graphics in Algol 60 -- PICTALGOL. It was implemented as a library of procedures. It was used in a few projects in the early 1970's. Meanwhile I started work on ways to record mathematics and logic in a computer readable form. This lead to PINAPL ( PINAPL Is Not A Programming Language) in the 1980s and MATHS in the 1990s onward. I still working on this. I will say nothing of the shorthand I worked out for taking notes that I started in the 1970's and am still tinkering with to this day. No mention of the two dozen programming languages I've learned and used.

      So, I'm always interested in new languages and what people say about old ones. Robert Glass has recently noted the ambiguity of English grammar and phonetics -- how do you pronounce "Gough"? Spinellis gives a very brief style guide for using XML well. Louridas shows how a special XML document type can define a business process. Finally, Frias et al show that an extension of Alloy enables the faster analysis of specifications.

      Glass08

      1. Robert L Glass
      2. On the impurity of the English language
      3. IEEE Software Magazine V25n2(Mar/Apr 2008)pp96+95
      4. =ESSAY ENGLISH LANGUAGE PHONETICS AMBIGUITY

      Spinellis08

      1. Diomidis Spinellis
      2. Using and Abusing XML
      3. IEEE Software Magazine V25n2(Mar/Apr 2008)pp88-89
      4. =EXAMPLES XML VERBOSE LANGUAGES INTEROPERABLE SCHEMA STYLE
      5. Don't use XML without defining a DTD.
      6. Use standard schemas if possible.
      7. Design own schemas to be used & to express meanings. Eg. Use meaningful tags with attributes in tags!

      Louridas08

      1. Panagiotis Louridas
      2. Orchestrating web services with BPEL
      3. IEEE Software Magazine V25n2(Mar/Apr 2008)pp85-87
      4. =ADVERT BPEL XML PROCESS WEB/NET SERVICES
      5. BPEL::xml= "Business Process Execution Language"
      6. 36 line "Hello World".
      7. p87: Lists resources.
      8. process:=partner_links; variables; fault_handlers; sequence.
      9. First understand the business requirements.

      FriasEtAl08

      1. Marcello F Frias & Carlos G Lopez Pombo & Juan P Galeotti & Nazareno M Aguirre
      2. Efficient analysis of DynAlloy Specifications
      3. ACM TOSEM Trans Software Eng & Methodology V17n1(Dec 2007)#4pp1..34
      4. =DEMO SPEED DynAlloy vs Alloy SPECIFICATION MODEL CHECKING HOARE TRIPLES
      5. Instead of traces defines {pre}action{post}.
      6. Much faster than Alloy.

      2008-06-09 Mon Jun 9 12:06 Notes on Requirements

      There has been a spate of publications on the connections between technological solutions and business needs. I'll list the citations and notes below. But here is my personal list of things I know about Requirements:
      1. You shouldn't think of requirements as an artifact or as a phase. There are a process, a discipline, a work in progress from the start of a project thru to its obsolescence and replacement. [ CaoRamesh08 ] Requirements never go away, they mutate as technology and processes are changed.
      2. Get out of your office and out from behind the machine. Go to where the problems are. You can learn a lot by just looking. Plan interviews. Avoid rigid development processes [ Codefirst07 ]
      3. What the stakeholders require is not technology but what it can do for them. Your enterprise only needs technology to support its real business needs. Data and information is central to meeting enterprise needs. [ RagowskyLickerGefen08 ] [ Maiden08 ] [ DiesteJuristoShull08 ] [ WagnerPiccoli07 ]
      4. First provide the data, but also provide the desirable qualities: usability, safety, security, etc., to fit the enterprises needs. [ Boegh08 ] [ TondelJaatenMeland08 ] [ HaleyLaneyMoffettNuseibeh08 ] [ Patton08 ] Technology often has a bigger effect on qualities than on the information provided.
        You have to understand the real world situation before you propose solutions. Understanding has more value than artifacts and documents. [ DiesteJuristoShull08 ]
      5. Express user functional requirements as simple and specific stories [ Desilets08 ] [ Mugridge08 ] first. Identify the user. Identify what they need. What qualities?
      6. Executable artifacts (even bad ones) are more valuable than documents that can't be executed. [ WingM07 ] [ Rainsberger07a ] So tests are a valuable expression of requirements. [ CaoRamesh08 ] [ MartinMelnick08 ] [ Mugridge08 ]
      7. Can you describe, in detail, what is currently done and how your solution fits into this process? [ WagnerPiccoli07 ] Only connect -- design connections into the current systems information flows.
      8. There is no logical process that derives technical solutions fit what stakeholders say they need. You have to invent and create solutions and then show that the fit the enterprise requirements. [ Maiden08 ]
      9. You can use tools to connect documented requirements to code. [ MohanRamesh07 ] [ BurgeBrown07 ] [ Cleland-HuangEtAl07 ]
      10. Manuals don't introduce new solutions [ RagowskyLickerGefen08 ] -- you need to give training and support.
      11. Throwing a SRS for a new products over a wall for engineers to develop doesn't work well. [ SafayiniEtAl08 ] [ CaoRamesh08 ] [ WagnerPiccoli07 ]
      12. Iteration/Evolution often works well. Both the user's needs, the system requirements, can all the code all evolve together. [ CaoRamesh08 ] But beware the requirements creep that kills projects or makes them unprofitable.

      RagowskyLickerGefen08

      1. Arik Ragowsky & Paul S Licker & David Gefen
      2. Give me Information, Not technology
      3. Commun ACM V50n12(Jun 2008)23-25
      4. =POLL INTERVIEWS CIOs =HISTORY MIS IS IT DYSFUNCTIONAL REQUIREMENTS vs TECHNOLOGIES DATA
      5. Business users value information and information services.
      6. They perceive IT as providing technology not business value. Technology is not about fixing the projector in the conference room.
      7. Too much technology is bad. Vendors do not help by promising too much. Technical manuals do not help, either.
      8. Systems/Business analysts should focus on user and managers as partners. Find out what information services are needed and only then proceed to Research and Development (R&D) of technology and technical requirements.
      9. Avoid solving non-problems. Listen.
      10. Avoid technical Jargon. Talk business.

      Maiden08

      1. Neil Maiden
      2. User Requirements and System Requirements
      3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp60-
      4. = USER SYSTEM REQUIREMENTS
      5. Distinguish user requirements from system requirements.
      6. Need both, separately.
      7. A user requirement comes from a user and describes a new property of the domain or business process. Goals.
      8. A system requirement describes a desirable property of the new system. The system shall .... Use cases or other structured text.
      9. Implementing system requirements should lead to satisfying user requirements -- Satisfaction arguments.
      10. It is a design task to move from user to system requirements.

      SafayiniEtAl08

      1. Frank Safayini & P Robert Duimering & Kimberley Zheng & Natalia Derbentseva & Christopher Poile & Bing Ran
      2. Requirements Engineering in New Product Development
      3. Commun ACM V51n3(Mar 2008)pp77-82
      4. =CASESTUDY COMPANY INTERACTION COMMUNICATION REQUIREMENTS SAP
      5. Company divided by functions with outsourced software development. Requirement Engineers separated from Market Sponsors by a Feasibility Analyst.
      6. Requirement Engineers had helpful knowledge but had a weakness with coordination.
      7. Requirement Engineers found less help especially with coordination, knowledge, and communication.
      8. In terms of functions, REs were helped by the software developers. The project manager and feasibility analysts and operations were helped by the REs.
      9. Examples: when Market Sponsors change requirements halfway thru a project the REs see it as unhelpful,.... In reverse, MS finds RE jargon unhelpful.
      10. Article includes proposals. Notes that reorganization would be a good idea that would not fly.
      11. (dick)|-Sounds like the company Dilbert works for. The lists of unhelpful behaviors should be studied by practitioners. No reference to Yourdon's analysis of Market vs Engineering speech. No discussion of possible technologies.

      CaoRamesh08

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

      DiesteJuristoShull08

      1. Oscar Dieste & Natalie Juristo & Forrest Shull
      2. Understanding the customer: What do we know about Requirements Elicitation
      3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp11-13
      4. =SURVEY USER REQUIREMENTS ELICITATION
      5. Many techniques and results, see [ s2voe.html ]
      6. Summary:
      7. Plan interviews in advance! Plan a Structure.
      8. Include general question when new to a domain.
      9. Introspective techniques are less useful.
      10. Sorting techniques not as useful as interviews but sometimes quicker.

      Desilets08

      1. Alain Desilets
      2. Tell Me a Story
      3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp14-15
      4. =EXPERIENCE USER REQUIREMENTS STORIES
      5. Express user goals as simple, specific, and concrete stories about particular people getting valuable things.

      Boegh08

      1. Jorgen Boegh
      2. A New Standard for Quality Requirements
      3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp60-
      4. =STANDARD QUALITIES MANAGEMENT MODEL MEASUREMENT REQUIREMENTS EVALUATION ISO/IEC 25030 SQuaRE
      5. ISO 9126 Quality model{ {External, Internal}><{Functionality, Reliability, Usability, Maintainability, Portability}, Quality in Use {Effectiveness, Productivity, Safety, satisfaction }}
      6. Distinguish: computer system, mechanical part, Human process.
      7. Computer system: hardware, software, and data -- all with qualities.
      8. Stakeholder needs ->(definition)->Stakeholder requirements ->(Analysis)-> System Requirements.
      9. Many more details...

      MohanRamesh07

      1. Kannan Mohan & Balasubramaniam Ramesh
      2. Tracing variations in software families
      3. Commun ACM V50n12(Dec 2007)68-73
      4. =PROJECT KNOWLEDGE MANAGEMENT REQUIREMENTS DESIGNS PRODUCT LINES REUSE WHY
      5. Analysis & Design of system to help manage product lines for 2 companies.
      6. Do more than link requirements to designs .
      7. Figure 1. UML. Variable requirements link to variation points in designs. Variation points linked to variants, mechanisms, and justifications. Interactions + conflicts + dependencies + constraints...
      8. Provide integrated environment that can be used by whole organization: engineering, sales, marketing, etc.

      BurgeBrown07

      1. Janet E Burge & David C Brown
      2. Software Engineering Using RATionale
      3. Journal of Systems and Software V81n3(2008)pp 395-413
      4. =EXPERIMENT =DEMO TOOL REQUIREMENTS DESIGN RATIONALE IDE SEURAT Eclipse Java RATspeak inference
      5. Faster maintenance for nonexperts (only)
      6. Who were the subjects?
      7. What is cost of capturing the rationale?

      2008-06-06 Fri Jun 6 06:06 Four thousande plus items in Bibliography

      As I post my notes on my reading on software development I also place them in a searchable bibliography. This started 20 years ago. It now has 4521 items! You can search it by going to [ biba.php ] and inputting a word or phrase -- it will accept regular expressions as well. Or you can try [ lab.html ] for a slightly different search engine.

      The search generates a list of items showing the items unique tag and a set of keywords describing the content. The identifier is also a link that extracts the item. Every item is given a unique tag, key or identifier so you can easily link to it.

      At the end of the listing is a link to a search engine that gathers the texts and citations into a non-standard HTML bibliography on the topic.

      Please use these tools.

      2008-06-06 Fri Jun 6 06:06 Security and Requirements

      Two articles on security form IEEE Software Magazine. One on Java techniques and the other a literature survey of the methods.

      Lai08

      1. Charlie Lai
      2. Java Insecurity: Accounting for subtleties that can compromise code
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp13-19
      4. =DEMO TECHNICAL Java SECURITY
      5. Example of sompromisable singleton pattern.

      TondelJaatenMeland08

      1. Inger Anne Tondel & Martin Gilje Jaaten & Per Hakon Meland
      2. Security requirements for the rest of us: a Survey
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp20-27
      4. =SURVEY SECURITY REQUIREMENTS
      5. Table 1: SQUARE, Haley et al, Bostrom et al, CLASP, MICROSOFT, APvrille et al, Fernandez, van Wyk & McGraw, Peterson
      6. Tasks: definition, objectives, misuse/threats, assets, coding standards, categorize & Prioritze, Inspect & Validate, Process planning.

      More below.

      2008-06-05 Thu Jun 5 10:06 Security Requirements Engineering

      The following paper and article both describe processes for sorting out security requirements. Jeff Patton's article argues that explicit goals and metrics for them is helpful for selecting the correct features to implement next. The paper is much longer and more complex but worth study, if only to observe the subtle interplay between formal logic (proving that a system is secure) and informal arguments (challenging the assumptions that were made in the proof).

      HaleyLaneyMoffettNuseibeh08

      1. Charles B Haley & Robert Laney & Jonathon Moffett & Bashar Nuseibeh
      2. Security Requirements engineering: A Framework for Representation and Analysis
      3. IEEE Trans Software Engineering V34n1(Jan/Feb 2008)pp133-153
      4. =CASESTUDY SECURITY REQUIREMENTS METHOD
      5. Describes a complex process and set of languages that work from security goals, to assets that are to be protected (compare [Stoneburner06] ), to requirements, thence to arguments for a particular system design satisfying the requirements, and so to the assumptions that can be rebutted, and the mitigation of the rebuttals and so forth.
      6. Security requirements are non-functional requirements and are closely related to the context of the machine being designed.
      7. Must expose assumptions about the machine and its context.
      8. Arguments that the system satisfies the requirements lead to lists of assumptions that can be challenged (WHY?) and rebutted.
      9. Rebuttals lead to mitigators that change the context.
      10. Hence an iterative process designing a more secure system.
      11. Uses Jackson Problem Frames ( [Jackson95c] [Jackson01] ), Toulmin type arguments, Propositional logic, and a causal logic based on
        Event 1 shall cause Event2.
      12. Outer_argument::jargon=Formal logic showing the design satisfies the requirement and exposing assumptions
      13. Inner_argument::jargon=Explores assumptions in terms of rebuttals and mitigators.
      14. Process involves engineers and stakeholders in intense and fruitful discussion.
      15. (dick)|-Compare the [Lakatos76] model of the mathematical process. Also methods used to achieve safety.

      Patton08

      1. Jeff Patton
      2. Ambiguous Business Value Harms Software Products
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp50-51
      4. =HARMFUL AMBIGUITY REQUIREMENTS FEATURES vs =ADVERT GOAL + METRIC GQM
      5. IRACIS::acronym="Increase Revenue, Avoid Costs, Improve Service", [GaneSarson77].
      6. Brainstorm->cards; cluster; Vote on priority (ceiling(|clusters|/3) votes per person), metrics, Poster

      2008-06-04 Wed Jun 4 20:06 Teams and Technology

      What technology should a distributed team use when developing software? What new technologies can we use in our systems?

      ThomasBostromGouge07

      1. Dominick M Thomas & Robert P Bostrom & Marianne Gouge
      2. Making Knowledge Work in Virtual Teams
      3. Commun ACM V50n11(Nov 2007)pp85-90
      4. =POLL 13 MANAGERS 30 PROJECTS DISTRIBUTED TEAMS COMMUNICATION TECHNOLOGY MATHODS
      5. ICT::="Information and Communication Technologies".
      6. More than 20 different ICTs.
      7. It is not enough to make technology available.
      8. Problems: team volatility, time pressue, interoperability all lead to work stopages and managerial intervention.
      9. All teams used audio confeences, EMail, and the phone.
      10. >70% used: Fax, project management, calendar, IDEs,many-to-many chat, versioning, instant 1-1 messaging,...
      11. Intervention:=(opportunity | problem) triggers leader actions and changes; aim for higher participation and capacity, leading to project outcomes.
      12. May have to shut down an ineffective technology as well as promote a better one.
      13. Triggers: outside the team, inadequate tools, breakdown of trust and relationships, interference in group work, member knowledge.
      14. Interference:turnover, cultural difference, physical distance, time zones

      BrownShipmanVetter07

      1. Jeff Brown & Bill Shipman & Ron Vetter
      2. SMS: The Short Messaging Service
      3. IEEE Computer Magazine V40n12(Dec 2007)pp106-110
      4. =STANDARD SMS PROTOCOL CELL MOBILE PHONE Shortcodes WAP EMAIL
      5. SMS::protocol="Short Message Service", not just for teenagers, also connects to the web and EMail.

      Heyman07

      1. Karen Heyman
      2. A new virtual private network for today's mobile world
      3. IEEE Computer Magazine V40n12(Dec 2007)pp17-19
      4. =STANDARD SECURITY PROTOCOLS WWW/NET UDP IPsec TCP SSL VPN

      2008-06-03 Tue Jun 3 19:06 Having a Fit

      Luckily I'm not having a fit about the local IRS office not letting us get in line for a sailing permit, or about my anti-virus software grabbing 90% of the bandwidth to download a complete new executable on Tuesdays and Thursdays.... But a proposes way of documenting requirements in an executable form -- a test expressed as a scenario with tabular steps.

      MartinMelnick08

      1. Robert C Martin & Grigori Melnick
      2. Tests and requirements, requirements and tests: a Mobius Strip
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp54-59
      4. =ADVERT REQUIREMENTS TESTS FIT TABULAR SCENARIOS
      5. FIT::tool= See http://fit.c2.com , Framework for Integrated Testing [ samples/methods.html#Fit ]

      Mugridge08

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

      2008-06-03 Tue Jun 3 10:06 Out Source and Open Source

      Four items in this batch. First a report of changes in outsourcing, then two books and a paper on F/OSS (Free/Open Souce Software. We have a text book on the technology and system, a political economists view of why open source has been successful, and a report of open source being used to teach software evolution/maintenance.

      Leavitt07

      1. Neal Leavitt
      2. The Changing World of Outsourcing
      3. IEEE Computer Magazine V40n12(Dec 2007)pp13-16
      4. =ARTICLE OUT SOURCING TRENDS DISTRIBUTED
      5. Consolidation. More countries. Smaller tasks/projects/companies. More complex systems. Not just the cost!

      DeekMcHugh07

      1. Fadi P Deek & James A M McHugh
      2. Open source: technology and policy
      3. Cambridge UP NY NY 2008 ISBN 0-521-88L03-X
      4. =TEXT Open source

      Weber05

      1. Steven Weber
      2. The success of open source
      3. Harvard University Press Cambridge MA ISBN 0674018583 CR 0611-1091
      4. =HISTORY SOCIAL POLITICAL ECONOMICS OPEN SOURCE CODE F/OSS
      5. (dick)|-Excellent survey by an outsider of the open source phenomenon.
      6. (dick)|-Last chapter has too much social science jargon.
      7. (dick)|-Only spotted one error: confused JavaScript with Java.
      8. (dick)|-Some small omissions: in the 60's software was bundled with the hardware & user groups shared their developed software, KDE may be a pun on Sun's CDE, Wikipedia, ...

      PetrenkoEtAl07

      1. Maksym Petrenko & Denys Poshyvanyk & Vaclav Rajlich & Joseph Buchta
      2. Teaching Software Evolution in Open Source
      3. IEEE Computer Magazine V40n11(Nov 2007)pp25-31
      4. =ADVERT SC EVOLUTION OPEN SOURCE EDUCATION CVS
      5. SC::="Software Change".
      6. Software_Change_Process::= Initiation; locate_concept; analyse_impact; (testing & (prefactoring; actualization; change_propagation; postfactoring)); new_baseline.
      7. CVS -- change version system for source code control and to provide data for grading. Note: difficult to set up. Students must get special training and practicebefore being let loose on the real code.
      8. Students work on realistically sized code and make realistic changes.
      9. Graduate students act as managers -- either for one team or all teams.
      10. Grades based on CVS records and interviews.
      11. Student opinions collected.

      2008-06-02 Mon Jun 2 19:06 Fear and Loathing of Complexity

      The following reflects my own beliefs:

      Santini07

      1. Simone Santini
      2. Making computers do more with Less
      3. IEEE Computer Magazine V40n12(Dec 2007)pp124+122-123
      4. =ADVERT SIMPLE TECHNOLOGY WEB/NET UPGRADES
      5. Argues that invisible downloads into a personal machine is a kind of trepass.
      6. Argues for using the simplest non-invasive technology for software and web pages.

      2008-05-30 Fri May 30 10:05 Fear and Loathing of Upgrades Part 2

      Below I described how well the Palm Tungsten Software upgraded from an E to an E2. But when I updated the Palm Desktop on my office laptop ( Part2 ) things were not as good. (1) The desktop crasshes if you are viewing a daily calendar and try to look at your to-dos at the same time. (2) most of my categories in the calendar have gone.... Events at work looked like they were for my wife. Not good.... spending time putting the categories back. (3) The Media application (Photos and videos) decided that it should send all its photos to the hand-held, even if they were duplicates. Spent time removing them.

      And my own personal cradle -- a rather nice Chinese Panda [ palmpanda1.jpg ] -- no longer fits the new handheld+cable:-(

      Well I wonder what will happen next.

    3. 16:05 Ugly First the story so far: Installing the upgraded Palm desktop software lead to the Palm E2 losing all the categories. Going back to the back machine deleted them from that back up system.

      Oddly each application on the palm behaves differently when you recreate deleted categories. The "Tasks" application accepts them and places the records back in the right (old) categories. The "Calendar" accepts them and assigns the event to categories so that most are right, but some are wrong. The "Memo" and "Contacts" application on the desktop refiles items in deleted categories as "Unfiled" so that you have to go thru it and file them correctly their -- even tho' the handheld has the categories OK!

      The cost: 2..3 hours of refiling on the laptop. Then I discovered that if you force the HotSynch to update the desktop from the palm top, AND if they have the same categories listed then the Memos and Contacts get filed in the category. To be precise, this is how I read the warning message that "File Categories" are not updated when the handheld over-rides the desk-top.

      Note that the data has not been normalized. These are all the kind of anomalies found in a less than third normal form data base.

      Notice that there is clearly no reuse of code or designs between these different parts of the Palm software.

      2008-05-29 Thu May 29 20:05 Economic ideas

      I agree with the first idea below: figure the value at risk of data as well the total cost of ownership. I'm not so sure about Michael Wing's code-centric view of software.

      TallonScannell07

      1. Paul P Tallon & Richard Scannell
      2. Information Life Cycle Management
      3. Commun ACM V50n11(Nov 2007)pp65-69
      4. =IDEA ECONOMICS DATA RELIABILITY COST VALUE RISK
      5. Can't mitigate all risk without high cost. Low costs can mean unacceptable risks.
        Keep the total cost of ownership of data ballanced with the value at risk -- cost of losing the data.
      6. information_life_cycle::= capture application decline. Value highest in the application phase.
      7. value at risk: graph frequency vs busines consequence of various events.

      WingM07

      1. Michael Wing
      2. On the Economics of Software
      3. ACM SIGSOFT Software Engineering Notes V32n6(Nov 2007)pp8-9
      4. =IDEAS CODE ECONOMICS PROTOTYPING QUALITY VALUE COST
      5. Code is one of the most valuable artifacts -- even if it is of bad quality. The value comes from it being used.
      6. The cost of code has a complex relation to its quantity.
      7. Each relase costs twice as much.

      2008-05-28 Wed May 28 18:05 Components and Reuse

      Here are an article and a paper on components in engineering. The first is about how a technical solution to a problem leads to new problems. The second is a comparison of different component frameworks:

      OshriNewellPan07

      1. Han Oshri & Sue Newell & Shan L Pan
      2. Implementing Component Reuse Strategy in complex environments
      3. Commun ACM V50n12(Dec 2007)pp63-67
      4. =CASESTUDY ENGINEERING REUSE PEOPLE MEETINGS DOCUMENTATION HARDWARE R&D RATIONAL
      5. Engineers unhappy with reuse: exploration became exploitation + too many meetings.
      6. The design of a component does not record its rationale.
      7. Proposes that meetings to present new components should be held in laboratory with technical tools to demo ideas.
        Problems with redesign feedback loops and time needed to reuse previous work.
      8. (dick)|-management confused research with development.

      LauWang07

      1. Kung-Kiu Lau & Zheng Wang
      2. Software Component Models
      3. IEEE Trans Software Engineering V33n10(Oct 2007)pp709-724
      4. =SURVEY MODULES ARCHITECTURE EJB COM .NET CORBA PECOS UML2.0 SOFA ...

      2008-05-27 Tue May 27 20:05 Fear and Loathing of Upgrades

      We spent Memorial Weekend looking for a place to retire: cooler than San Bernardino, near libraries, entertainment, and affordable on pensions. One realtor talked about how he wouldn't be tackling any searches of the Multiple Listing Service until the system was upgraded. I always loathed the effort involved in upgrades -- inserting endless CDs (UNIXen) or a long World Wide Wait for downloads (or both)... and the occasional MS windows freeze when the MS upgrade collides with the touch pad driver on one laptop....

      I Stan Kelly Bootle's dictionaries there used to be a "Riddle Song" with the line:

    4. I promised my love an upgrade without any crying.

      Plus the punch line

    5. I was lying.

      I particularly fear new software because I am blessed with the ability to discover bugs. It happens without thought. As the old saying had it "Nothing is fool proof -- fools are too ingenious".

      So I was not looking forward to upgrading my Palm Tungsten E to an E2. It was forced: the battery charger for the old E was held together with toothpick splints, the glue on the keyboard had broken, the digitizer was consistently about 1/8 inch low on the bottom left of the screen and horrifically slow on the middle left of the screen, and the on-off button had arthritis. A system has to be this bad to force me to upgrade.

      So I ordered a replacement from Palm. And expected it to arrive on next Thursday. And tried to not worry about it. Would the 17Mb of data move to the new machine? How do I move the encryption software to the new machine? Would the digitizer have similar fault? What new bugs would I have to work around.

      The E2 arrived today at about noon. All undamaged... and it took 3 hours to charge the battery. The CD updated the Software on the Back up lap top -- and installed all the data and the old applications with the first hot-synch! Pretty good going. A slight glitch when I didn't set the date and found I had no todos or scheduled events -- the E2 was set to 2005 -- which crashed the OS:-( Another small crash in the notepad when testing the digitizer:-( My grafiti shorthand has gone and needed reprogramming. And I've gained some categories that I don't want -- and since I can only have 15 all my Vendor contacts moved into unfiled:-(

      In summary -- much better than I feared. We will see what happens next. See Part2.

      2008-05-23 Fri May 23 06:05 Workflow determines a helpful interface

      This paper reports an experiment that shows that helpful user interfaces can be automatically constructed from a model of the what the user has to do. The result provides the context for the work which helps non-experts to do the work.

      ZouZhangZhao07

      1. Ying Zou & Qi Zhang & Xulin Zhao
      2. Improving the usability of e-Commerce Applications Using Business Processes
      3. IEEE Trans Software Engineering V33n12(Dec 2007)pp837-855
      4. =EXPERIMENT USER INTERFACE BUSINESS WORKFLOW MODEL XML Java
      5. Tools derive user interface directly from an encoded model of the workflow and the needed data, forms, and functions.
      6. Result improves usability for non-expert users.
      7. Screens show Navigation + Processes + Tasks + Workspace panes/frames.
      8. The workspace shows only the relevant screens for current Tasks.

      2008-05-22 Thu May 22 12:05 Evidence for an old fashioned step being useful

      My campus [ http://www.csusb.edu/ ] has a long history of fairly painless changes in Information Technology(IT). This includes the recent implementation of a system wide ERP. Last year the faculty started to use the new CMS system for handling rosters, adds, drops, and grades. The reading below states that on two other campuses, even though faculty were involved in developing new IT, they did not like the resulting system -- in one case it has dubbed a failure and completely redeveloped. Here is the citation:

      WagnerPiccoli07

      1. Erica L Wagner & Gabriele Piccoli
      2. Moving beyond participation to achieve successful IS design
      3. Commun ACM V50n12(Dec 2007)pp51-55
      4. =CASESTUDIES USER PARTICIPATION DESIGN ERP FAILURE ANALYSIS CS372
      5. Users were really involved with current system not the new one until the project was went live.
      6. Start by focusing on what users are doing in current system.
      7. Get user stories of current challenges and successes.
      8. Analysts must learn to translate user expertise into designs that fit.
      9. Change SDLC to include iterations after it goes live.
      10. (dick)|-3 known techniques confirmed.
      11. (dick)|-presumes "Big Design Up Front", A more incremental approach gets users involved within their current work process.

      Now, here is story that explains why CSUSB has not had failures like this. When I arrived, in 1982, the registration process was based on a main frame computer and punched cards. Each department had a faculty representative sitting in the gym handing out cards to students. These card represented seats and acted as tickets. A classic "visual record" system. But I knew that this was about to change -- I had made sure to court my colleagues in the "Computer Center". Experience with software development lead me to worry about the change. To be honest I worry about all upgrades -- I'll write something on "Fear and Loathing in Upgrades" real soon now.

      In this case, the system being changed was central to the enterprise and it would be a large change. So I was worried. Then I saw, across the gym, the systems analyst in charge of the project. He was observing what was going on. He checked on each of the departmental "booths". He was also frowning. When he came by, I asked him what he felt. He said there was a lot going on that nobody had mentioned in meetings.

      It was at that moment I knew that the new system would be an improvement of the old one.

      So, in 1982 computer professional knew something that some current computer professionals have forgotten -- the importance of studying the current system. In the 1970's the first step is to analyze the current system -- know what people do, know what is good about it, know what is bad, know what is supposed to done vs what actually happens. Perhaps, the movement that proposed skipping this step and focusing on the "Essential System" may have encouraged many places to abandon a useful practice.

      The other suggestion of expecting changes to be made after the project goes live has also been a part of software development for decades -- plan to throw one away, you will anyway.

      2008-05-21 Wed May 21 19:05 Unsafe software

      Here are a couple of articles on attempts to establish procedures for assuring the safety or at list trustworthiness of software. Both articles take a pessimistic view of government procedures and standards.

      BishopWagner07

      1. Matt Bishop & David Wagner
      2. Risks of E-Voting
      3. Commun ACM V50n11(Nov 2007)p120
      4. =REPORT TECHNICAL SOURCE CODE REVIEW VIRAL RISKS SECURITY QUALITIES
      5. The authors found buffer overruns, hard-coded encryption keys, dumb pseudo-encryption, dumb passwords etc. in all voting systems.
      6. Federal tests did not disclose the flaws. Code review did.
      7. Voting systems must be transparent.
      8. Need for audits.

      Thomas07

      1. Martyn Thomas
      2. Unsafe Standards
      3. IEEE Computer Magazine V40n11(Nov 2007)pp109-111
      4. =REVIEW STANDARDS PROCESS ISO 61508 DO-178
      5. Based on a recent NRC Report.
      6. Safety is a systems property not just a software one.
      7. Three_Es::= Explicit safety claims + Evidence + Expertise.
      8. We don't have the evidence to substantiate the claims specified in the current standards.

      2008-05-20 Tue May 20 19:05 Ruby on Rails

      Here is a short introduction to a very popular way to rapidly develop a web-based application

      BachleKirchberg07

      1. Michael Bachle & Pauk Kirchberg
      2. Ruby on Rails
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp105-108
      4. =DEMO RUBY ROR TECHNICAL WEB PLATFORM RAPID PROTOTYPING MVC
      5. Also compares with Apache Struts, Tapestry, Cocoon, and ASP.NET

      2008-05-19 Mon May 19 14:05 Practical research and standards

      Robert Glass is something of a gadfly but sometimes he reports something that is novel, reliable, and has practical implications... in this case about a well known standard having problems. I've matched it to a report on how standard software imporvement process had to be tuned to their environment. I've added a report that confirms one of the blessed Glass's claims: software projects do not fail as often as some have reported: a 60% success rate is common.

      Glass07a

      1. Robert L Glass
      2. A Research project with important practitioner-oriented findings
      3. Commun ACM V50n11(Nov 2007)pp15-16
      4. =REPORT EXPERIMENT STANDARD ISO/IEC 9126 QUALITIES DESIGN METRICS
      5. H Al-Kilidar & K Cox & B Kitchenham, The use and usefulness of the ISO/IEC 9126 standard, Proc ISESE 2005 conference.
      6. The standard was ambiguous and not easy to use (by student teams).

      OktabaEtAl07

      1. Hanna Oktaba & Felix Garcia & Mario Piattini & Francisco Ruiz & Francisco J Pino & Claudia Alquicira
      2. Software Process Improvement: the Competisoft Project
      3. IEEE Computer Magazine V40n10(Oct 2007)pp21-28
      4. =STANDARD IMPROVEMENT SOUTH AMERICAN SMALL ENTERPRISE CMMI VSE ISO MOPROSOFT
      5. One size does not fit all: small enterprises need special software improvement methods.

      SauerEtAl07

      1. Chris Sauer & Andrew Gemino & Blaize Horner Reich
      2. The impact of size and volatility on IT project performance
      3. Commun ACM V50n11(Nov 2007)pp79-84
      4. =POLL SUCCESS SIZE CHANGE UK BUDGET SCHEDULE SCOPE
      5. 2/3 projects succeed (according to their managers).
      6. CF [Glass05]
      7. More effort (person*months) increases risk of failure.
      8. Changing team increases risk of failure.
      9. Moving targets increases risk of failure.

      2008-05-16 Fri May 16 06:05 Incubating Projects

      In the traditional systems life cycle a critical first stage is deciding what projects to tackle, gathering information that is needed to develop the software, organizing a team, etc.

      It appears the Free/Open Source communities have spontaneously developed well defined procedures which can turn a single person's vision in to a project that the community is committed to. Here is a comparison of the Apache and the Eclipse processes for incubating projects.

      DuenasEtAl07

      1. Juan C Duenas & Hugo A Prada G & Felix Cuado & Manuel Santillan & Jose L Ruiz
      2. Apache and Eclipse: Comparing open source project incubators
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp90-98
      4. =EMPIRICAL COMPARISON 2 F/OSS PROCESSES PROJECT INITIATION LIFE CYCLE
      5. Incubation is the process of developing and defining new project/subprojects to be further developed and integrated into a the current (evolving) system.
      6. Apache and Eclipse have well defined processes and share many features (Table 1 page 97)

      2008-05-15 Thu May 15 17:05 Started Organizing MATHS Project

      I've decided to treat my sabbatical project as a sample project: [ samples/maths.html ] so that it will use MATHS (the notations and tools) to develop MATHS (the tools and notations). I've copied some of the items below into a new blog.

      You can always findout what is going on -- spread over several blogs by visitting my home/index page [ index.html ] , by the way.

      2008-05-14 Wed May 14 18:05 The Choice Uncertainty Principle

      Lot of exercise today: walkinging and weights first thing, then getting leaves out of the pool, then walking accross the parking lot carrying this old Dell for its monthly dose of updates,... But a pleasant morning in the library checking out Jerry Weinberg's Introduction to General Systems Thinking and Principia Mathematica chapter *93. Brought home a book of F P Ramsey's papers on logic and philosophy.

      Now here is an interesting new working rule from Peter Denning

      Denning07b

      1. Peter J Denning
      2. The Choice Uncertainty Principle
      3. Commun ACM V50n11(Nov 2007)pp9-14
      4. =ESSAY RACE HAZARDS ARBITRATION SYNCHONISATION NON-SEQUENTIAL METASTABLE STATE flipflop Buridan
      5. CUP::= "No choice between near-simultaneous events can be made unambiguously within a preset deadline".
      6. 9 refs. Many examples: hardware, software, and mundane.

      2008-05-13 Tue May 13 14:05 What people think about software development projects

      Here are a couple of papers that are based on "Surveys of the literature".

      CarmelAbbot07

      1. Erran Carmel & Pamela Abbot
      2. Why 'nearshore' means that distance matters
      3. Commun ACM V50n10(Oct 2007)pp40-46
      4. =SURVEY 150 ARTICLES DISTRIBUTED PROCESS LOCATION OUTSOURCE OFFSHORE SHORING SOURCING
      5. nearshore::= low geographical temporal cultural linguistic political economic historical distance to lower wage software development.
      6. Some places are both exporters and importers of software work.

      UmeshJessupHuynh07

      1. U N Umesh & Len Jessup & Minh Q Huynh
      2. Current issues faced by technology entrepreneurs
      3. Commun ACM V50n10(Oct 2007)pp60-66
      4. =SURVEY PRESS FINANCE ECONOMICS SKILL OUTSOURCING FIT USABILITY TAMSM
      5. Market dominance depends on overcoming hurdles rather than the quality of the idea.
      6. Outsourcing can be both a resource and a challenge.
      7. hurdles: finance, skill, fit customers, fitting existing products, ease of use, security, useful.
      8. TAMSM::="Technology Acceptance and Market Success Model". Based on TAM 1989.

      Meanwhile -- working on requirements and the available technologies for my sabbatical project, and sorting out leaks in (1) my accounting and (2) a bath room tap. Also reviewing the syntax and semantics of documentation in my MATHS language -- [ maths/notn_13_Docn_Syntax.html ] [ maths/notn_14_Docn_Semantics.html ] [ maths/notn_15_Naming_Documentn.html ] etc. .

      2008-05-12 Mon May 12 14:05 YAML -- XML considered harmful

      My favorite blog just sent me an excellent article [ 001114.html ] which says something that I have been thinking ever since XML was invented -- that it may not be the best solution for all your data encoding needs. As evidence the author gives examples of YAML [ samples/languages.html#YAML ] which are both easier to read and still 99% unambiguous.

      Like my own MATHS language it use white space to indicate structure. But it goes further by having no open+close bracketing syntax. It is all done by indentation. Much the same way CODIL did (does?).

      I'm tempted to formalize YAML into my MATHS language as a long format for complex objects:

    6. CIRCLE( center=> POINT( x=>1, y=>2 ), radius => 10 ) 
       .Open.YAML
           center:
              x : 1
              y : 2
           radius : 10
       .Close.YAML

      But this will need some thought about current features of MATHS and how simple implementation might be. Can it be done with the UNIX standard tool kit -- sed/auk/...?

      By the way I've added some links to Polya's book "How to Solve It" below.

      2008-05-09 Fri May 9 17:05 Sabbatical Project -- MATHS

      My sabbatical project is not making much progress. The next post is typical of the reading that I have been doing that indicates that there may not be a market for a simple, formal notation for mathematics -- even if designed to have a lot in common with programming languages. The language exists [ maths ] and has stabilized over several years personal use. My project is to add a new feature heading in the direction of a wiki.

      In the project I was hoping to move in the direction of a wiki-style site that used the language with a lot of people contributing information, notes, samples, and so on. Yesterday I looked into a "PHP Phrasebook". It is full of warnings about the bad things can do if they supply data and some of the things you can do to avoid them. I knew about the risk of passing HTML code with "<script>" tags and have (for years) translated HTML-special symbols in MATHS into entities on HTML pages.

      What I had not thought about is that URLs can not be trusted. I'm quite paranoid about clicking on links and attachments for example in EMail. But I'm starting to wonder if I can trust links in the WikiWikiWeb and the Wikipedia any more.

      This is fairly typical of requirements... a desirable feature comes with a poison pill. It is also typical that you discover the poison pill after the project is well under way. It is also an example of a negative requirement -- something that must not be possible.

      MATHS Project Features

      1. (REQ1): Users should be able to edit MATHS web pages.
      2. (REQ2): Users must not be able to include links to illegal and/or malicious URLs.
      3. (NAT1): Some people attempt to include illegal and malicous links in my pages.
      4. (above)|-Anonymous users may need to have their changes vetted before inserting.
      5. (above)|-Untrusted users may be limited to local links.
      6. (above)|-There may be away to join a group of trusted users who will get full access to the system
      Note: In the above I distinguish requirements (labeled REQn) from known facts (NATn). This comes from the SCR project and Michael A Jacksons recent publications.

      Contact me if you have an thoughts.

      2008-05-08 Thu May 8 16:05 Mathematics Made Boring

      Here is a powerfully expressed argument that mathematics is taught the wrong way:
    7. LockhartsLament::= See http://mail.geneseo.edu/pipermail/math-thinking-l/attachments/20080507/b091d446/LockhartsLamentArticle.pdf

      To quote from the end of the article

    8. "SIMPLICIO: Alright, I'm thoroughly depressed. What now?"


      (Polya): one antidote for the above Lament is Polya's method of teaching and doing mathematics [Polya88] ("How to solve it"). Also see some notes [ samples/polya.html ] and [ maths/logic_20_Proofs100.html#polya ] on Polya's "New Heuristic".

      2008-05-08 Thu May 8 14:05 Alloy and JacksonD06a

      I've just updated my previously unannounced bibliographic item for Daniel Jackson' 2006 text book. Previously it was tagged "=UNREAD" in my bibliography and didn't have much details. I've now spent a week studying it and have posted this:

      JacksonD06a

      1. Daniel Jackson
      2. Software Abstractions: Logic, Language, and Analysis
      3. The MIT Press Cambridge MA 2006 ISBN 0262101149 CR 0802-0116
      4. =TEXT Alloy LIGHT FORMAL MODEL CHECKING METHODS TOOLS
      5. A neat way of finding bugs in specifications and requirements.
      6. Small_scope_hypothesis::=Most bugs have small counterexamples.
      7. Notes the difficulty of creating consistent formal models that have the desired properties.
      8. Alloy::language=a formal first order relational logic expressed in ASCII with tools in Java.
      9. Alloy_examples::= See http://softwareabstractions.org.
      10. Alloy_analyzer::= See http://alloy.mit.edu.
      I like the quirky examples: how can I be my own grandfather? How do hotel key-cards work and what bugs do the have? ...

      Alloy is something of a rival to my own MATHS language. It is a cleverly chosen subset of first order logic that can be analyzed by a Java program -- you can check for consistency and also check to see is properties must be true. It relies on finding counter-examples to assertions in a small universe. The general problem is clearly intractable. Hence the limit on the help that can be provided by tools using my own MATHS language -- which is more general.

      2008-05-07 Wed May 7 18:05 Tools for teams

      I've just improved my very sketchy notes on probability theory [ maths/math_81_Probabillity.html ] to the point of sketching definitions of expectation, entropy, mean, moments, etc.

      Meanwhile here are three articles/papers on tools that teams can use:

      Frost07

      1. Randall Frost
      2. Jazz and the Eclipse Way of Collaboration
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp114-117
      4. =ADVERT ENVIRONMENT TEAMWORK PROCESS BUG BUILD TRACKING ECLIPSE
      5. Jazz extends on Eclipse to coordinate many programmers.

      RechBognerHaas07

      1. Jorg Rech & Christian Bogner & Volker Haas
      2. Using Wikis to Tackle Reuse in Software Projects
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp99-104
      4. =EXPERIENCE WIKI ARTIFACTS ONTOLOGY SEARCH TAGS RIKI
      5. Wiki made it easier to save and share documents etc.

      FluriEtAl07

      1. Beat Fluri & Michael Wursch & Martin Pinzger & Harald C Gall
      2. Change Distilling: Tree Differencing for Fine-Grained Source Code Change Extraction
      3. IEEE Trans Software Engineering V33n11(Nov 2007)pp725-743
      4. =DEMO ALGORITHM TOOL Eclipse plugin AST STRING MATCHING

      2008-05-06 Tue May 6 18:05 Experimental prototypes and pair programming

      Here are two articles that are worth reading. The first presents the case for experimental protoypes and describes the risks. A pretty good summary of experience. The second reports on the research that' has been done on pair programming where two people work on an artifact at once. One has the keyboard and the other makes comments. Here the value comes from experiments done with the technique.

      Rainsberger07a

      1. J B Rainsberger
      2. Just Try It
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp16-17
      4. =ANECDOTE EXPERIMENTAL DESIGN TEAM PROTOTYPING PEOPLE
      5. Sometimes it is better to try at an idea than spend time debating it -- running an experimental prototype.
      6. Risks of dominant programmers.
      7. Risks of keeping experimental code.
      8. Need for a clear question and time limit for experiments.

      DybaEtAl07

      1. Tore Dyba & Erik Arishlm & Dag I K Sjoberg & Jo E Hannay & Forrest Shull
      2. Are two heads better than one? On the effectiveness of pair programming
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp12-15
      4. =META-ANALYSIS EXPERIMENTS PAIR-Programming QUALITY COST
      5. Quality tends to be a little better and the time to complete the project is better. The effort (people * time) is slightly worse.

      2008-05-05 Mon May 5 13:05 Software Reliabillity Probabillity etc

      I've made some small improvements to some pages introducing my MATHS language: [ maths/intro_records.html ] showing how to describe structures with optional and multiple parts. For example to state that a cat has 4 legs...
    9. CAT::=Net{ cat: $ LEG ^ 4 ,...}.

      I've gathered an article and a paper on the use of probabillity theory and statistics to predict the reliability of software.

      AlmeringEtAl07

      1. Vincent Almering & Michiel van Genuchten & Ger Cloudt & Peter J M Sonnemans
      2. Using Software Reliability Growth Models in Practice
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp82-88
      4. =EXPERIENCE 5 MODELS TVs RELIABILITY
      5. The models got better as more data was fitted.
        λ(t) :=failure intensity function.
      6. (GO): λ(t) =a*b*exp(-b*t).
      7. (delayed S): λ(t) =a*b^2*t*exp(-b*t).
      8. (log power): λ(t) = α*β*ln^(b-1)(1+t)/(1+t).
      9. (log Poisson): λ(t) = λ[0] / (λ[0] * θ * t + 1).

      DaiXieLongNg07

      1. Yuan-Shun Dai & Min Xie & Quan Long & Szu-Hui Ng
      2. Uncertainty Analysis in Software Reliability modelling by Bayesian Approach with Maximum-Entropy Principle
      3. IEEE Trans Software Engineering V33n11(Nov 2007)pp781-795
      4. =THEORY PROBABILITY RELIABILITY PREDICTION
      5. Problems: few tests fail, incorporating prior information, uncertainty in models reduces reliability.
      6. MEP::= "Maximum-Entropy Principle", choose an a prior distribution to maximize the entropy given the known data.
      7. For distribution p, entropy(p):= Expected_value(-ln(p(_))).
      8. Use Bayesian a postiori formula to encorporate data from tests.
      9. Use simulation and analysis to predict relibilities of whole system.
      10. Gives examples.
      11. Refers to texts for calculations of MEP.

      2008-05-02 Fri May 2 10:05 An Example of Bad Requirements Analysis

      To some extent I'm writing this entry now to keep our home phone line busy to shut up the repeated calls by the local school district substitute system also known as SmartSearch. If you answert the phone by saying something then the nice voice identifies itself and invites you to either input the substitutes ID number folowed by the star key, or by star key to wait for the substitute to come to the phone. There don't seem to be any other scenarios.

      So if the substitute is out of the house there is no real response you can make. So cover the phone and wait for the system to go away. It phones back a few minutes later.

      The old system had included the assumption that the substitute could not come to phone -- you dialed "**3" and it went away for several hours. The new system does not.

      Of course the substitute can program the system to not call -- but this process takes about 15 minutes and is error prone...

      So how do you spot holes in your understanding of the world in which your software is going to operate?

      It is a common problem. And the best solution I've seen is to construct a model that expresses the structure and logic of the real world outside the computer. I've spent years looking at ways to do this. One technique might be called literate analysis and uses a mixture of natural language, mathematics, logic, and diagrams. I have an old example [ papers/rjb0xa.lift.html ] of a model of the famous lift problem. I plan to revise it sometime real soon now and include manual UML diagrams.

      Another approach is to have a set of patterns or an ontology for requirements. I've just read about two books on this topic, which I hope to read in detail one day: [Hruby06] and

      RoemannGreen05

      1. Michael Roemann & Peter Green (Eds)
      2. Business systems analysis with ontologies
      3. Idea Group Pub Hershey PA 2005 ISBN 0804-0350 CR 0804-0353
      4. =UNREAD =THEORY BUSINESS ANALYSIS BWW RM-ODP ONTOLOGY
      5. BWW::="Bunge-Wand-Weber".
      6. Notes [click here [socket symbol] if you can fill this hole]
      (The "plug hole" above invites you supply your thoughts on the items... I will review, edit and post...).

      2008-05-01 Thu May 1 11:05 Users and Human Computer Interfaces

      I was very interested in what we used to call user friendly computing in the 1980's. It was very much a matter of creative design in those days. Also a battle with inadequate hardware interfaces: no mice or other pointing devices. But I was able to create "FRED, the FRiendly EDitor" for beginning Computer Science students.

      Since then we have seen the emergence of a dominant WIMP model. The MIT press have recently published a couple of books challenging it. I've just found them in CSUSB library new books.

      EricksonMcDonald08

      1. Thomas Erickson & David W McDonald (Eds)
      2. HCI Remixed -- Essays on Works that have influenced the HCI Community
      3. The MIT Press Caambridge MA 2008 QA76.9.H85H4125 ISBN 978-0-262-05088-3
      4. =HISTORY =ESSAYS USERS Human Computer Interfaces HCI
      5. Any book with an essay on Ted Nelson's Computer Lib/Dream Machines must be good!

      KaptelinCzerwinski07

      1. Victor Kaptelin & Mary Czerwinski (Eds)
      2. Beyond the Desktop Metaphor -- Designing Integrated Digital Work Environments
      3. The MIT Press Caambridge MA 2007 QA76.9.H85B539 ISBN 978-0-262-11304-5
      4. =PAPERS USER HCI METAPHOR Lifestreams Haystack Task Gallery GroupBar Scalable Fabric Soylent

      (And in the middle of writing the above entries seated in the CSUSB library the WiFi network went down and so I had lunch... Now back in my office... and much quieter than the library, sadly)

      2008-04-30 Wed Apr 30 18:04 Requirements worst practices

      Neil Maiden claims to interviewed a leading expert in the field of requirements ... but his advice seems to be the reverse of the best practices. For example: use fuzzy natural language and weasel words to avoid committing the developers to anything. I also like the advice to be very rigorous with the process...

      Codefirst07

      1. Colin Codefirst (alias) & Nail Maiden (ed)
      2. From the horses mouth
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp21-23
      4. =JOKE REQUIREMENTS SPECIFICATION WORST PRACTICES

      2008-04-29 Tue Apr 29 19:04 Social Processes of Mathematics

      I've recently read something a little outside the main thrust of this blog. Be warned this entry is not, at first, linked through to software development. I, by accident read a layperson's introduction into a esoteric bit of pure mathematics: the Poincare Conjecture. See [ OShea07 ] below for the citation. The description of the publication of the proof of the conjecture, and then it's public presentation -- a walkthrough that took several days -- and exposed a few small errors is an example of a social process that iterates towards the truth.

      One of the mistakes in early "formal" methods was in glossing over this part of mathematical work. We stressed the formal correctness of results rather than the need for people to review the proofs to correct them.

      One of the things I want to do is to develop a more open system that allows mathematical ( and logical ) work to be published and then worked on by many people. I envision the creation of documents ( requirments, designs, code, tests) that can be shared and edited -- and that include a rich hypertext structure -- definitions linked to usage of terms -- and mathematical notation for convenience.

      2008-04-28 Mon Apr 28 18:04 Charrettes in Software Development

      First an apology -- the coughs and sneezes and fevers knocked me out for another week or so. April is something of a write-off.

      In the latest weekend edition of the Los Angeles Times I met a word that I not seen before: charrette and had to search through three dictionaries to get a definition. A charrette is an intensive group or individual period of architectural design. It comes from the French for tumbril -- a cart used to take people to the guillotine for execution. I found a very good description and history of the term on the Wikipedia:

    10. charrette::= See http://en.wikipedia.org/wiki/Charrette

      The above description reminds me alot of the intensive all night work that is done in developing software in some organizations. However I can only trace one example of the word charrette being used as part of a software process. And here [ Mindjet-Labs-Charrettes.aspx ] a software developer is using his education as an architect to create a design/requirements workshop.

      Perhaps we should seek to apply charrette to eliciting requirements and blitzing a design.

      I would like to see any evidence for the value of this technique in eliciting requirements and designing interactions.

      However if the whole development provcess degenerates in a ride to the scaffold <audio source=Berlioz\> then we are almost certainly in a death march project [ bib.php?search=death.*march&from=blog ] and definitely breaking the XP practice of a 40-hour week. I thinki we should deprecate this kind of charrette.

      2008-04-11 Fri Apr 11 14:04 Assertions annotating source code

      In the previous entry I developed the idea that good code may need extra comments in it that explain what it is doing and how it is supposed to do it. See [ beautiful code ] below.

      I finished with the promise of an example. It took me a chunk of last night. I'll be using a code fragment in a language like C/C++/Java/etc/. This is based on code I learned from a colleague 30 years ago... but with a twist.

      Here it is without comments 

       		while ( low < high - 1)
       		{
       			middle = (low + high) / 2;
       			if( array[middle] < target )
       				high = middle;
       			else if( array[middle] > target )
       				low = middle;
       			else low = high = middle;
       		}
      You probably recognize it. But do you really know what the variables are doing? What properties they must have? The odds are you'll be wrong.

      (Yes, a few test cases would help -- examples always help ).

      Now here is the same code with added invariant assertions 

       	// array and target are constant
       	// if i < j then array[i] > array[j]
       	// low=-1 and high = sizeof(a)/sizeof(a[0])
       		while ( low < high - 1)
       		{
        	  // array[low] > target and array[high] < target
       			middle = (low + high) / 2;
       			if( array[middle] < target )
       				high = middle;
       			else if( array[middle] > target )
       				low = middle;
       			else low = high = middle;
       		}
      Now I haven't proved the above fragment -- proving is an expensive task reserved for highly reusable algorithms and life-critical software in my current play-book.

      But you have been warned that this binary search is a reversed version that requires the array to be in decreasing order. You can also see that the low and high variables are always just outside the range of elements that might contain the target

      Also notice that 

       	// if i < j then array[i] > array[j]
      can not be written as a C/C++/Java/etc. Boolean expression. First of all it has "if_then". Now you can simulate this quite elegantly by using "<", but you can not handle the implicit quantifiers. The formula must be true for all valid i and j. In fact, if N is the number of elements then in MATHS you would write:
    11. for all i:0..N, j:0..N, i<j ( array[i] > array[j] ).

      This ( and the first comment) makes my partly backed idea below less than half-baked. Back to the oven.

      2008-04-10 Thu Apr 10 19:04 Beautiful Code

      I've seen several discussions of beautiful code in recent blogs and articles. Here is one that casts doubt on the whole idea of a piece of code being beautiful:

      Wirfs-Brock07b

      1. Rebecca J Wirfs-Brock
      2. Does Beautiful code imply Beautiful design?
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp18-20
      4. =ESSAY BEAUTY CODE DESIGN STYLE LANGUAGE REFACTOR habitabillity
      5. Can one determine the beauty of a piece of code without knowing it's context?
      6. Shouldn't identifiers have meaningful names?
      7. Shouldn't there be some comments giving a clue as to purpose and design of the code?

      This article mentions the need for meaningful identifiers. And I was reminded of the reaction of a business student doing a first C++ class last quarter. In my code I tend to use i, j, k in for loops as subscripts. And x and y for real numbers... The student thought it too much like algebra. Which was precisely the comment made 30 years ago by a colleague who used US (Universal Subscript) where I used i. And then that lead me to think about a research student sitting in the same office as I did who used ZIET in his code... but he was German. So I wonder if you can actually chose good names without knowing the background of your reader!

      Worse you can lie when you choose names.

      I've seen a very cogent article [Zokaites02] that argued that one wants code to be self-explanatory -- if a comment is needed then the code needs to be refactored: better variable names, better method/function names, ... Mainly because comments can not be checked. This does discuss the possible use of a formal language for comments (for example Ada had the Anna language) and tools for model checking.

      It is also ignores the problem of expressing purpose: what is this code trying to do. One modern way to to document the purpose of code is to document the tests that is must pass -- ideally in a form that enables the tsting. And indeed this is one of the benefits of Test Driven Development claimed in [Beck01] however tests can only indicate the generl rules governing the purpose and design of code.

      The traditional solution [Floyd67a] [Botting75] has been to include Invariant Assertions in the code. The Wikipedia has a short and pretty accurate introduction [ Assertion (computing) ] to the topic. And that lead me to an amazing survey of the past and present of the use of assertions to make code better:

      Hoare01

      1. C A R Hoare
      2. Assertions: a personal perspective (Draft)
      3. Microsoft Research Ltd., Cambridge, England (6 Jun 2001) .See http://research.microsoft.com/~thoare/6Jun_assertions_personal_perspective.htm
      4. =HISTORY ESSAY CODE ASSERTIONS INVARIANTS ALGOL60 ELLIOTT CSP Z
      5. Assertions as annotating designs.
      6. Assertions and axioms defining semantics.
      7. Assertions as an executable part of code.

      A Partly Baked Idea -- Assertions in C++ and C

      Perhaps we could use the 'assert' function inside a comment to record formal assertions:
      1. Invariants 
         	//inv assert(....);
      2. Pre and post conditions/contracts [Meyer00] 
         	//pre assert(....);
         	//post assert(....);
      3. Specification and safety conditions [Maddux96] 
         	//safe assert(....);
         	//spec assert(....);
      We could easily make this executable to check our reasoning. but our real purpose is explain the code. I'll see if I can construct an example, and an explanation of why the 'assert' still doesn't provide a powerful enough language for assertions.

      2008-04-09 Wed Apr 9 20:04 Good intentions and Proofs in Practice

      I had intended to make an entry on this blog every week day during my sabbatical. But yesterday night the coughs came back and I spent the morning trying to sleep.

      But I did make a small change in the previous post in the proof of the lemma.

      Now this is quite typical -- you work for several days on preparing an accurate and rigorous proof only to find the next day a trivial error in it.

      But this is very much the pattern described in [Lakatos76] [ maths/logic_20_Proofs100.html#Proofs and Refutations ] however with a longer timescale: mathematics progresses by the correction of false proofs and the discovery of mistakes and false assumptions in apparently good work.

      A very similar pattern is described in

      OShea07

      1. Donald O'Shea
      2. The Poincare Conjecture: In Search of the Shape of the Universe
      3. Walker & Co NY NY 2007 ISBN 0-8027-1654-7
      4. =POPULARIZATION MATHEMATICS TOPOLOGY GEOMETRY PROOFS REFUTATIONS
      5. Compare to similar process noted by [Lakatos76]
      6. Need for peer review of mathematical results.
      7. Use of presentations.
      8. Mathematics as a social process. [DeMilloLiptonPerlis79]
      9. Rise of www.arXive.com.

      The other observation coming from this is that in every mathematical field of any interest there are always a large number of "Low lieing fruit" that are easily proved results. T