.Open RJBottings Web Log 2009
See
.See Invitation to Contribute
below.
. 2009-11-18 Wed Nov 18 15:25 Thanks for the typos
Dr. Christopher Landauer is enrolled in the elite list of people who have sent
me lists of errors to correct. This has helped me fix a
dozen typographical mistakes in
.See ./samples/ada.syntax.html
my syntx of the Ada Programming language.
. 2009-11-17 Tue Nov 17 17:57 Still Waiting for the Engineering of software
Mary Shaw was invited to look backwards and write an update
of here 1990 article on how professional engineering might arise with software.
Interesting history and some speculation about the future.
.Open ShawM09
Mary Shaw (CMU)
Continuing prospects for an Engineering Discipline of Software
IEEE Software magazine V26n6(Nov/Dec 2009)pp64-67
=ESSAY ENGINEERING SOFTWARE
Review of
.See [ShawM90]
"Prospects for an Engineering Discipline of software"
History of programming practices by decade originally 1960-1990 now extended to 2010.
Three new trends: abstract architecture (1990+-5), Democratization on the Internet (2000+-5),
Vanishing system boundaries.
Notes conflict between high-ceremony (CMM) vs agile and open-source processes.
Production and Craft ~~> Commercial, Commercial and Science ~~> Engineering.
Need for documented for routine ways to solve precedented problems.
Being satisfied by open documents on the web.
More specialisms are emerging.
.Close
. 2009-11-16 Mon Nov 16 13:01 Bad comments are found in bad code
Here
.See http://www.itworld.com/development/84780/if-comments-are-ugly-code-ugly
is a nice blog-item by Esther Schindler (November 15th 2009). It is something
I believe.... but I find it difficult to practice, as you know if you
read my blog regularly.
. 2009-11-12 Thu Nov 12 20:19 More on Agile and formal or mathematical methods
The latest issue of IEEE Computer Volume 42 Number 2 has a couple of letters and an article that argue against $BlackEtAl09 (next below)
and their attempt to mix formal methods with agile processes. William Adams on page 6 has
a letter restating the traditional theory that agile methods don't work on big projects and
formal methods are needed instead including a dose of waterfall planning. It is
not clear what methods he considers to be `formal`. His `real world`
has fixed requirements and budgets.... He is rebutted by the original
authors who quote some large, real projects that used agile methods with
success.
On page 7 Harry Gilbert claims to be a competetn programmer (and author of "Practical Pascal")
who does not do mathematics and so is blocked from computer science. Modern CS curricullum's
have less mathematical BA degrees... But more disturbing is Neville Holmes's rationale
for defining a non-algebraic tool for doing exact calculations because
there is a decline in mathematical skills. He proposes a functional scheme called the
`formulator' that I will report on later...
Meanwhile I am worrying about the possible futures with less mathematics in it.
. 2009-11-10 Tue Nov 10 19:32 Mixing agile with other methods
Real programmers don't like documentation but it does have value, see
$Selic09
below. Mathematics is a shorthand. It could reduce the amount of upfront documentation.
Perhaps [$BlackEtAl09]
it can be used in an agile way.
This led me (years ago) to invent an accronym:
AMAS::="Agile Mathematics Applied in Software development".
Also this second reference has some links to some tools and methods.
.Open BlackEtAl09
Sue Black & Paul P Boca & Jonathan P Bowen & Jason Gorman & Mike Hinchey
Formal versus agile: Survival of the Fittest
IEEE Computer Magazine V42n9(Sep 2009)pp37-45
=SURVEY RESEARCH AGILE FORMAL MODEL CHECKING Alloy X-Machines SMV CTL KeY
SEEFM2003::acronym="First South East Europe Workshop on formal methods",
.See http://delab.csd.auth.gr/~bci1/SEEFM03
XFM::="eXtreme Formal Modeling",
.See http://doi.acm.org/10.1145/1109118.1109120
XFun::= http://delab.csd.auth.gr/~bci1/SEEFM03/seefm03_03.pdf
(PDF), Unified Process with X-Machines verified by model checking.
KeY::method=http://i12www.iti.uni-karlsruhe.de/~key/keysymposium07/slides/haehnle-agile.pdf
Extend TDD by including static-analysis and theorem-proving tools to extend coverage. Example 97% of assertions checked automatically in SPARKAda toolset.
How do formal requirements handle creep?
Machine checked refactoring?
Parallelism: FDR and Coverity
.See http://www.coverity.com/
Speed and availability of tools:
.Key Rodin
.See http://rodin.cs.ncl.ac.uk/
and
.Key Deploy
.See http://www.deploy-project.eu/
projects. Praxis
.See http://www.praxis-his.com/
has
.Key SPARK toolset
as open source.
Formal methods lite -- use math at the right times in a project.
Argues that the total cost (effort) for a project is less with up front work getting requirements etc. right.
Agility is not about speed but maneuverability. Producing the highest quality in each iteration/increment. Compared to RAD.
Controlling the technical debt.
No real conflict... given some mutual understanding.
.Close
.Open Selic09
Bran Selic
Agile documentation anyone?
IEEE Software Magazine V26n6(Nov/Dec 2009)pp11-12
=ESSAY DOCUMENTATION vs CODE ARCHITECTURE
Documentation has no value to the producer but can be valuable to others.
Code does not provide Rationales and Architectual specifications.
Documentation must be closer to the user's domain than the code is.
.Close
. 2009-11-10 Tue Nov 10 12:27 Quick addition
Added some thoughts
.See [Maiden90b]
on the certification of requirements engineers and updated, as
a result
.See [CurtisKrasnerIscoe88]
and
.See [Paech08]
as well. Maiden endorses the "one size does not fit all" philosophy and
the importance of domain knowledge to a project.
. 2009-11-06 Fri Nov 6 11:45 A couple of quick ones
The Communications of ACM has a souple of good survey articles in its September
issue. The first is a comparison of distributed vs centralized version control
systems -- see
.See [OSullivan09]
in my bibliography. The second is a history and status report on the P=NP
problem. See
.See [Fortnow09]
for citations etc.
. 2009-11-05 Thu Nov 5 19:51 A Traditional Formal Method
The following paper summarizes a lot of the thinking from the 1970s thru to the 1990s. $Abrial09 points out the role of formality when determining requirements but ignores the common need to discover requirements by implementing software.
.Open Abrial09
Jean-Raymond Abrial
Faultless Systems: Yes we can
IEEE Computer Magazine V42n9(Sep 2009)pp30-36
=ADVERT FORMAL SYSTEMS REQUIREMENTS B Event-B CORRECTNESS MODEL PROOF SIMULATION REFINEMENT PATTERNS MATHEMATICS TOOL Rodin
assumes waterfall is necessary.
process=requirements; model; code.
requirements are a mixture of informal explanations and form definitions and proofs etc.
Use coupled discrete state transition systems. And animation. Prove invariants.
Need tools to prove thousands of changing propositions.
Validate the problem as a system in an environment not just the software.
Problem with not enough discrete mathematics in education.
Problem with technology transfer.
Link
.See http://www.event-b.org
.Close
. 2009-11-05 Thu Nov 5 14:09 Chance of Extra Credit
.See ./seminar/20091112BrokenCirclesStudios.txt
(November 12th 10-11:50 JB360).
. 2009-11-03 Tue Nov 3 20:16 Formal Methods and Requirements
This is the first of a series of postings on what have been called "Formal Methods" which I interpret to mean
techniques that apply mathematics and logic in the development of software. The first ($JaspanEtAl09)
reports on a discussion of formal methods and whether the myths still hold. This reviews an article from 1990.
Oddly it does not refer to either
.See [BowenHinchey95b]
which added seven more myths to the original list
or to
.See [BowenHinchey06]
which stated 10 commandments. But it noted that formal methods have expanded beyond
proving that a specification is met by a program. They now are commonly used in requirements engineering.
Which takes me to the next two papers that report experiences with formal methods for requirements. The first
($DesaiChopraSingh09) describes in excruciating detail the Amoeba method applied to two large (if artificial)
projects. Amoeba helps work out requirements
for connecting disparate actors together. The other ($NuseibehHaleyFoster09) describes the development of a
secure Air Traffic Control system despite possible malice and malfeasance.
.Open JaspanEtAl09
Ciera Jaspan & Michael Keeling & Larry Maccherone & Gabriel L. Zenarosa & Mary Shaw
Software mythbusters explore formal methods
IEEE Software Magazine V26n6(Nov/Dec 2009)pp60-63
=REPORT DISCUSSION EXPERIENCE MYTHS FORMAL METHODS AGILE FSM LOGIC MATHEMATICS
Reference a list
.See [Hall90]
of seven myths
Formal methods are richer than in 1990.
They are now used in requirements to get precision and understanding.
They are embedded in tools and environments reducing the need for mathematical maturity.
They enable communication and evolution and so support agility.
An FSM model for understanding lead to better code.
Must match the method to the problem cost-effectively.
Formal methods are being domesticated.
.Close
.Open DesaiChopraSingh09
Nirmilt Desai & Amit K Chopra & Munindar P Singh
Amoeba: A methodology for modeling and evolving cross-organizational business processes
ACM Transactions on Software Engineering and Methodology V19n2(Oct 2009)pp6.1-45
=ADVERT 2 CASE STUDIES Amoeba REQUIREMENTS METHOD LOGIC COMMITMENTS SCENARIOS SEQUENCE CHARTS AXIOMS EVOLUTION AGENTS SERVICES ORCHESTRATION CHOREOGRAPHY
Amoeba::Method= iterate( roles and interactions; contractual relationships -> Commitments; message meanings->create and manipulate commitments; Constraints; compose protocols -> process model).
Uses the idea of
.Key business protocols
as modules. These have messages and resulting changes in the commitments between components.
For example `CC(VENDOR, BUYER, pay(price), ship(goods))` would result from a VENDOR sending a
`quotation(price, goods)` message to a BUYER.
Theory
.See [DesaiEtal05]
.Close
.Open NuseibehHaleyFoster09
Bashar Nuseibeh & Charles B Haley & Craig Foster
Securing the Skies: In Requirements we Trust
IEEE Computer Magazine V42n9(Sep 2009)pp64-72
=EXPERIENCE ITERATIVE FORMAL SECURITY REQUIREMENTS ANALYSIS ATC TOULMIN ARGUMENT PROOF RISKS SYSTEM ARCHITECTURE STAKEHOLDERS EXPERTS
Advice: Exploit the experts. Exploit nonexperts. Scope the problems. Iterate to mitigate. Formalize but also argue informally.
Used
.See [Jackson01]
for architectural models. Used Toulmin to structure arguments and rebuttals.
Security requirements derived from protecting assets and challenging assumptions exposed by form proofs.
Outer arguments on cover hidden assumptions, inner arguments rebut assumptions and lead to mitigation strategies or revisions of requirements.
.Close
. 2009-10-29 Thu Oct 29 19:40 Sociology trumps technology in solving problems
.Open WhitworthLiu09
Brian Whitworth & Tong Liu
Channel E-Mail: A Sociotechnical response to spam
IEEE Computer Magazine V42n7(Jul 2009)pp63-71
=DEMO PROBLEM SYSTEMS PEOPLE SOCIAL TECHNOLOGY EMAIL SPAM
Shows that some problems are not solvable by technology alone.
Sociology plays a part in a real solution.
.Close
. 2009-10-27 Tue Oct 27 19:55 Modeling tasks and Integration Requirements
It is windy here in San Bernardino again.
lights are flickering....
Meanwhile, here are a couple of proposed techniques to use when developing software. First, $Rich09, shows how to develop user interfaces by first modeling the tasks the users need to carry out.
Then $Bolloju09 gives a tested (in a graduate course) notation and method for specifying how different systems must behave and be connected to achieve an integrated system.
.Open Rich09
Charles Rich
Building Task-Based User Interfaces with ANSI/CEA-2018
IEEE Computer Magazine V42n8(Aug 2009)pp20-27
=ADVERT STANDARD USER TASK XML JavaScript
First model the task.
Use an engine to guide the user.
Questions asked by user during a task. What next? How do I? When should I? Why did you do that? What is needed? What is output? Did it work?
Answers encoded into XML+JavaScript.
Tools aid the writing of the XML and in it's interpretation.
Property files.
No reference to scenarios or use-cases!
.Close
.Open Bolloju09
Narasimha Bolloju
Conceptual Modeling of Systems Integration Requirements
IEEE Software Magazine V25n6(Sep/Oct 2000)pp66-74
=EXPERIMENT METHOD NOTATION SYSTEM REQUIREMENTS SERVICES
Graph: Nodes represent subsystems and transformations. Arcs labelled with conditions and messages.
Transformations: BATCH and SPLIT, AGGREGATE and DISTRIBUTE, X(translation).
Uses <....> to indicate refined subsystem.
Tested an 78 graduate students who found it usable.
.Close
. 2009-10-21 Wed Oct 21 15:22 UML 3.0 or 2.4
Jordi Cabot has posted the good news on the UML Forum
.See http://groups.google.com/group/umlforum/
that the OMG is not going for UML 3.0 just yet. instead they
may try to simplify the language. Jordi has this link
.See http://blogs.msdn.com/stevecook/archive/2009/09/28/reflections-on-the-omg-meeting-in-san-antonio.aspx
for details on Steve Cook's WebLog.
. 2009-10-20 Tue Oct 20 20:13 The Now looks like the Past
It looks like we still have bugs in radiation machines
.See http://www.wired.com/threatlevel/2009/10/gamma/
(Wired Oct 2009). We also still have a wide range of practices and their consequent qualities
($CusumanoEtAl09). Finally we still don't evaluate projects and process improvements in terms
of financial costs and benefits ($Solingen09).
.Open CusumanoMaccormackKemererCrandall09
Michael A Cusumano & Alan MacCormack & Chris F Kemerer & William Crandall
Critical Decisions in Software Development: Updating the State of the Practice
IEEE Software Magazine V25n6(Sep/Oct 2000)pp84-87
=SURVEY PROCESS MANAGEMENT waterfall vs agile ONESIZE QUALITIES
Revisits
.See [CusumanoMaccormackKemererCrandall03]
showing a wide range of processes and qualities.
One size does not fit all.
Must choose a process to fit the situation.
Distributed development gives rise to a more modular structure and needs special learning to pay off.
A rigid process can give higher quality but at risk of loosing innovative products.
.Close
.Open Solingen09
Rini van Soligen
A Follow-Up Reflection on Software Process Improvement ROI
IEEE Software Magazine V25n6(Sep/Oct 2000)pp77-79
=REVIEW PROCESS IMPROVEMENT COST BENEFIT ECONOMICS SPI ROI SIX SIGMA
refers to
.See [Solingen04]
Hardly any published work on the monetary value of improvements.
Need to think in economic terms about projects.
Money should win management commitment.
Should adopt Six Sigma. No evidence.
.Close
. 2009-10-19 Mon Oct 19 15:14 Bonus -- Programmers at work
Jeff Atwood
.See http://www.codinghorror.com/blog/archives/001305.html
is reccommending a couple of books which are well inside the
scope of this blog. He also mentions a thord.
I'd love to have time to read them and inwardly digest them
before blogging them here. But I don't think I will have time for the next 10 months
or so. Here are the citations with an invitation to send me your comments.
.Open Seibel09
Peter Seibel
Coders at Work
Apress 2009 ISBN 1430219483
.See http://www.amazon.com/dp/1430219483
=UNREAD =INTERVIEWS PROGRAMMERS PEOPLE CODING TECHNICAL
Please send me your comments
.See ./contribute.html
to see them here.
.Close
.Open Lammers89
Susan Lammers
Programmers at Work: Interviews With 19 Programmers Who Shaped the Computer Industry
Tempus Books 1989 ISBN 1556152116
.See http://www.amazon.com/dp/1556152116
=UNREAD =INTERVIEWS PROGRAMMERS PEOPLE CODING TECHNICAL
Parts online at
.See http://programmersatwork.wordpress.com/
Please send me your comments
.See ./contribute.html
to see them here.
.Close
.Open BiancuzziWarden09
Federico Biancuzzi & Shane Warden
Masterminds of Programming: Conversations with the Creators of Major Programming Languages
O'Reilly Media 2009 ISBN 0596515170
=UNREAD =INTERVIEWS PROGRAMMERS PEOPLE CODING TECHNICAL LANGUAGES CSCI320
Please send me your comments
.See ./contribute.html
to see them here.
.Close
. 2009-10-15 Thu Oct 15 20:51 Spending Money
A couple of pieces on economics -- firstly on what people are spending IT money on and the
other on why we pay what we do for things.
.Open ChaEtAl09
Hoon S Cha & David E Pingry & Matt E Thatcher
What Determines IT Spending Priorities
Commun ACM V52n8(Aug 2009)pp105-110
.See http://doi.acm.org/10.1145/1536616.1536644
(Virtual Extension)
=POLL 2006 IT SPENDING ECONOMICS PROJECT REASONS CS372
Abstract
.Box
"Based on survey results from 1,495 business leaders we have derived some
important insights into how factors such as industry type, firm size, state
location, and past IT performance affect a firm's allocation of IT
expenditures across business functions. Specifically, the survey data shows
that the highest IT spending priorities of the respondents are in the areas
of administration and production and distribution while the lowest
priorities are in the areas of R&D and security."
.Close.Box
.Close
.Open Ariely09
Dan Ariely
Predictably Irrational: The Hidden Forces That Shape Our Decisions
Harper Collins NY NY 2009
=UNREAD =POPULARIZATION =EXPERIMENTS PEOPLE PSYCHOLOGY FALLACIES MARKETING BEHAVIORAL ECONOMICS
Web site
.See http://www.predictablyirrational.com/
We are all a lot less rational than standard economics assumes.
Online Outline
.See http://bookoutlines.pbworks.com/Predictably-Irrational
Reviewers are welcomed at
.See ./contribute.html
A third option can makes us choose the worse alternative. cf Arrow's Theorem.
Price is often determined by habit not supply and demand.
The word "Free" helps us spend more money.
We will buy things or do things because we think others will buy/do it -- norms.
Arousal changes things.
Procrastination -- teachers should impose deadlines.
We overprice what we have -- cognitive dissonance strikes again.
We will waste time and money to keep our options open.
Expectations color our perceptions. Stereotypes!
Higher cost makes medicine etc. work better.
We don't like to cheat but still cheat a little bit.
We are more honest about cash than things.
Making public choices can make you choose differently (in the USA) or in conformity(Hong Kong).
(dick)|- Maslow!
.Close
. 2009-10-14 Wed Oct 14 10:52 Power cuts vs Grades
It was raining in San Bernardino yesterday. This is a rare event.
Indeed I am convinced that people in Southern California do not understand rain
and tend to ignore it -- driving, designing roofs, etc. ... Hence my favorite
movie "Singing in the Rain".
Whatever... the power became flakey. A brief cut 9am yesterday knocked out
out our DSL box and so my wife learned the dark art of rebooting it until it
worked. When I got home.... I spent half an hour checking the network out, and another 30 minutes downloading and installing Microsofts mega-pack
of updates.... and posted the entry below.
I was just deciding whether to grade or to watch a DVD when the power went out.
Total darkness..... Emergency lighting turned on (well 80% of it). The
Elctricity company robot was told about it. Candles
were found. Friends and nieghbors met and shared data.... And we collapsed into
bed with no grading done.
The power was back at 11:45 and I checked things out. I decided to
not reboot the LAN until I knew the power was stable.... back to
sleep.
Got all systems operational this morning again.
ANd that is why grades are not posted yet.
. 2009-10-13 Tue Oct 13 20:05 Codefest
First we have an article ($Spinellis09b) listing all the things you can do
to increase job security by producing incomprehensible code. Then Kode
Vicious
.See Neville-Neil09a
explains how an organization can recover from
sacking somebody who does this. The same prescription (code reviews) can
stop the problem in the first case. Then we have
($BrandtEtAl09) who present a case (exploratory prototyping)where badly
written code is the norm. Finally, under the heading of `why code anyway`
we have a book ($MellorBalcer02) about making the UML into a complete and
executable language. So who needs code? And who said that a picture was
worth a thousand words?
.Open Spinellis09b
Diomedis Spinellis
Job security
IEEE Software Magazine V25n6(Sep/Oct 2009)pp14-15
=JOKE HOWTO BAD CODE
Excellent survey of things not to do if you want bad code.
.Close
.Open Neville-Neil09a
George V Neville-Neil (Kode Vicious)
Kode reviews 101
Commun ACM V52n10(Oct 2009)pp28-29
.See http://doi.acm.org/10.1145/1562746.1562778
=ESSAY CODE REVIEWS WHY HOWTO TEAM
How to learn about others code.
Must be prepared for.
Piece of the code assigned to each for study.
Do not schedule after just lunch.
Provide coffee+food
Keep the focus. Do much more than nitpicking the spelling and syntax.
Take notes. And afterwards distribute.
Follow up.
Use a tool to track code reviews and followup work. Example Rietveld.
.Close
.Open BrandtEtAl09
Joel Brandt & Philip J Guo & Joel Lewenstein & Scott R Klemmer & Mira Dontcheva
Opportunistic Programming: Writing code to prototype, ideat, and discover
IEEE Software Magazine V25n6(Sep/Oct 2000)pp18-24
=EXPERIMENT BRICOLLAGE POSTMODERN PROTOTYPING GLUE WWW/NET d.mix
Principles for rapid prototyping
.List
Glue together existing high-level components.
Add functionality via Copy-paste from the web.
Iterate rapidly.
Consider code to be impermanent.
Expect and prepare for debugging.
Use many languages.
Don't expect good code.
Need different version control.
.Close.List
.Close
.Open MellorBalcer02
Stephen J Mellor & Marc J Balcer
Executable UML: A Foundation for Model-driven Architecture (2nd Edition)
Addison Wesley 2002 ISBN 0-201-74804-5
.See http://my.safaribooksonline.com/0201748045
=HOWTO =ADVERT DAD DDD UML PROFILE xUML MDA DOMAIN BRIDGE USECASE NONSEQUENTIAL OBJECT_ORIENTED DAD LIFECYCLES TOOLS?
Updates the ShlaerMellor Methods to use the UML.
.See [ShlaerMellor88]
.See [ShlaerMellor89]
.See [ShlaerMellor92]
.See [ShlaerMellor97]
to use the UML.
Comments wanted
.Hole
.Close
. 2009-10-12 Mon Oct 12 15:01 Contribution on Pompeii
My name is Katie, I am a history major and was doing some research on Pompeii when I came across your page. I noticed that on
.See http://www.csci.csusb.edu/dick/info4.html#Pompeii
you link to http://jefferson.village.virginia.edu/pompeii which seems to be broken. If you are interested in a replacement, I found a site that has some great information and resources on Pompeii and its destruction that would make a nice addition to your page:
.See http://www.travelinsurancereview.net/Travel-Facts/destruction-of-pompeii.html
http://www.travelinsurancereview.net/Travel-Facts/destruction-of-pompeii.html
. 2009-10-11 Sun Oct 11 09:33 Good Concert Last Night
The 81st season of the San Bernardino Symphony
.See ./symphony.html
started last night with an excellent evening of
entertainment.
. 2009-10-08 Thu Oct 8 20:47 Hard problems and practical solutions
Apparently the existence of problems that (apparently) can not be solved in polynomial time, even though the solutions can be checked in polynomial time is attracting some attention due to the following survey. Following it is an example of this kind of problem and the best practical algorithms to solve it.
.Open Fortnow09
Lance Fortnow
The status of the P versus NP problem.
Commun ACM V52n9(Sep 2009)pp78-86
.See http://doi.acm.org/10.1145/1562164.1562186
=SURVEY THEORY PERFORMANCE COMPLEXITY NP NP-HARD NP-COMPLETE P=NP?
"What we would gain from P = NP will make the whole Internet look like a footnote in history."
"Since all the NP-complete optimization problems become easy, everything will be much more efficient. Transportation of all forms will be scheduled optimally to move people and goods around quicker and cheaper. Manufacturers can improve their production to increase speed and create less waste."
probably P<>NP. But no proof yet.
Quantum computers probably won't do it.
For practice see
.See [MalikZhang09]
.Close
.Open MalikZhang09
Sharad Malik & Lintao Zhang
Boolean Satisfiabiliy -- From Theoretical Hardness to Practical Success
Commun ACM V52n8(Aug 2009)pp76-82
.See http://doi.acm.org/10.1145/1536616.1536637
=SURVEY THEORY BIGO EXAMPLE PRACTICE CNF DPLL ALGORITHMS PERFORMANCE BENCHMARKS NP
Theory calculates the worst case performance.
SAT solvers rely on the typical case (in a given domain) is not the worst case.
The Davis Putnam Logeman Loveland algorithm with optimizations gives a usable tool.
See
.See [Fortnow09]
for the theory.
.Close
. 2009-10-06 Tue Oct 6 19:56 Empirical research in Agile methods
As noted previously, agile processes are not a new idea but they are growing in popularity. Here is a survey of the published literature that provides scientific evidence of the good and bad properties of these methods. For more information search my bibliography for the tag "AGILE".
.Open DybaDingsoyr09
Tore Dyba & Torgeir Dingspoyr
What do we know about agile software development
IEEE Software Magazine V25n6(Sep/Oct 2009)pp6-9
=SURVEY EMPIRICAL RESEARCH AGILE XP
Agile processes can improve customer satisfaction, productivity and job satisfaction.
They can be difficult to introduce into a large organization.
Being the onsite customer is stressful and hard to sustain.
A Team needs a strong focus on both the interpersonal and the team goals.
Skill and experience helps.
May not be the best approach for large projects.
Need more research.
.Close
. 2009-10-06 Tue Oct 6 10:48 Bonus Blog
Frank P. the web master of Web Talk
.See http://www.webtlk.com/
contributed his own blog as a back link ... good for news about hardware and software. It is permanently embedded at
.See ./samples/people.html#Blogs
. 2009-10-01 Thu Oct 1 20:17 Better bookmarks for Eclipse
The following describes an extension of Eclipse bookmarks and its testing on some
live projects.
.Open StoreyEtAl09
Margaret-Anne Storey & Jody Ryall & Janice Singer & Dei Myers & Li-Te Cheng & Michael Muller
How Software developers use tagging to support reminding and refinding
IEEE Trans Software Engineering V35n4(Jul/Aug 2009)pp470-483
=CASESTUDIES TOOL FEATURE HIERARCHY COMMENTS TECHNICAL Java Eclipse TagSEA
Notes that Eclipse user don't use the bookmark feature very often.
Provided a light weight plugin to Eclipse to organize the markup of code (in comments) into an easy to access hierarchy.
Some evidence that this approach is better than book marking at setting reminders and finding things later.
.Close
. 2009-09-29 Tue Sep 29 20:14 About Code Quality
First evidence that the quality of Open Source code is improving, then a tool that helps you improve the quality of code by refactoring.
.Open Kanaracus09
Chris Kanaracus
Study Shows improvements in quality of open source code
Info world (Sep 23 2009)
.See http://www.infoworld.com/d/applications/study-shows-improvements-in-quality-open-source-code-950
=REPORT QUALITY METRICS STATISTICS OPEN SOURCE
"In survey commissioned by Department of Homeland Security, Samba, tor, OpenPAM, and Ruby granted top-level status for resolving defects"
Data collected at
.See http://scan.coverity.com/about.html
.Close
.Open TsantalisChatzigeorgiou09
Nikolaos Tsantalis & Alexander Chatzigeorgiou
Identification of move method refactoring opportunities
IEEE Trans Software Engineering V35n3(May/Jun 2009)pp347-367
=DEMO OBJECT ORIENTED REFACTORING CODE FEATURE ENVY SMELL METRICS Java TOOL ECLIPSE JDeodorant ALGORITHM JACCARD DISTANCE
JDeodorant::=http://www.jdeodorant.org/
, 2007.
.Close
. 2009-09-28 Mon Sep 28 13:01 Small Change in weekly schedule
I've decided to plan an earlier lunch. See
.See ./plan.html
for the new schedule.
. 2009-09-24 Thu Sep 24 19:18 For the weird languages file
Here are three references to weird languages: Boogie, Spec#, and Scratch -- all described or demoed on the web. To be more precise Boogie is a tool, Spec# is a specification language, and Scratch is a integrated Development environment for children to use on the "One Lap Top Per Child" system. Scratch also demonstrates an application of the Open Source principle of shared code -- even if the code has a heavy graphic component.
.Open Boogie09
Microsoft Research
Boogie -- The World's Best Program Verification System
Web site Aug 27th 2009
.See http://boogie.codeplex.com/
=ADVERT OPEN SOURCE VERIFIER SQA PROOF NONSEQUENTIAL TOOL #
"Boogie is a program verification system that produces verification conditions for programs written in an intermediate languagec (also named Boogie). The intermediate language is easy to target from source languages such as Spec#, C#, or even C."
.Close
.Open Specsharp00
Microsoft Research
Spec#
Web site Aug 28th 2009
.See http://research.microsoft.com/en-us/projects/specsharp
=ADVERT API SPECIFICATION CONTRACTS ASSERTION Eiffel
"Spec# is a formal language for API contracts (influenced by JML, AsmL, and Eiffel), which extends C# with constructs for non-null types, preconditions, postconditions, and object invariants. Spec# comes with a sound programming methodology that permits specification and reasoning about object invariants even in the presence of callbacks and multi-threading. Spec# is a research vehicle that has been used to explore specifications and the dynamic/static tools that make use of them."
.Close
.Open Scratch
MIT One Lap Top Per Child
Web site
.See http://scratch.mit.edu/
=DEMO IDE GRAPHIC LANGUAGE TOOL IDE
.Close
. 2009-09-24 Thu Sep 24 10:32 Bonus -- Online magazine on methods and tools
.Open MartinigEtAl
Martinig and Associates
Methods and Tools
Web page
.See http://www.methodsandtools.com/
=MAGAZINE =ADVERTS METHODS TOOLS PROCESSES NEWS LINKS JOKES
.Close
. 2009-09-22 Tue Sep 22 18:55 Prehistoric agility
This continues the series of early (rediscovered) publications describing or advocating what are now called agile processes. This $Schorr77 didn't have much impact because it was in IEEE Computing magazines "Open Channel" section which would publish anything from anyone (example me).
.Open Schorer77
Peter Schorer
The Open Channel
IEEE Computer magazine V10n8(Aug 1977)pp70-71
.See doi:10.1109/C-M.1977.217827
=EXPERIENCE ADVOCATE AGILE PROCESS USER ITERATIVE EVOLUTIONARY
Early description of an agile process.
A Question to ask in interaction design: What other information does a user need to know to use the new system?
.Close
. 2009-09-17 Thu Sep 17 20:11 Bugs Faults Defects and Failures
Lets talk about bugs. Now, informally we use `bug` to indicate bad behavior and the cause of that behavior.
So, First, a more precise terminology. A `failure` is a misbehavior in some software. A `fault` is the thing inside the software that is wrong. Another term for this is `defect`. The `defect density` is the number of defects in a piece of code divided by the size of the code. Now, when we look at the record of the development or maintenance of software we can not see the `faults` all we have a record of, is the fixes -- the changes made to attempt to fix the problem behavior.
$Hatton09 present some empirical data and a theory that says the defect density increases as the logarithm of the size. This means that the number of faults/defects in a piece of code of size `n` (lines of code) will have a number of defects proportional to
n* log(n)
$HamilPopstojanova09 provide data that normally a single failure needs fixes in several places.
Finally, $Schrock09, shows how to instrument Ajax code so that you can diagnose the bugs that emerge with a parallel system.
How else to debug a complex asynchronous system with minimal support from the platform like in AJAX?
.Open Hatton09
Les Hatton
Power-law distributions of component size in general software systems
IEEE Trans Software Engineering V35n4(Jul/Aug 2009)pp566-572
=EMPIRICAL STATISTICS CODE PACKAGES METRIC QUALITY MODULE SIZE DEFECTS STATISTICS Pareto
Theory and data show that defect density(defects/line) in a stable software system is proportional to the logarithm of the number of lines of code in that module.
However see
.See [Zhang08]
that claims a Weibull distribution is better.
.Close
.Open HamilPopstojanova09
Maggie Hamil & Katerina Goseva-Popstojanova
Common trends in fault and failure data
IEEE Trans Software Engineering V35n4(Jul/Aug 2009)pp484-496
=EMPIRICAL CASESTUDIES GCC NASA FAULTS = FIXES vs FAILURES
One failure is fixed by changes in more than one file 60% of the time. More than 2 files, 30% of the time.
Pareto principle: 20% of the files contain nearly 80% of the fixes in GCC. 47% of the files have 100% of the fixes.
NASA groups files into configuration items. 90% of failures lead to fixes within one item.
main reasons: 30% requirements, 25..30% coding, 15% data, ...
interactions cause problems.
.Close
.Open Schrock09
Eric Schrock
Debugging AJAX in Production
Commun ACM V52n5(May 2009)pp57-60
.See http://doi.acm.org/10.1145/1506409.1506423
=COMPARISON TOOLS BROWSERS java_script web/NET ASYNCHRONOUS
Write wrapper function that puts a try block arround calls!
Generate stack traces!
Etc.
.Close
. 2009-09-10 Thu Sep 10 17:53 Keeping systems simple by trusting people
It appears that Craig's List works despite breaking a lot of rules that
seem to be true. For example -- trusting people to make contributions with
little oversight. Quite different to Shirky's theory. Very like the difference
between "Theory X" and "Theory Y" as held by managers.
.Open Wolf09
Gary Wolf
Why Craigslist is such a mess
Wired V17n9(Aug 22 2009)
.See http://www.wired.com/entertainment/theweb/magazine/17-09/ff_craigslist
=REPORT CULTURE VISION WORLDVIEW PEOPLE DESIGN NET/WEB WEB2.0 CS372
Part of a set of articles on Craigslist
.See http://www.craigslist.org
that trace the design of a web-based system to the culture and vision of the enterprise that develops it.
Interviews with the founder
.Key Craig Newmark
and CEO/Chief Programmer
.Key Jim Buckmaster
about Craigslist.
See also "The Craigslist Credo: Unbrand, Demonetize, Uncompete"
.See http://www.wired.com/epicenter/2009/08/craigslist-credo-unbrand
and "Extreme Makeover: Craigslist Edition"
.See http://www.wired.com/entertainment/theweb/magazine/17-09/ff_craigslist_makeover
Quote
.Box
The axioms of this worldview are easy to state. "People are good and
trustworthy and generally just concerned with getting through the day,"
Newmark says. If most people are good and their needs are simple, all you
have to do to serve them well is build a minimal infrastructure allowing
them to get together and work things out for themselves. Any additional
features are almost certainly superfluous and could even be damaging.
.Close.Box
Compare
.See [Shirky03]
which assumes their are vandals who will wreck a web site.
.Close
. 2009-09-08 Tue Sep 8 19:36 On the Importance of distance
Before I get to the topic of the day (how distance doesn't matter any more) here is a word from
my sponsor
The following student project presentations will take place in JB 359 on Wednesday, Sept 9.
.Box
2:30 -- My Work on Mythic -- John Heim
3:00 -- Mythic -- Scott Young
3:30 -- Java Web Programming -- Eyob Zelke
4:00 -- Joomla Website -- Atip Siripat
4:30 -- Central Content Management System -- Raul Tabares
.Close.Box
Details in
.See ./seminar/
This afternoon I attended the Ph. D. thesis defense of one of our alumni -- Allan Knight. He set it up
using "GotoMeeting"/"GotoWebinar" and so I didn't have to leave home (in San Bernardino) to
go to Santa Barbara where the presentation took place. The whole thing went as planned. Details below in $Knight09. Which leads me to another example of the distance not being an obstacle.
.Open BirdEtAl09
Christian Bird & Nachiappan Nagappan & Premkumar Devanbu & Harald Gall & Brendan Murphy
Does Distributed Development Affect Software quality? An Empirical Case study of windows Vista
Commun ACM V52n8(Aug 2009)pp-
.See http://doi.acm.org/10.1145/1536616.1536639
=EMPIRICAL DISTRIBUTED PROCESS QUALITY MS Vista
Little evidence that having a team spread over two continents gives worse code than being in the same building.
Size of team does have an effect.
(dick)|- They did not check to see if the distributed team compensated for distance be special processes or tools.
.Close
.Open Knight09
Allan Knight
Facilitating the integration and impact measurement of technologies and media that augment learning environments
Thesis Defense CSci UCSB(Sep 8th 2009)
=THESIS WWW/NET EDUCATION TECHNOLOGY PEOPLE CULTURE DATA PERFORMANCE USER EVOLUTION
New devices, social media, and connectivity.
Turning up in classrooms. Opportunities or distractions in the classroom?
Stakeholders: teachers + students + researchers.
|-We can create computer systems that facilitate integration of the new into the learning as well as support research.
Four projects: DeCAF(event streams/producers/consumers), AutoCap(captioned audio), DataCafe(research data), PAIRwise(Plagiarism)
Lessons learned:
(DataCafe): relational database didn't scale. Flatter files fast enough. Interface difficult to use.
(PAIRwise): Evolved in purpose and implementation. Installation simplified. Initial version fragile.
.Close
. 2009-09-04 Fri Sep 4 07:11 location location location
I've just updated the next entry on the importance of locating data
in the right place when speed is important.
. 2009-09-03 Thu Sep 3 17:11 On the Persistence of Memory Performance Issues
This blog is about linking things that I've known about for decades to the latest and newest publications.
One persistent issue is how fast you can get access to data in a computer system and
the
.Key Physical Design of Databases.
Back in the late 1970's I taught the SSADM method in England (
.See [DownsClareCoe8792]
.See [Hares90]
.See [RobinsonBerrisford94]
) and we had a specific step to fit the logical design (normalized and relational) to (1)
the quirks of the database management system and then to make sure that the system was
fast enough. You might think that these issues would go away as disks became larger and faster.
But no! In
.See [PechuraShoefler83]
we have a paper that gives formulas for calculating the times it takes to read and write data
to disk -- prime rule: sequential access is still faster than random access. I used their formulas,
in
.See [Botting88]
to disprove some classic Big-O results taught in data structures classes. For example,
the time read all the data in a large disk file is not O(`n`) but O(`n`^2) for
large values of `n`!
In 1993, Jim Bentley
.See [Bentley93]
demonstrated the power and technique of do-it-yourself caches. Then we have, in 2001,
.See [Armstrong01]
on optimizing data warehouses -- and making the same points. By 2004,
.See [Alsaadi04]
used UML to denormalize data to speed up a program.
Last year
.See [KunkleCooperman08]
demonstrated solving Rubik's Cube using a cluster of disks to simulate
a very large Random Access Memory,
and concluded that you still had to avoid random access by using sorts
and caching.
For 30 years the same lesson: the physical location of data is a vital
component for determining performance.
All that has changed is the size of the data set that is needed to slow down the
software to the point of the users/stakeholders complaining.
In the August 2009 issue of the Communcations of the ACM we have the same
ideas -- resulting from experience with large data:
.Open Jacobs09
Adam Jacobs
The pathologies of big data
Commun ACM V52n8(Aug 2009)pp36-44
.See http://doi.acm.org/10.1145/1536616.1536632
=EXAMPLES DENORMALIZATION DATA OPTIMIZATION QUALITIES PERFORMANCE RDBMS
"It is easier to get data into a large database than get it out."
"To achieve acceptable performance[...] one must be willling to consider abandoning the purely relational database model."
"As dataset sizes grow, it becomes increasiingly important to exploit the efficiency of sequential acces[...]"
Problems with arbitrary limits.
Discusses distributed data bases.
Tradeoffs between fast access and duplicated data.
.Close
. 2009-09-02 Wed Sep 2 09:38 Two Reviews published -- CORBA and Montanari
I write reviews for "Computer Reviews" ($CR below). Two have been
published in hard copy. They have these two
.See [DeganoEtAl08]
.See [Henning08]
items in my bibliography.
. 2009-09-01 Tue Sep 1 19:17 More on Google MapReduce
Here is a more formal description on the MapReduce architecture...
which let me update the $MATHS definition in the item linked below:
.Open Lammel08
Ralf Lammel
Google's MapReduce programming Model -- revisited
Science of Computer Programming V70n1(Jan 2008)pp1-30 $CR 0908-0758
.See doi:10.1016/j.scico.2007.07.001
=THEORY MapReduce Haskell vs NONSEQUENTIAL MATHEMATICS
See first
.See [DeanGhemawat08]
.Close
. 2009-08-27 Thu Aug 27 18:50 Plans plus Cliches
I've spent the last week or so working up my plans for the coming quarter..... including a 10% reduction in
pay and work. I guess that it will be best if I shift the posting of items to this blog to Tuesday and Thursday
evenings. To start this new schedule: here is a light piece listing some management cliches and some
possible ripostes:
.Open Armour09a
Phillip G Armour
the business of software: the cliche defence
Commun ACM V52n7(Jul 2009)pp34-36
.See http://doi.acm.org/10.1145/1538788.1538802
=ESSAY PEOPLE MANAGERS BUZZ PHRASES
Do it right the first time. But.... Quote: "much of the business of software involves the discovery of what we are supposed to be doing".
Work smarter not harder.
Quality is the most important thing. But.... Which quality?
Our customers are the most important thing. But.... Which customers? What about future extensions and the people who work on them?
Our people are the most important thing. But... are they supported?
.Close
. 2009-08-26 Wed Aug 26 08:13 Business Links plus Respect in Software Development
First a note about my earliest web pages. They were set up, using HTML, using the
"Information superhighway" as a metaphor. They have a true miscellany of links. The were used in
my department's CSci127 course in the 1990s. A representative of `LexisNexis` has asked me to add
links to some of their services to businesses. This
.See ./info4.html#LexisNexis
is the result.
I am thinking it may be time to recode all of the "info" pages on this site to use the same
$MATHS language as this page. But I need to think about this change, and where the resulting
sample should end up. As always let me know what you think.
And now for something completely different.... Actually there is a link. My work on "info4" is not
very scientific, and it is not engineering. It is more a craft than anything else. Here is a contribution
on the long running discussion of whether programming is a form of engineering. More important is
the importance of `respect` as a driver of the qualities of software development
.Open Holmes09
Neville Holmes
Agility and respect
IEEE Computer Magazine V42n7(Jul 2009)pp100+98-99
=HISTORY ETHICS RESPECT PROGRAMMING vs ENGINEERING USER SERVICE NOT PROJECTS
Programming is a talent. Engineers should respect it. Programmming is a separate trade to engineering.
Development should focus on providing services to the enterprise not on projects.
A computer professional must be more than an expert on the technology.
Respect users by empowering them rather than programming them.
Also see keynote at ASWEC2009
.See http://eprints.edu.au/
(dick)|- Many programmers are craftspeople.
(dick)|- CASE tools did not change this, will model-driven tools?
.Close
. 2009-08-24 Mon Aug 24 10:30 How to be sure you have a good architecture -- Review it
Continuing the serires of Software Quality Control techniques, here we have a study
of the use of a well known technique -- technical reviews -- as applied to high level
design decisions that attempt to tackle requirements.
.Open BabarGorton09
Muhammad Ali Babar & Ian Gorton
Software Architecture Review: The State of Practice
IEEE Computer Magazine V42n7(Jul 2009)pp27-32
=POLL 235 ENTERPRISES SQA ARCHITECTURE MODELS INSPECTION WALKTHROUGH
Excellent summary of ways of ensuring design quality and addressing architectural concerns -- not all of them popular.
Common techniques: Scenarios, Experience, and prototyping. Less common: check lists, metrics, simulation, questionaires, mathematics
Documenting architectures: modeling notations, views, features, assumptions and constraints, ...
Inputs: (commonest first) requirements, descriptions, business drivers, standards, ...
Stakeholders -- various
.Close
. 2009-08-21 Fri Aug 21 08:21 A little lite mathematics
How do we get highly reliable software? One approach to improving reliability is to use mathematics
and logic in the design and review. There are a couple of examples posted previously -- a
compiler and a kernel for an operating system.
Here are a couple of books on mathematics that should be worth reading.
I've read $Stewart06 and wish that I had read it 40 years ago when I was a
`young mathematician`. Some of the chapters present a different view of proof to the one I have documented
on this site (
.See ./maths/logic_20_Proofs100.html
.See ./maths/logic_25_Proofs.html
). He argues that mathematical proof are stories. In this site I've documented something close to Lamport's
.See [Lamport95]
idea of a proof. My hope is that using hypertext we can get the benefits of both concepts. One
can be given a high-level story describing why something is true and embed in it links to the detailed steps
that link make up the formal (and checkable) proof.
The other book ($StepanovMcJones08 below) was on the math-thinking mailing
list and looks very interesting. It connects the kind of algebraic
properties that I've documented in this site to the construction of C++
code. I've ordered it and
hope to post a detailed opinion later.... meanwhile if you have read it, I would love to know what `you` think so I
can post it here and in my bibliography.
.Open Stewart06
Ian Stewart
Letters to a Young Mathematician
Basic Books Cambridge MA 2006 ISBN 0-465-08231=9
=ADVICE MATHEMATICS PROOFS
Suggests that mathematical proofs (not formal ones) are stories.
Good examples. Few formulas. Good advice. School...college...grad...faculty.
.Close
.Open StepanovMcJones08
Alexander Stepanov and Paul McJones
Elements of Programming
Addison-Wesley Professional 2009 ISBN 0-321-63537-X
.See http://www.elementsofprogramming.com/book.html
=UNREAD MATHEMATICS ABSTRACT ALGEBRAIC PROPERTIES FUNCTIONS PREDICATES TEMPLATES C++
Please send me any comment:
.Hole
.Close
. 2009-08-19 Wed Aug 19 14:53 Empirical Software Engineering
How can we get reliable information about a topic? There are a family of approaches that are called
.Key Empirical
which look to data gthered about the subject -- experiments, experiences, observations, statistical analysis, etc.
Empirical methods are closely associated with scientific methods. Sometimes you will meet people who
talk about `the scientific method` -- but if you check the history you will find several varieties.
The Wikipedia article
.See http://en.wikipedia.org/wiki/Scientific_method
on the history of the scientific method provides a very good survey of empirical methods. People are applying the to understanding software development.
I have been tagging the entries in my bibliography of software engineering -- nearly 5,000 of them now.
Here is a list of the tags from the most empirical (reliable) to the least:
.List
=EXPERIMENT -- an artificial set up designed to evaluate a specific set of hypothesis -- may not apply to real projects
=EXPERIENCE -- collected for real software development projects -- may be biased and/or unrepeatable
=OBSERVATION -- the researcher observes real projects -- may be biased and/or unrepeatable
=EMPIRICAL -- mixtures of the above
=SURVEY -- reports on the literature
=DEMO -- exhibits a working piece of software and the techniques and methods used to develop it
=POLL -- data collected from people, opinions, probably biased, ...
=THEORY -- Defines terms, postulates assumptions and proves results.
=ESSAY -- a balanced review of a topic or belief, but little in the way of data
=ANECDOTE -- writer appears to believe it but can't prove it
...
=ADVERT -- no proof or data, just arguments in favor of something, including papers about theses that quote results
proven in the thesis.
=POLEMIC -- strong arguments designed to make the author feel better.... but no data.
.Close.List
The first four are `empirical`.
Mark Doenhoefer's column (below) has
a comprehensive survey of web sites relevant to the empirical study of software development.
.Open Doernhoefer09b
Mark Doernhoefer
Surfing the net for software Engineering notes -- Empirical Software Engineering
ACM SIGSOFT Software Engineering Notes V34n3(Jul 2009)pp4-16
.See http://doi.acm.org/10.1145/1543405.1543409
(PDF)
=SURVEY =LINKS EMPIRICAL EXPERIMENTAL EXPERIENCE POLLS SURVEYS
Links to Journals, Groups, Courses, Conferences all concerned with gathering data and fitting theories to software development.
.Close
. 2009-08-17 Mon Aug 17 15:47 Inspections find defects
A recent experiment and observation of software inspections -- where a group gathers to
review code and look for particular problems in the code -- confirms an observation made in 2002
.See [Votta02]
that given modern software development tools most of the discovered defect decrease the quality of code
without damaging the functionallity.
.Open MantylaLassenius09
Mika V Mantyla & Casper Lassenius
What types of Defects are Really Discovered in Code Reviews
IEEE Trans Software Engineering V35n3(May/Jun 2009)pp430-448
=EMPIRICAL EXPERIMENT STUDENTS EXPERIENCE INDUSTRIAL INSPECTIONS SQA V&V DEFECT CLASSIFICATION EVOLUTION MAINTENANCE
Experiment done on students. Backed up with obsrvations of a company.
Inspections done after code has been run.
Most (60%) of discovered defects do not effect the functioning of software but might make the code harder to understand or change.
.Close
. 2009-08-14 Fri Aug 14 10:36 Program Proving is alive
Previously, I noted the existence of a proved compiler for a large subset of C.
Now comes news -- from Dr. Dobbs Update - 08/13/09 - Yes, 100% Verifiable Bug-Free Code Is Possible.
Jonathon Erickson reports that OK Labs
.See http://www.ok-labs.com/
have completed the verification of the corrrectness,
reliability, and security of their microkernel.
SOmething I did on a much smaller and simpler system nearly 40 years ago....
. 2009-08-12 Wed Aug 12 07:35 Mathematical Diversion republished in Book
Brian Hayes writes an excellent series of articles in "The American Scientist". Some of these have been republished in a book. This encourages me to add the article on the
common forms of data encoding to this bibliography.
.Open HayesB08
Brian Hayes
Group theory in the bedroom, and other mathematical diversions
Hill and Wang NY NY 2008 ISBN 0-8090-5219-9
=ARTICLES MATHEMATICS FUN CODING DATA INTRACTABILITY
Reprints
.List
The Easiest Hard Problem
.See [HayesB02]
Naming Names
.See [HayesB05]
and other good articles
.Close.List
.Close
.Open HayesB05
Brian Hayes
Naming Names
American Scientist V93 (Jan/Feb 2005)
and republished in
.See [HayesB08]
=ARTICLE CODING DATA
.List
Internet account IDs
NY Stock Exchange Ticker Symbols -- up to 3 Uppercase letters -- 26+26**2+26**3 possible
Universal Product Codes -- bar codes -- (
.Key UPC
)-- 12-digit until January 2005, and then 13-digits.
Global Traded Item Numbers (GTIN)
European Article Numbers (EAN)
Biological Species -- Two Latin-like words
The Chemical Elements -- One uppercase letter + option lower case letter.
(I had to program these while working for ICI in the 1960's)
Organic Chemicals -- Complex coding.
Internet Assigned Number Authority
.Key IANA
names for countries -- two ASCII letters
Radio Call Signs -- 3..4 Capital letters -- KVCR, KFROG, ...
Telephone numbers -- 10 digits (in the USA).
Social Security Numbers -- 9 digits in the USA
Airport codes (IATA) -- Three letters.
Names of Horses -- 2..18 characters ( letters plus space, period, and apostrophe).
.Close.List
.Close
. 2009-08-10 Mon Aug 10 10:55 Finnegans Wake
It is said that the party for the dead Finnegan was so good that the corpse got up to join in.
Here we have a couple of technologies/techniques
--
.Key Program Proving
and
.Key COBOL
-- that have been pronounced dead
many times, and yet keep showing signs of life.
.Open Atwood09b
Jeff Atwood
COBOL: Everywhere and Nowhere
Coding Horror (Aug 9 2009)
.See http://www.codinghorror.com/blog/archives/001294.html
=BLOG COBOL COBOL.NET EXAMPLE
.Close
.Open Leroy09
Xavier Leroy
Formal Verification of a realistic compiler
=DEMO PROGRAM PROVING COMPILER TOOLS CompCert Coq FORMAL SEMANTICS SEMANTIC PRESERVATION Mach Cminor
Commun ACM V52n7(Jul 2009)pp107-115
Shows that a useful subset of C can be compiled in real and efficient assembler code
by a compiler that has been proven correct -- with the proofs checked by tools.
.Close
. 2009-08-07 Fri Aug 7 15:39 Jackson Structured Programming and Structures Design
In the previous but one posting
.See Maibaum09
I mentioned `JSP` (a form of Data Directed Design or DDD) and
`JSD`(a form of Dynamic Analysis and Design or DAD) that dates back 3 decades.
Bo Sanden has has just published a personalized history of these methods which
explains these constructive methods. My own thoughts can be found in
.See ./monograph/
.See ./samples/methods.html#JSP
.See ./samples/methods.html#JSD
on this web site. Bo Sanden suggests that multithread programs need each thread to
track a realistic entity with a State Machine model.... something that slots
straight into the UML as a active object.
.Open Sanden09
Bo Sanden
Inspired software design early Jackson methods to thread architectures
SIGSOFT Softw. Eng. Notes V34n4 (Jul. 2009), pp1-6
.See http://doi.acm.org/10.1145/1543405.1543423
=HISTORY JACKSON METHODS DDD JSP DAD JSD ELM THREADS NON_SEQUENTIAL
cf ELM in
.See [Sanden03]
Students found JSP too difficult.
However, making each thread implement/follow a single entity's life history -- expressed as state diagram is OK with students.
.Close
. 2009-08-05 Wed Aug 5 11:21 Open Source and Crowd Source
The last 10 years have had a lot of studeis made of the open source
techniwue -- a technique dating back to software distributed in the early part
of the 20th century. It is clearly a viable technique to develop some kinds of software.
The later technology of `crowd sourcing` -- examples: wikipedia and YouTube --
has also been studied more recently -- tho' again the development of FAQ listings
on UseNet (AKA Google Groups) is an early incarnation. So first I will list some
significant papers and books on the topic and then a proposal for setting up an
effective open/crowd sourced project. This summarizes best practices into a
a process with principles and implications.
Bibliography
.Box
.See [Grier06b] (history)
1998
.See [Keuffel98]
1999
.See [O'Reilly99]
.See [Raymond99b]
2000
.See [MockusFieldingHerbsleb00]
2001
.See [FellerFitzgeraldHoek01]
2002
.See [DempseyWeissJoneGreenberg02]
.See [MockusFieldingHerbsleb02]
2003
.See [Glass03b]
.See [Shirky03]
2004
.See [Fitzgerald04]
.See [Lussier04]
.See [ThomasHunt04b]
2005
.See [Dinh-TrongBieman05]
.See [Weber05]
2006
.See [DamianiEtal06]
2007
.See [Nov07]
.See [Aberdour07]
.See [DuenasEtAl07]
.See [PetrenkoEtAl07]
2008
.See [Campbell-Kelly08]
.See [CapraFrancalanciMerio08]
.See [Huberman08]
.See [Laplante08]
.See [Shirky08]
2009
.See [Lawton09]
.Close.Box
.Open KazmanChen90
Rick Kazman & Hong-Mei Chen
the metropolis model -- a new logic for development of crowsourced systems
Commun ACM V52n7(Jul 2009)pp76-84
.See http://doi.acm.org/10.1145/1538788.1538808
=ESSAY WEB/NET COMMONS OSS ONION SERVICES CROUDSOURCE JAD CBSS LIFECYCLE ANALYST DESIGN ECONOMICS ITERATION. DISTRIBUTED EVOLUTION PEOPLE COMMONS
CBSS::="community-based service systems", following
.Net
not producing goods for consumption. Not centralized.
open teams.
Mashability -- reuse.
conflicting, unknowable requirements -- discover by doing, emergent.
Continuous evolution.
Focus on operations. Start with a working system and aim for no downtime.
Sufficient correctness. Perpetual Beta.
Unstable resources -- many parallel prosumers.
prosumer::= produce & consumer.
Emergent behavior. Nondeterministic.
.Close.Net
metropolis_model::onion=kernel+periphery+masses.
principles:
.Box
crowd management>project management.
promotion through ranks, attracting developers, meritocracy.
split kernel services from peripheral services.
pernipheral work is done by crowdsourcing, kernel by higher ranked developers.
ubiquitous operations even as it evolves.
.Close.Box
implications: no phases, align business to crowd, not control but lead, tutorials and examples, usability. Requirements come from the periphery, forums help but can be shortcircuited. Architecture vital core. Small modular kernel. Tools for Testing, bug reporting and tracking. Flexible delivery. High availability.
.Close
. 2009-08-03 Mon Aug 3 10:13 Engineering and Formal Methods
Engineering often has a scientific research part -- figuring out
how the real world works, and testing out untried technology/algorithms. But standard engineering relies on
.Key cookbooks
recipes and formulas for designs and qualities. $Maibaum09 (below) reports
that those methods that are labelled "formal" have not produced any
cookbooks. However he does not note the "cookbook" methods that evolved
from theory before the "formal methods movement" started -- DAta Directed
Methods, Compiler design, Data base design, etc.. He also omits to mention
the theoretical obstacles to developing tools and calculations and those
tools that are on the market or being taught -- model checking -- for
example.
However he refers to a book that seems highly relevant ($Vincenti90). He
could also refer to Henry Petrosky's corpus on what engineers do, and how
they fail.
.Open Maibaum09
Tom Maibaum
formal methods versus engineering
ACM Inroads & SIGCSE Bulletin V41n2(Jun 2009)pp6-12
=EDITORIAL ENGINEERING SCIENCE MATHEMATICS DESIGN HANDBOOKS EDUCATION METHODOLOGY COOKBOOK
Quotes Vincenti90 and MAJackson
Engineers need standard cookbook methods and calculations suited to specific kinds of problems.
Fails to mention DDD(JSP, compilers, database, JSD, SSADM etc), Model checking ( SMV Alloy etc.)
Does not discuss the intractability and/or unsolvability of the problem of calculating consequences of requirements.
Implies that given pre/post conditions the code can be generated automatically
-- but actually the engineer needs to supply internal invariants, structures, and non-functional requirements to determine the best design for code.
More on the scientific basis for software negineering
.See [ JuristoMoreno02]
.Close
.Open Vincenti90
Walter G Vincenti
What Engineers know and how they know it
Johns Hopkins UP 1990
=UNREAD SCIENCE ENGINEERING COOKBOOK
notes
.Hole Vincenti90
.Close
. 2009-07-31 Fri Jul 31 08:17 Life and death of software engineering
Another view of software engineering -- as a controled, measurable, and pre-planned
process -- bites the dust ($DeMarco09). Here we have a pundit retreating, in public, from a fragile process and a glad response.
Independently, people at the Simula lab have explored the predictability of software development -- 4 independent outsourced implementations of the same set of requirements -- with varying results. Evidence that we do not have a controlled process.
My belief
.Key One size does not fit all
-- only some projects are engineering projects -- there exist niches where "engineering" is not the ideal way to develop something.
And many projects are best developed incrementally, growing the functionality while maintaining the quality.
.Open DeMarco09
Tom DeMarco
software engineering: an idea whose time has come and gone
IEEE Software Magazine V26n4(Jul/Aug 2009)pp96+95
=ESSAY PROCESS CONTROL METRIC ESTMATING PLANNING
1982 book tried to control too much.
Only marginal projects need tight control.
Better to ask for incremental growth to better and better systems until time runs out.
.Close
.Open Atwood09?
Jeff Atwood
software engineering dead?
coding horror blog (jul 18 2007)
.See http://www.codinghorror.com/blog/archives/001288.html
=ESSAY CONTROL PLANNING ENGINEERING CRAFT
surprised by
.See [DeMarco09]
Quote
.Box
And yet, it's also a release. It's as if a crushing weight has been lifted from my chest. I can publicly acknowledge what I've slowly, gradually realized over the last 5 to 10 years of my career as a software developer: what we do is craftsmanship, not engineering. And I can say this proudly, unashamedly, with nary a shred of self-doubt.
.Close.Box
.Close
.Open AndaSjobergMockus09
Bente C D Anda & Dag I K Sjoberg & Audris Mockus
variability and reproducibility in software engineering: a study of four companies that developed the same system
IEEE Trans Software Engineering V35n3(May/Jun 2009)pp407-429
=EXPERIMENT COMPARISON QUALITIES OUTSOURCED USER CODE MAINTENANCE RELIABILITY COST ESTIMATES TIME PROCESS
Sent out call for bids -- 34 responses, 4 selected -- to develop a web application in Scandinavia.
Prices range from 2k Euros to 70k Euros!
Many variables, no trustworthy hypotheses to test. Exploration.
Concluded that only the usability was similar between 4 competing projects. The reliability, time to produce, size, and maintainability all varied between companies.
There was evidence of a trade off between price and quality.
.Close
. 2009-07-29 Wed Jul 29 09:26 Economics killed web consulting
Continuing the "postmortem" series of example of software development
failing and the non-technical reasons for the failure....
.Open Spolsky09
Joel Spolsky
The Day my Industry Died
Inc. (Jul 1st 2009)
.See http://www.inc.com/magazine/20090701/joel-spolsky-the-day-my-industry-died.html?partner=fogcreek
=HISTORY ANECDOTE FogCreek dotcom WEB CONSULTING BUBBLE ECONOMICS
The growth and death of web consulting 1990-2001
.Close
. 2009-07-27 Mon Jul 27 08:58 Techniques for improving Requirements
First a clarification --
.Key Interaction Design
should not be considered as part of designing the structure, architecture,
or code of software. When programmers design interactions they design for
control freaks and geeks. See Alan Cooper's writing. Instead the design
of the interaction between humans and actors is best treated as specifying
requirements that the code will have to meet. Setting a challenge for the
programmer/designer to meet. The reading for today points to two techniques
that clarify these requirements: The analogy and the "black-hat session".
The theme of the last four of five items has been how focussing on the technology rather
than the real world and existing systems can cause problems. Today's item gives
examples of techniques to uncover these problems early.
Note most of my development work -- for example this web site --
has done it wrong by searching for the sweet spot
where technology meets usability.
.Open Patton09
Jeff Patton & Leah Buley
Leah Buley: toward collaborative, pragmatic user-experience work
IEEE Software Magazine V26n4(Jul/Aug 2009)pp93-94
=INTERVIEW USER INTERACTION DESIGN PEOPLE
Clarify your design principles: If this was a animal/place/food/... what would it be.
Generates non-functional requirements, and clarifies the vision for a project.
Provides guidance when designing interactions.
Use `black-hat` sessions to collect criticisms.
.Close
. 2009-07-22 Wed Jul 22 13:48 Postmortem -- A Technique that avoided requirements
Here is another example of the kind of technical thinking that can make sure that the stakeholders' requirements are not met.
The article is funny. It is a joke. It satirizes a bad practice. But it does record a technology that I loved -- stencils and flow-charts.
.Open Codephirst09
Colin Codephirst (alias) & Nail Maiden (ed)
Where have all the stencils gone?
IEEE Software Magazine V26n4(Jul/Aug 2009)pp
=HISTORY STENCILS FLOWCHARTS =JOKE REQUIREMENTS
Technique was easy and fun to use, impressed the stakeholders, and contributed little to understanding the problem.
Compare
.See [Codephirst07]
.Close
. 2009-07-20 Mon Jul 20 17:12 Continuing the postmortem -- Domain specific worst practices
Previously we had a description of a case study where an unexpected combination
of circumstances coast a company a lot of money. It is a pity that is easy to prove
that finding such combinations is time consuming... or even impossible. Given a sufficiently
complex set of formal requirements we know that there will be properties
that can not be proved or disproved.... but which will be true -- Goedel's
Theorem. And finding such "antics" is at leat NP complete in simple cases, and uncomputable
in general. I teach more abour analysing rules in my classes: CS372, CS556, and CS656.
Even so, it is a pity that developers do not spend more time thinking
outside the computer. And here is another paper that points in this
direction.
Part of the IEEE Software Magazine V26n4(Jul/Aug 2009) special issue on domain specific languages and modeling. Some of the articles and papers are more about what goes on inside the software -- the
.Key Solution Domain
rather than the users, stakeholders, etc that are in the
.Key Problem Domain
(outside the software). One paper observes that most domain models are
not based on the reality and the existing systems but on the existing or planned software.
So here are some recommendations based on experience.
.Open KellyPohjonen09
Steven Kelly & Risto Pohjonen
Worst practices for domain-specific modeling
IEEE Software Magazine V26n4(Jul/Aug 2009)pp22-29
=EXPERIENCES 76 CASES DOMAIN MODELS LANGUAGES GRAPHICS DSL DSM
DSL::="Domain Specific Language".
DSM::="Domain Specific Model".
Everyone's first language is unlikely to be a masterpiece.
Involve stakeholders.
Understand the domain. Think about how people will use the language and/or model.
Suspect outside sources for concepts. Eg UML/3GL/code/library/tools.
Iterate. Nothing is perfect.
Balance specific and general concepts.
Don't Focus too strongly on one feature of the domain.
Choose a good notation: Symbols need to be visually different and not ugly.
Select graphic notation for relations between concepts with care.
Plan for reuse.
Understand the clients process.
Plan to train people. It is not obvous.
Plan to change after it is in use.
.Close
. 2009-07-15 Wed Jul 15 11:07 The costs of ignoring the real situation
This continues my summer series on technological prowess not being enough. The following
case study shows how complex requirements can contain mis-features.
.Open Tamai09
Tesuo Tamai
Social impact of information system failures
IEEE Computer Magazine V42n6(Jun 2009)pp58-65
=CASE STUDY ETHICS SOCIAL SYSTEM Mizuho Tokyo TSE RISKS USER ERRORS RULES ETHICS LAWSUIT
RISKS 12th Dec 2005
.See http://catless.ncl.ac.UK/risks/24.12.html
Example of software leading to costly errors that followed the requirements.
Example of the unexpected and expensive consequences of obscure cases in complex business rules.
Example of human behavior -- user and maintainers -- defeating requirements.
Example for MAJackson's analysis
.See [Jackson06]
in terms of domains outside the software under design should lead to better requirements and results.
.Close
. 2009-07-13 Mon Jul 13 15:10 More on technology and the real world
These two articles are from ACM Queue. The first describes a less successful project and
the second explains the failure as a focus on technology rather than the needs of the
stakeholders.
.Open Norwalk09
Jeff Norwalk
Featured Case Study: Making the Move to AJAX
ACM Queue V7n1(Mar 2009)
.See http://queue.acm.org/detail.cfm?id=1515744
=CASE STUDY WEB/NET AJAX Javascript GWT DEBUGGING RIA SaaS SERIALIZATION PERFORMANCE QUALITY FITNESS
Beta release did not work well enough -- did not fit the user and underperformed.
Always try a full load test.
Always try a user interface test.
Also see
.See [Christy09]
.Close
.Open Christy09
Peter Christy
Commentary: A Trip without a Roadmap
ACM Queue V7n1(Mar 2009)
.See http://queue.acm.org/detail.cfm?id=1515746
=CASE STUDY REVIEW TECHNOLOGY REQUIREMENTS RIA FITNESS PERFORMANCE USER
Review of
.See [Norwalk09]
No user requirements -- straight to technological solution. Performance an afterthought.
Quote
.Box
A good start is to not imagine what users want or need, but instead to talk
with them about it. Try to walk in their shoes and understand how your
software might help make their lives better (or not, as in this case). If
you don't have time to do that yourself, then you should at least work with
good product marketing people and listen to what they have to say.
.Close.Box
.Close
. 2009-07-10 Fri Jul 10 10:09 Who killed Technology
One persistent theme in software development is the mismatch betwen the technology
that the developer knows and loves vs the culture+systems+users within which the
the technology is deployed. So here is the first example of a cool
technology not acheiving its stated objectives because of political and
economic forces. I plan a whole series on this topic....
.Open KraemerDedrickSharma09
Kenneth L Kraemer & Jason Dedrick & Prakul Sharma
One Laptop Per Child: Vision vs. Reality
Commun ACM V52n6(June 2009)pp66-73
.See http://doi.acm.org/10.1145/151646.1516063
=EXPERIENCE TECHNOLOGY CULTURE SYSTEMS ECONOMICS EDUCATION MARKET
OLPC::acronym="One Laptop Per Child".
Project attempted to change the worlds educational system by giving cheap robust laptops to all children.
Teachers don't accept the new learning plan.
Lack of political will and diffusion of goals -- computers are abandoned in classrooms with no training....
Inspired existing companies to develop rival
.Key netbook
Computers.
Good technical solution fails to meet objectives because of cultural mismatch.
.Close
. 2009-07-08 Wed Jul 8 12:26 Open Source as another optional process
.Open Lawton09
George Lawton
the changing face of open source
IEEE computer magazine V42n5(May 2000)pp14-17
=HISTORY F/OSS ECONOMICS
open source is no longer a movement, but another development process option.
.Close
. 2009-07-06 Mon Jul 6 20:07 Term Transformars and semantics
I'm in the process of reviewing $MorrisBunkenburgTyrrell09 (below) when I tripped over another
paper on "term Transformers" with a completely different approach and goal. Pity.
.Open MorrisBunkenburgTyrrell09
JOSEPH M. MORRIS & ALEXANDER BUNKENBURG & MALCOLM TYRRELL
Term Transformers: A New Approach to State
ACM Trans. Program. Lang. Syst. V31n4 (May 2009)a16:1-42
.See http://doi.acm.org/10.1145/1516507.1516511
=IDEA TERM TRANSFORMERS PREDICATE wp LANGUAGES SEMANTICS LOGIC PROOF Lambda axiomatic denotation Dijkstra
phase ::=command "|>" term.
In the text \righttriangle is used for my "|>" above.
Example:
x:=x+1 |> x^2 = (x+1)^2.
Uses a lambda calculus based language of commands and terms to establish mathematical `bona vides`.
.Close
.Open FarmerMohrenschildt00
William M. Farmer and Martin v. Mohrenschildt
Transformers for Symbolic Computation and Formal Deduction
Presented at a Workshop on the Role of Automated Deduction in Mathematics,
CADE-17, Carnegie Mellon University, Pittsburgh, Pennsylvania, June 2000
.See http://imps.mcmaster.ca/doc/transformers.pdf
=IDEA LOGIC DEDUCTION COMPUTATION TERM TRANSFORMERS
STTM::="von-Neumann-Bernays-Goedel set theory".
This has terms and formulas. Terms may be undefined, but formulas are always defined
and are either true or false.
Transformers are total functions which may or may not preserve meaning or logistic properties like being (provably) true or false.
.Close
. 2009-07-04 Sat Jul 4 07:50 How to design Application Programmer Interface -- API
.Open Henning09
Michi Henning
API Design matters
Commun ACM V52n5(May 2009)pp46-56
.See http://doi.acm.org/10.1145/1506409.1506424
=EXAMPLES BAD GOOD INTERFACES FUNCTION PROTOTYPE SPECIFICATION ABSTRACTION ADVICE USER
Bad is easier than good but has large long term unlimitted costs.
.List
Provide sufficient functionality to the caller/client/user.
Smaller is better.
Understand the context.
General interfaces shouldn't set policy but specific ones should.
Design from the caller's/client's point of view and for their convenience not yours.
Don't pass the buck to the caller/user/client.
Document before you implement.
Ergonomics!
.Close.List
Need to change education and career paths.
(dick)|- no discussion of design by contract. Does it give better interfaces?
.Close
. 2009-07-01 Wed Jul 1 10:34 Patterns for Implementers
As noted in the previous but one item
.See ./blog009.html#Difference Engine
it is a lot easier and less risky to work within a range of known, tested, and
standardized set of solutions to understood problems. Notice these don't
have to be the `best`
solution. What is important is that the solutions have been used, several times,
successfully in the past. These are nowadays called
.Key Patterns
of course. This usage of the word "pattern" goes back to
.See [Alexander79]
which describes tested solutions that resolve conflicting forces architecture.
Again note that an untested solution to a problem is not a pattern. It is untested and
so risky. It takes several applications of the solution before it becomes a pattern. It may or
may not evolve into a component in a library, or a feature in a language, but it still is preferable
to an untested solution in practical software development. For example, ideas like stacks and queues
where used again and again until they started to appear in libraries like C++'s STL. Another set
of patterns, that once grabbed the limelight, is the "Gang of Four" (GoF)
.See [Gammaetal94]
object oriented patterns. I cover GoF and GRASP patterns using Larman's text
.See [Larman02]
in my CSCI375 class with
.See ./cs375/patterns.html
as a simplified guide or cheatsheet.
So, using tested patterns is precisely what successful engineers try to do.
Indeed I inherited two books from my father of standard mechanical solutions to problems. With
"Spons'" you don't have to reinvent the log cabin or a device to convert rotation into sliding motion.
So, we need to expand the collection of patterns available to software developers.
And then teach beginners to use them creatively.
The following attempts to help. It is on Safari so most computer professionals can get it online.
It is not the easiest book to read... it starts with the big theory and then develops a lot of details.
Let us hope that some of these are helpful enough to become standards.
.Open Beck06
Kent Beck
Implementation Patterns
Addison-Wesley Pro, Boston MA, 2006 ISBN 0321413091 $CR 0903-0209 Safari
.See http://proquest.safaribooksonline.com/9780321413093
=THEORY PATTERNS Class State Behavior Collections Frameworks Performance TECHNICAL CODE = EXPERIENCE JUnit HotDraw
Lots of detailed advice on object-oriented coding.
.Close
. Request for input on Adrenaline Junkies and Template Zombies
Anybody able to contribute some notes on
.See [DeMarcoHruschkaEtAl08]
?
. 2009-06-30 Tue Jun 30 11:12 Model The Process
I was disapointed in the following paper. It appears to provides evidence for a hypothesis that
I beleive: that software developer's must understand the system into which their software will fit.
In fact it merely advertizes a method for analysing, simulating, and designing business processes.
To my mind this is a part of the problem space that already has many competing methods. The advocated
techniques may or may not be better -- we have no data. Further I think that a lot of errors
in software development happen because the developers did not look beyond the current process into
the "real world".
.Open Barjis08
Joseph Barjis
The importance of business process modeling in software systems design
Science of Computer Programming V71n1(Mar 2008)pp73-87
.See http://www.sciencedirect.com/science $CR 0906-0558
=ADVERT METHOD THEORY MODEL DEMO LANGUAGE-ACTION PETRI GRAPHIC ANALYSIS REQUIREMENTS SCENARIOS
Keywords: Requirements specifications; Model checking; Business process modeling; Business process simulation;
DEMO::="Design & Engineering Methodology for Organizations",
.See http://www.demo.nl/
Special colored Petri nets show logic. Can be simulated to show clients what is possible.
Analyze business processes in terms of the language-action cycle as expressed as $Transactions between parts.
Transaction::=Order; Execution; Result.
Order is a transition from initiator to executor. It sets up a contract for the executor to carry out.
Result is a transition from executor to initiator. It completes the contract.
Execution is executed by the executor and can initiate further transactions with others.
.Close
. 2009-06-29 Mon Jun 29 13:53 Now for Something Difference
Here is a nice example of an engineering project that shows all the symptoms of a software project, and
yet, clearly, involved no software.
The design of the second
.Key Difference Engine
was completed by Babbage in the 1800s, and was implemented [$Swade00] in the 1900s.
It is, possibly, the biggest example of $BDUF ever attempted.
The results are interesting.
BDUF::="Big Design Up Front", pejorative term usually contrasted with various
iterative risk-driven processes ( such as RUP -- The Rationale Unified Process,
.See [BoehmTurner03]
etc. ).
Iterative processes avoid designing the whole system before starting any testable code.
Roughly, their process is:
Analyze a risky little piece of the problem; Design a little solution; Test it; Integrate it;
Refactor; repeat.
Some have argued that a sufficiently rigorous ("formal") design and a stable set of requirements allows
$BDUF to succeed.
In the case of Difference Engine 2 the requirements were stable and expressed mathematically.
The design was expressed in a special rigorous language (Babbage's
.Key Mechanical Notation
.See http://ed-thelen.org/bab/bab-t-385.jpg
and engineering drawings).
No face-to-face communication. But the formal language did not
provide answers to many questions. A graphic notation (compare UML!) did not help.
The questions had to be answered by testing.
We thus prove that $BDUF doesn't work in a advantageous case.
More, the Difference Engine 2 project shows that
it is not software `per se` that is the difficulty but the use of untested technology.
This demonstrates the risks of novel technology as in
.See [Petroski85]
"To Design is Human". There are other hardware projects where the initial design fails and
has to be tested into a working project.
See "
.Key The Soul of a New Machine
" by Tracy Kidder
.See http://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine
on the Wikipedia.
.Open Swade00
Doron Swade
The Difference Engine -- Charles Babbage and the quest to build the first computer
Viking Penguin NY NY 2000 ISBN 0-670-91020-1
=HISTORY ENGINEERING PROJECT HARDWARE MECHANICS STANDARDS GRAPHIC LANGUAGES CALCULATORS
The ultimate big design up front on a bleeding edge project. Design completed 100 years before implementation started.
Result: Lots of debugging and redesign. Unit testing saved time. Assembly and test lost time.
Impossible marketing deadline -- almost death march -- not met.
Critical need of standard components and interfaces -- Whitworth bolts, nuts, and screws for example.
.Close
. 2009-06-23 Tue Jun 23 11:10 Websites on Reliability
Mark's column in SIGSEN is always interesting and provides interesting links. Here
is the latest crop -- taken from the PDF.
.Open Doernhoefer09a
Mark Doernhoefer
Surfing the net for software Engineering notes -- Software and System Reliability
ACM SIGSOFT Software Engineering Notes V34n3(May 209)pp6-15
.See http://doi.acm.org/10.1145/1527202.1527204
(PDF)
=SURVEY =LINKS RELIABILITY
Handbook
.See http://www.cse.cuhk.edu.hk/~lyu/book/reliability/
The Reliability Information Analysis Center
.See http://www.theriac.org/
The Data and Analysis Center for Software
.See https://www.thedacs.com/databases/url/key/2/
Relex Reliability Dictionary
.See http://www.relex.com/resources/ReliabilityDictionary.asp
Weibull.com
.See http://www.weibull.com
NASA Software Assurance Technology Center
.See http://satc.gsfc.nasa.gov
IEEE Reliability Society
.See http://www.ieee.org/portal/site/relsoc/menuitem.112d36a56667b078fb2275875bac26c8/index.jsp?&pName=relsoc_home
City University Centre for Software Reliability
.See http://www.csr.city.ac.uk
Reliability Engineering Tools
.See http://www.enre.umd.edu/tools.htm
...
IEEE Transactions on Software Engineering(1993)
.See http://portal.acm.org/toc.cfm?id=173802&type=issue&coll=GUIDE&dl=GUIDE&CFID=29760540&CFTOKEN=27889279
Dependable Embedded Systems
.See http://www.ece.cmu.edu/~koopman/des_s99/sw_reliability/
...
Reliability Calculators
.See http://users.telenet.be/phvg/AvailabilityTranslator.htm
.See http://www.pixelbeat.org/docs/reliability_calculator
.Close
. 2009-06-23 Tue Jun 23 09:16 Server fixed again
I'm just finishing up grading and testing the newly rebuilt server
that I use for preparing web pages etc.
Also wondering about the publication schedule for this blog in the
summer.
. 2009-06-22 Mon Jun 22 13:08 Servers fail again
My usual workstation (and other in csci.csusb.edu) are less than finctional
after a crash last week.... luckily I've been able to port my tools
to the faculty web server and so this is being written on a strange machine.
More later.
. 2009-06-19 Fri Jun 19 16:40 Students present work
I spent the whole day taking notes of student presentations.
See 2009/09/19 in
.See ./seminar/
. 2009-06-17 Wed Jun 17 12:18 Errors and Defects
Here is a perennial question -- where do you look for bugs in a large modular
project? Should you look at the big complex modules or the small ones? I got involved in this
controversy back in 1985 ($BasiliPerricone84 below).
The evidence conflicts ith ones intuition that defects occur most in large
complex modules.
Since then I've noted
five other papers in my bibliography (list below)... and here is a new contribution --
$KoruZhangEmamLiu09.
.Set
=EXPERIMENT METRIC QUALITY MODULE SIZE DEFECTS STATISTICS . . .
.See [Hatton97 ]
=EXPERIENCES ANALYSIS SIZE METRICS RELIABILITY . . .
.See [FentonOhlsson00 ]
=EXPERIENCE STATISTICS SQA METRICS . . .
.See [GravesEtal00 ]
=POLL 52 OPEN SOURCE DEFECTS . . .
.See [KoruTian05 ]
=EXPERIENCE COCOMO TEAM PEOPLE FUNCTION POINTS . . .
.See [SmithHaleParrish01 ]
.Close.set
.Open BasiliPerricone84
Victor R Basili & Barry T Perricone
Software Errors and Complexity: An Empirical Investigation
Commun ACM V27n1(Jan 1984)pp42-42 + Correspondence V28n3(Mar 1985)pp322-323
(with Richard J Botting, H Dieter Rombach & Richard W Selby)
=EMPIRICAL DEFECTS MODULE COMPLEXITY SIZE SEL CHANGES
New application means requirements change during the project.
New modules have different kinds of errors than changed modules.
Module size did not account for error proneness.
Intuition clashes with data.
.Close
.Open KoruZhangEmamLiu09
A Guneg Koru & Dongsong Zhang & Khaled El Emam & Hongfang Liu
An Investigation into the Functional Form of the size-defect relationship for software modules
IEEE Trans Sofware Engineering V35n2(Mar/Apr 2009)p293-304
=EMPIRICAL STATITICS OPEN SOURCE LOGS DEFECTS MODULE SIZE Cox
Problems with conventional analysis -- deleted modules, size changes, ...
Proposes and fits Cox proportional hazards models to CVS data from Mozilla, Cn3d, JBoss, and Eclipse
Discovers more changes are made to small modules than might be expected.
.Close
. 2009-06-12 Fri Jun 12 15:25 Cards
One of my favorite tools has been old fashioned cardboard cards. All my class
notes in my last undergraduate year are on cards. Burroughs explained
an earlystack based compiler using cards as an analogy. I use playing cards to
demonstrate sorting and searching algorithms. My first data base was a
bibliography that was (and is) on 3><5 cards. Psychologists
(eg Kelly) have used them with success to tease out the way we think
and feel about a set of subjects. And of course I've read about and
like the XP technique of writing `User Stories` on cards and sorting them
in different ways in the `Planning game`. So with great pleasure we have
the following:
.Open Maiden09
Neil Maiden
Card Sorts to Acquire Requirements
IEEE Computer Magazine V26n3(May/Jun 2009)p85-86
=EXPERIENCE MANUAL REQUIREMENTS TOOL CARDS SORTING
Compares advantages and disadvantages for using a very old technology
to represent and manipulate requirements.
Compare the XP Planning Game.
.Close
. 2009-06-12 Fri Jun 12 15:25 A Graphic is worth a thousand words
Diomidis has shared some of his favorite tools...
.Open Spinellis09a
Diomidis Spinellis
Drawing Tools
IEEE Computer Magazine V26n3(May/Jun 2009)p12-13
=EXPERIENCE GRAPHIC TOOLS dot Graphviz pic neato twopi circo gnuplot groff GMT mapping Google UMLGraph SVG PDF PNG ImageMagic
"We don't seem to benefit from drawings in the way other engineers do".
Describes experiences with half a dozen tools that produce graphics from commands/texts/data.
Graphviz::=http://www.graphviz.org/
groff::=http://www.gnu.org.software/groff/
gnuplot::=http://www.gnuplot.info/
GMT::=http://gmt.soest.hawaii.edu/
UMLGraph::=http://www.umlgraph.org/
ImageMagic::=http://www.imagemagic.org/
Ghostscript::=http://pages.cs.wisc.edu/~ghost/
Inkscape::=http://www.inkscape.org
.Close
. 2009-06-10 Wed Jun 10 13:34 Better Embedded Programming
People are always proposing new/old ways of fixing software processes. Here is a selection
for fixing processes for developing embedded software: Incorporate executable models in the process,
use static tools to check code, use software improvement techniques and CMMI, use a more agile process, use more formal techniques, use UML and MDD, ...
As a child I often looked at the "Pick and Mix" counter for sweets in Woolworths -- I guess
you should pick and mix from these moderately perennial proposals.
Details follow:
.Open ShokryHinchey09
Hesham Shokry & Mike Hinchey
Model-based verification of embedded software
IEEE Computer Magazine V42n4(Apr 2009)p53-59
=ADVERT PROCESS EMBEDDED SOFTWARE+HARDWARE
Describes a complex sequence of phases which use a mathematical model to test successive versions of the system.
process=$MIL; $SIL; $PIL; $HIL.
MIL::phase="Model-in-the-Loop", Basic simulation of models response to stimuli with model generating code for $SIL.
SIL::phase="Software-in-the-Loop", Test executable code from $MIL vs test results in $MIL on a PC.
PIL::phase="Processor-in-the-Loop", Test executable code from $MIL vs test results on the processor.
HIL::phase="Hardware-in-the-Loop", Test on actual hardware.
.Close
.Open ChelfEbert09
Ben Chelf & Christof Ebert
Ensuring the integrity of embedded software with static code analysis
IEEE Software Magazine V26n3(May/Jun 2009)p96-99
=ADVERT RISKS =HISTORY TOOLS lint
p97 Links to resources in sidebar.
Six_detectable_defect_classes:= division by zero + memory leak + null pointer dereference + uninitialized variable + buffer overflow or underflow +inappropriate cast.
.Close
.Open Kandt09
Ronald Kirk Kandt
Experiences in Improving flight software development processes
IEEE Software Magazine V26n3(May/Jun 2009)p58-64
=EXPERIENCE JPL SPACEFLIGHT CONTROLLERS CMMI IMPROVEMENT MATURITY MODULES SQA MSAP
Very little quantitative evidence of benefits of the improvement process.
Improvements had a wide impact.
.Close
.Open SmithMillerHuangTran09
Michael Smith & James Miller & Lily Huang & Albert Tran
A More Agile Approach to Embedded System Development
IEEE Software Magazine V26n3(May/Jun 2009)p50-57
=CASESTUDIES 4 XP TDD TESTING Embedded-Unit XPI E-Race
Stages:= Vision; Prototyping; initial_production; full_production.
Run a parallel system to monitor for race hazards.
.Close
.Open YooJeeCha09
Junbeom Yoo & Eunkyoung Jee & Sungdeok Cha
Formal Modeling and Verification of safety-critical software
IEEE Software Magazine V26n3(May/Jun 2009)p42-49
=EXPERIENCE FORMAL TOOLS NuSCR nuSRS FTA FBD SMV Verilog
Connect model checking tools to a graphic interface -- use color!
Generate code from models.
FTA::="Fault Tree Analysis".
Reduce the gap between "raw data" and "Domain Knowledge".
.Close
.Open MartinezMerinoSalmeronMalpartida09
Jesus Martinez & Pedro Merino & Alberto Salmeron & Francisco Malpartida
UML-based Model-Driven Development for HSDPA
IEEE Software Magazine V26n3(May/Jun 2009)p26-33
=EXPERIMENTS TELECOMMUNICATIONS ACE CODE UML MDD TOOL Rhapsody State-Charts
HSPDA::="High-Speed Downlink Packet Access".
Using executable and compilable models made it easier.
.Close
. 2009-06-08 Mon Jun 8 07:50 Reading about invented languages
I finished "In the Land of Invented Languages"
overnight on Saturday. It is going to be a busy day today and so
I will edit the bibliographic entry
.See [Okrent09]
directly
rather than expatiate here....
But briefly: (1) required reading for all language designers. (2) humans
are incredibly inventive, but inventing a new "natural" language is
not a productive use of your time. (3) read it!
. 2009-06-05 Fri Jun 5 12:44 Undetected Errors
I can't resist noting $The_Kirsch_Principle and its history.
.Open Kirsch09
Russell A Kirsch
An undetected Error (letter)
IEEE Computer Magazine V42n4(Apr 2009)p53-59
=HISTORY SEAC
SEAC work 24/7 for four years with an undetected error! Discovered when moved.
Video
.See http://video.google.com/videosearch?q=seac+history
The_Kirsch_Principle::="All computers are always, in some, sense 'broken'".
.Close
. 2009-06-03 Wed Jun 3 11:19 More invented Languages
My wife heard this
.See http://www.onpointradio.org/2009/06/invented-languages
last night on NPR (On Point) and I replayed it this morning. If you are interested
in languages then you should enjoy it. It is hype for
$Okrent09 below.
But fascinating and knowledgable discussion.
And gives me an excuse to indulge my liking for artificial languages.
For a previous entry on this topic see
.See ./blog008.html#Holmes08
and the controversy in 1978 in "Computer World".
Okrent claims to have found 900 hundred artificial languages
-- and they have all failed.
If Okrent is right then you need speakers for the language before the language exists.
It is quite clear that languages evolve -- and that this is healthy.
.Open Okrent09
Arika Okrent
In the Land of Invented Languages: Esperanto Rock Stars, Klingon Poets, Loglan Lovers, and the Mad Dreamers Who Tried to Build A Perfect Language
Random House Publishing Group Pub. Date: May 2009 ISBN-13: 9780385527880 352pp
=UNREAD =SURVEY =HISTORY 900 ARTIFICIAL LANGUAGES Blissymbolics MATHEMATICS LOGIC Elvish
Benjamin Whorf's Hypothesis
More when I've read it
.Hole
.Close
While researching the previous entry I found a new diagramatic technique based on Bliss + Loglan
.See http://kennexions.ludism.org/old/belltrinity.html
which in turn lead me to people
.See http://www.ludism.org/gbgwiki
working on the "Glass Bead Game" imagined by Herman Hesse(
.See Hesse43
below ). Another
topic which has been part of my life for nearly half a decade. The Glass Bead Game
captures the essence of academic life - the search for connections and ideas -- and
the ritual presentations.
. The Glass Bead Game
.Open Hesse43
Herman Hesse
The Glass Bead Game (Magister Ludi)
Publishers: Several. Try any good library or book store
.See http://www.amazon.com/Glass-Bead-Game-Magister-Novel/dp/080501246X
(Amazon.com)
=CLASSIC NOVEL BILDUNGSROMAN LANGUAGES ACADEME MEDITATION EXISTENTIALLISM
For history, summary and clues see
.See http://en.wikipedia.org/wiki/The_Glass_Bead_Game
(Wikipedia)
.Close
Apparently people have been trying to instantiate the game ...
.Open Hale-Evans04
Ron Hale-Evans
Kennexions GBG Home Page
Link
.See http://kennexions.ludism.org/
$TBA
Also see
Ludism::=http://ludism.org/
, the philosophical study of games
=IDEAS Glass Bead Game Wiki Kennexions Bliss Loglan
.Close
. Bliss Symbols
.Open Bliss42
Charles K Bliss
Semantography ( Blissymbolics) 2nd Edn
Semantography ( Blissymbolics), Sydney Australia 1942
.See http://www.semantography.com/
=ADVERT GRAPHIC SYMBOLIC LANGUAGE
Dictionary of symbols
.See http://www.semantography.com/4/
.Close
Other resources:
.See http://www.blissymbolics.org/
(introduction to symbols)
.See http://www.blissymbolics.us/animations/
(Animations of the derivations of some symbols)
.See http://www.blissymbolics.org/downloads/bliss-rules.pdf
(Rules)
.See http://www.blissymbolics.us/
(USA)
.See http://www.crockford.com/blissym/
(introduction and fonts)
.See http://www.crockford.com/blissym/lesson1.pdf
(first lesson in Bliss)
.See http://www.omniglot.com/writing/blissymbolics.htm
(Intro -- one page of simplest symbols)
What I would like is an online dictionary/thesaurus.
I guess that is enough indulgence for today.
. 2009-06-01 Mon Jun 1 13:19 More Details on the Safety of Hybrid Systems
Now I have studied the technical report $PlatzerClarke08
below I must revise my comments in the previous blog entry.
I thought it would describe the discovery of a hole in a standard way of
avoiding collisions between aircraft. It fact it gives an example showing
the absence of errors. I've yet to find a source for the original report. I'll
probably find it one day.... but meanwhile I small hype.
.Open PlatzerClarke08
Andre Platzer & Edmund M Clarke
Computing Differential Invariants of Hybrid Systems as Fixed Points
CMU CS Technical Report
.See http://reports-archive.adm.cs.cmu.edu/anon/anon/home/ftp/2008/CMU-CS-08-103.pdf
(PDF)
=MATHEMATICS MODEL LOGIC ODEs DIFERENTIAL EQUATIONS SAFETY HYBRID PROGRAMS
Gives a way to compute whether formula describing important properties are true for all time or not.
[\alpha]\phi = `all states reachable thru Hybrid program \alpha satisfy \phi`.
Formulas assembled out of terms (expression ~ expression) for relation "~".
Directional derivative of a term t wrt to vector equation D : x_dot = \theta, \nabla[t] = \nabla t.\theta.
Differential Invariant of a formula F depends on \nabla[D]F is the conjunction of \nabla t.\theta over all terms `t` in F.
.Close
. 2009-06-01 Mon Jun 1 06:29 Fun introduction to Intractability
I can't resist posting this
.See http://www.codinghorror.com/blog/archives/001270.html
bit of the "Coding Horror" blog that gives a fun introduction
and example (from `xkcd` comic) to "P=NP".
. 2009-05-30 Sat May 30 07:13 The Joy of Upgrades -- Scripts dead
The Contact/MailMe and Contribute scripts no longer work. Please
use regular EMail to rbotting at my CSUSB address instead.
. 2009-05-29 Fri May 29 13:05 Dependable and Safe Systems
First I found an interesting article
.See http://www.sciencedaily.com /releases/2009/04/090420121333.htm
in the Science Daily web site. It reported on Edmund M. Clarke and Andre Platzer's
work on verifying the Safety Of
Computer-controlled Devices (ScienceDaily 23 April 2009. 28 May
2009). This is based on a press release
.See http://www.cmu.edu/news/archive/2009/April/april20_cyberphysicalsystems.shtml
that I chased back to a CMU technical report
.See http://reports-archive.adm.cs.cmu.edu/anon/anon/home/ftp/2008/CMU-CS-08-103.pdf
(PDF)
on proving the safety of systems that have both digital and analog components -- for example
an air traffic control system. The motion of the planes (hopefully) is analog, and
much of the modern control system is digital.
Their technique found a case where the normal
recommended flight path to avoid another aircraft, if followed by both planes, leads to
a collision. Not a safe system. To achieve this (and some other impressive
results the authors compute differential invariants which are an extension of Floyd's Invariant Assertion used in software.... and indeed the definition of transitive closure in `Principia Mathematica`.
I need time to study the report in detail before I can record it in my bibliography.
Meanwhile, Daniel Jackson has written a long but well reasoned proposal for
a newish way of thinking about the quality of systems. In particular, he argues that
if you are going to rely on a system then you need to have some reason for trusting it.
He suggests a way
.See Dependability Cases
to record and develop dependable systems.
.Open JacksonD09
Daniel Jackson
A Direct Path to Dependable Software
Commun ACM V52n4(Apr 2009)pp78-88
.See http://doi.acm.org/10.1145/1498765.1498787
.See http://sdg.csail.mit.edu/publications.html
=ESSAY RISKS COSTS not PROCESSES CRITICAL PROPERTIES CLAIMS QUALITIES REQUIREMENTS
Based on a study done for NRC lead to
.Key Dependability Cases.
Lots of examples of RISKS and how they occurred and how the effect reasoning about the dependability od a system.
A dependability case provides evidence, in the form of claims, that certain critical properties will hold.
The analysis of the critical properties and the claims that support them starts on day one of a project,
and guides architectural decisions.
Well chosen architecture -- modular, decoupled, simple --
makes it cheaper to establish a dependability case.
Dependability cases should develop "hand-in-hand" with the product.
The developers chose techniques and technology to support the claims.
Critical properties should be close to the user/client/real world.
All claims depend on assumptions about the client's world: an air traffic control system can not stop a pilot
deliberately crashing into another aeroplane.
Claims connect the developing system, via assumptions, to the critical properties.
A dependability case must be auditable, complete, and sound.
A rigorous process can help establish a dependability case -- but need not be burdensome.
A risk-averse and meticulous culture will help.
Need robust platforms and tools -- language design.
The correctness of code is not the weakest link in the chain -- only 3% of the time...
Testing and analysis contribute as well.
Credible tools -- example of a broken proof: binary search when bounds > largest integer!
See also
.See [JacksonD06]
.See [Jackson01]
.See [Jackson04]
(Outer vs inner requirements)
.Close
. 2009-05-27 Wed May 27 17:18 Changing tools and systems -- makefiles
One of the things one learns in practice is to "make haste, slowly"
(`festina lente`), to not
rush your clients into a large change. To evolve changes incrementally rather than big-bang.
Another rule is to prefer bottom-up user-advised growth to top-down management mandated
change.
The following article makes this point.
But not in a client's domain. Kode Vicious is discussing making changes to a developer's tools.
I have often regretted that much that we know about developing software for our clients is not applied to
developing our tools as well.
.Open Neville-Neal09
George V Neville-Neal (Kode Vicious)
System Changes and Side Effects
Commun ACM V52n4(Apr 2009)pp25-26
.See http://doi.acm.org/10.1145/1498765.1498777
=EXPERIENCE TOOLS SYSTEMS CHANGE Make SCons Makefiles SConstruct debugging Python
Problems occur with build tools when there are many interlinked description/dependency files.
Debugging a collection of configuration/buildfiles/Makefiles is difficult.
Changes have unexpected consequence that ripple thru the system... and the description of the system.
Make changes because they give value.
.Close
. 2009-05-26 Tue May 26 17:22 Memorial Day and Tao
Yesterday was a holiday in the USA and so I didn't post a message.
Meanwhile, I have added a "The Tao of Programming" link to my
.See ./samples/methods.html
page -- which has many HHOS descriptions of programming
development methods and processes.
By the way.... the web server in the CSE.csusb.edu domain
are about to change. I will be moving the pages on this site over
sometime soon.
It should be transparent, but systems do exhibit antics....
. 2009-05-22 Fri May 22 15:58 Computer languages
Perhaps two publications on computer languages that don't advertise a
particular language might form a trend. There was
.See ./blog009.html#WhiteKochGehrkeDemers09
on using domain patterns to design games scripting languages, and now
$Shapiro09 that describes half-a-dozen debugging languages as examples of how langauges evolve.
However, there is also $Richardson09 and
.See /blog009.html#Larson09
which continue the old tradition of selling a particular language...
.Open Shapiro09
Michael Shapiro
Purpose-Built Languages
Commun ACM V52n4(Apr 2009)pp36-41
.See http://doi.acm.org/10.1145/1498765.1498781
=HISTORY EVOLUTION LANGUAGES DEBUGGERS UNIX WEB JavaScript XML-RPC ODT-8 db adb proc multicall
Figure 1: little languages in Unix in the early 1980s
.Close
.Open Richardson09
Chris Richardson
ORM in Dynamic Languages
Commun ACM V52n4(Apr 2009)pp48-55
.See http://doi.acm.org/10.1145/1498765.1498783
=ADVERT GORM Grails Groovy OBJECTS RELATIONAL DATABASE Hibernate PERSISTENCE
Managing a Object-Relational-Mapping (ORM) using a dynamically typed language like Groovy.
.Close
. 2009-05-20 Wed May 20 13:27 Musical standards
Just read the following and added to my
.See ./samples/standards.html
page.
.Open BaggiHaus09
Denis Baggi & Goffredo Haus
IEEE 1599: Music encoding and interaction
IEEE Computer Magazine V42n3pp84-87
=ADVERT =STANDARD IEEE-1599 MUSIC AUDIO VISUAL NOTATION GAME JAZZ Blues XML
IEEE1599::DTD=http://standards.ieee.org/downloads/1599/1599-208/
Example:
Previous report
.See [Baggi05]
.Close
. 2009-05-18 Mon May 18 12:52 Domain Specific Scripting Languages -- Games
This may be the first time a computer professional has published a discussion of
the design of a language without advertizing the language they have already designed. The
key thought is a flash of blinding if obvious truth -- the users and usage of the
language should strongly influence the design of language.
.Open WhiteKochGehrkeDemers09
Walker White & Christoph Koch & Johannes Gehrke & Alan Demers
Better Scripts, Better Games
Commun ACM V52n3(Mar 2009)pp42-47
.See http://doi.acm.org/10.1145/1467247.1467262
=ESSAY LANGUAGE DESIGN DOMAIN GAMES SCRIPTING USER DESIGNER ENGINEER PATTERNS
Notes the need for less technical designers to write scripts for games.
Proposes designing languages that fit the well-known patterns --
used by users and by game-play programmers not software engineers.
State_Effect::pattern="Behavior of object depends on current state and is summarized into an effect that is then applied to change the state",
so, language separately declares state variables and effect variables and supports two phases: effect and update.
During the effect phase the state variables do not change and the effect is not read.
In the effect phase the effects are read only and the states are write only.
simulation_loop::=following
.(
for each timestep
.(
for each object, compute object.effect' using object.state;
for each object, update object.state' using object.effect;
.)
.)
Restricted_iteration::pattern="to avoid infinite loops, all loops have finite limits",
.See [Witty77a]
Concurrency patterns -- example of the need for an atomic transaction: putting things in a container, if room.
Game-Aware Runtimes: Language should provide the runtime system with clues on how to execute code, and monitor it for statistics.
Does not advocate a particular language!
.Close
. 2009-05-15 Fri May 15 13:08 System Engineering
We've just had James H. Jones of ODDSCO
.See http://www.optants.com
and Optivus Proton Therapy
present an seminar
.See ./seminar/20090515JimJones.txt
on System Engineering. For a short while you can
find the slides he presented at
.See ./seminar/20090515JimJones.pdf
on this web site.
I've also just finished reading an article noting how far short Software
Engineering is from Engineering. It bewails the lack of training in System
Thinking and System Engineering in COmputer Science.
It ignored the reality that most software development is not engineering.
Because engineering processes fit some niches well, but not others.
.Open DenningRiehle09
Peter J Denning & Richaqrd D Riehle
The Profession of IT: Is Software Engineering Engineering
Commun ACM V52n3(Mar 2009)pp24-26
.See http://doi.acm.org/10.1145/1467247.1467257
=POLEMIC ENGINEERS
Things we do worse than engineers do:
.List
The Principle of least surprise.
Design metrics -- including design to tolerances.
Separating design from implementation.
Reconciling conflicting forces and constraints.
Adapting to changing environments
.Close.List
Roles (one person plays many roles in a team) --
software { architect, engineer, programmer, manager } | O(systems engineer).
Need for Systems Thinking: From the hardware.... to the user environment.
Need for better tools, education, adoption of effective practices.
.Close
. 2009-05-13 Wed May 13 13:33 Erlang the Language
I have just updated
.See ./samples/languages.html#Erlang
my documentation on the Erlang concurrent functional language.
This comes from studying $Larson09 below.
.Open Larson09
Jim Larson
Erlang for Concurrent Programming
Commun ACM V52n3(Mar 2009)pp48-56
.See http://doi.acm.org/10.1145/1467247.1467263
=ADVERT LANGUAGE Erlang NON-SEQUENTIAL FUNCTIONAL Ericsson OTP OPEN SOURCE AGENTS
A naturally concurrent language used at Ericsson and elsewhere.
Use pattern matching rather like Prolog!
But also pattern matches incoming massages.
Has anonimous functions.
Typically a client makes a unique reference that it sends as part of a
message to a parallel server. This identity is used by the server to
call-back the client.
Note: The obligatory examples are also at
.See http://en.wikipedia.org/wiki/Erlang_(programming_language)
(Wikipedia)
See
.See ./samples/langauges.html#Erlang
for more information.
OTP::="Open Telecom Platform".
.Close
. 2009-05-11 Mon May 11 14:23 Proof Checking
I have grave doubts about the usefulness of the following theory -- but I've been proved wrong before --
as when I decided that relational databases would never be important.
My $MATHS language is designed with a proofs in mind.
I use a variation of Natural deduction that use block structure in the same way
that modern programming languages do. I taught this back in the 1970's.
I've written several pages
.See ./maths/logic_20_Proofs100.html
.See ./maths/logic_25_Proofs.html
.See ./maths/logic_27_Tableaux.html
.See ./maths/logic_10_PC_LPC.html
.See ./maths/logic_11_Equality_etc.html
on proofs.
Key point -- it should not be difficult to write a PVS style tool
.See ./maths/logic_20_Proofs100.html#Automation
to check MATHS proofs, spot holes and errors,
and report the correctness. However you do have to examine every step in the proof ... and in any
interesting logic there proofs of any length can think of.
Recent theoretical work hints at ways of writing proofs
that take a constant time
but offer on partial certainty. They will never reject a correct proof, but they may
accept (occasionally) a fallacious proof.
.Open Sudan09
Mahu Sudan
Probabilistic Checkable Proofs
Commun ACM V52n3(Mar 2009)pp76-84
.See http://doi.acm.org/10.1145/1467247.1467267
=HISTORY THEORY PROOFS NP=P COMPLETENESS SOUNDNESS PCP VERIFIERS and PROVERS
Normal proof methods require you to check every step in the proof to be sure that the result is a theorem.
PCP is a theoretical method for constructing proofs that can be checked with a degree of certainty quickly.
Examples quoted are limited to the propositional calculus or the lower predicate calculus with a finite universe of discourse.
.Close
. 2009-05-08 Fri May 8 12:05 Graphical notations for Software
When I was first allowed to compile and run my code, first year of college (1963), and was taught about
flow charts. I decided that what I wanted was a language that could encode flow charts directly.
At the time I had not seen any visual displays.... so I invented a notation that expressed boxes and
arrows directly. I've forgotten the details and never figured out how to compile it.
My graduate work centered on simple graphics -- drawing curves mainly. But I saw executable graphics
running in some American research places. As a junior faculty (1970's) I played with the
idea of inputting and executing flowcharts just in time for the Structured Programming revolution
to make flowcharting a "bad" idea.
One of my students
.See [Witty76]
.See [Witty77a]
.See [Witty77b]
invented a very clever and simple notation for structured
.Key Dimensional Flowcharts
which he proved by developing an operating system for a microfiche and microfilm output device,
plus a language and tool that let him compile his Dimensional charts and output them to microfiche.
Very impressive. The key idea was brilliant -- the vertical dimension was for sequences and
the horizontal for parallelism (including conditional branches). Refinement was shown as a diagonal.
It gave elegant support of structured programming and stepwise refinement.
.Image DimensionalChart.png Dimensional Chart of a program
Then I left my university and joined the British Civil Service to learn Jackson Structured Programming
.See http://en.wikipedia.org/wiki/Jackson_Structured_Programming
(JSP)
which has a different, very hierarchical approach to drawing data and program structures. A key thought is
that the structure of the program reflects the structure of the data and the "real world" that the
data encodes.
I then moved to the USA and explored combining Dimensional Charts with JSP. By 1985 there was a ton
of graphical notations for programs
.See [Raeder85]
including the famous
.See Nassi-Shneiderman
diagrams --
.See http://en.wikipedia.org/wiki/Nassi-Schneiderman_diagrams
(Wikipedia).
I developed a technique I called "Temporal Mapping" that used Witty's Dimension's for sequence and selection.
I used these with a bit JSP to develop my favorite tool for word wrapping long lines in a text file --
.See ./tools/br.d.html
.See ./tools/br.d.in.jpeg
.See ./tools/br.d.out.jpeg
.See ./tools/br.c
(K&R C source code).
I've evolved temporal maps further into a languge TEMPO
.See ./papers/rjb9Xx.TEMPO.html
(figures in PostScript).
However I decided that parallelism was a third dimension and decided to wait for a virtual reality system
to explore that. I had also discovered how very constraining it is to cast every process into the
four structures: sequence, selection, iteration, and parallelism.
And round about then David Harel
.See http://en.wikipedia.org/wiki/David_Harel
sent me a copy of a technical report on statecharts
(
.See http://en.wikipedia.org/wiki/Statechart#Harel_statechart
) and the rest is history ($Harel09 below), as they say.
.Open Harel09
David Harel
Statecharts in the Making: A Personal Account
Commun ACM V52n3(Mar 2009)pp67-75
.See http://doi.acm.org/10.1145/1467247.1467265
=HISTORY StateCharts GRAPHIC TOOL NOTATION FSM Hypergraphs SYNTAX SEMANTICS PRACTICE VISUAL FORMALISM Statemate Rhapsody
Originally an invited paper at the history of Programming Languages conference 207
How work on Avionics (1983) lead to a notation where diagrams define the system's behavior.
1983 Problem: clients understood the system but the information was not well-organized:
"I had to pend a lot of the time asking questions"(p69).
Solution: "The pictures simply did a much better job of setting down on paper the systems' behavior[...]the mathematician in me found this difficult to accept".(p69)
"when designing a graphic language, topology should be used whenever possible"(p70).
"Executability was a basic[...] concern"(p70).
1984 Tools: Statemate -- GUI, executable, generate source code. Simulate circumstance -- similar to debugger.
Woes of Publication -- many rejections -- some successes.
Technical report
.See [Harel86]
Commun ACM
.See [Harel88]
IEEE Trans Se
.See [Hareletal90]
ACM TOSEM
.See [HarelKahanna92]
.See [HarelNaamad96]
IEEE Computer Magazine
.See [Harel01]
Object-oriented StateCharts:
.See [HarelGery97]
.See [HarelKupferman02]
On Semantics: very important, but finding the right semantics took time.
Now used widely.
Conclusions
.Box
Lessons come from developing tools and real-world use.
Development in the lion's den -- not academic.
Getting a handle on the way clients think.
Should have published a book faster.
Should not have confused the problem of getting clear semantics with publicizing the chosen semantics.
.Close.Box
.Close
. 2009-05-06 Wed May 6 11:00 Paper confirms previous observations
I learned about this paper by reading "Computer Reviews" $CR.
Then I found it in the ACM Digital Library.
It is a very nice paper reporting on experiences implementing a workflow Management system for a bank.
They used $BPEL
BPEL::=http://csci.csusb.edu/dick/newb2006/FuBultanSu05.html
Which I am suspicious of because it uses control flow rather than data flows to model
complex non-sequential systems
.See http://csci.csusb.edu/dick/newb2006/newb0329.html#DesaiEtal05
What is nice about it is that the writers come to some very familiar conclusions.
.List
Exceptions are the rule.
.See [KjaerMadsen95]
90% correct today is better than 100% later.
A lesser tenet of
.See [Gancarz95]
Listen and work with your users.
.See [Royce70]
(one of hundreds tagged " USER " in my bibliography).
Grow Software
.See [Brooks95]
Systems of Systems increase interdependence
(Boehm's SISOS
.See [Boehm08]
).
.Close.List
It sounds that using a work flow management system to link legacy systems is very like using a
UNIX shell script to drive UNIX power tools.
.Open BraheSchmidt07
Seen Brahe & Kjeld Schmidt
The Story of a Working Workflow Management System
ACM Proc GROUP'07 (Nov 2007) pp249-258 $CR 0811-1106 ACM DOI
.See http://doi.acm.org/10.1145/1316624.1316661
=EXPERIENCE SYSTEMS WORKFLOW BPEL XML SOA SERVICE LEGACY WFM PEOPLE DANISH BANK 2003-2007 ORCHESTRATION PORTAL TASK vs CASE
CSCW::="Computer Supported Cooperative Work".
WFM::="Workflow Management".
SOA::="Service Oriented Architecture".
Early attempts to program office procedures failed because exceptions to the procedures were common.
How to make the result adaptable?
How to fit in with the continuing creation and adaption of procedures/workflows.
How to integrate existing (legacy) systems.
Integrate systems by using SOA... encapsulate legacy code as a service. Workflow as glue.
(dick)|- Workflow sytems/languages seems to be like scripting.
Develop a workflow system iteratively.
Get the developers and the users closely involved.
Business's analyst's can get it wrong!
Development followed Babbage's model: craft; division of labor; stepwise automation; more or less complete automation.
Need to avoid fragmented tasks.
People prefer complete cases to individual tasks.
First task in process should assign remaining tasks in the case to same person.
"We do not want to be a factory". Not task-centric, but case-centric.
"It does not feel right " not to know the context of tasks.
Another early task in each workflow is to determine if the task is simple enough to be automated or needs human discretion and guidance.
Describing exceptions if difficult and time consuming. Better to bounce them to a human... and think about
how to automate in a later iteration.
Automating more kinds of processes is an optimization. Tweaking and Twisting the automated processes.
Nearly a 20% gain in speed. 80-90% automated.
No need to re-enter data into each application.
People like to monitor automated processes.
Tell the users when the system is becoming unstable.
Tell them about bugs.
Tell them about performance problems.
Workflows integrated legacy systems into exiting processes
-- so the old system could not be replaced until the workflow was redesigned, tested, and running with the new service provider.
Increased coupling and dependency between systems.
Application niche is a very regular system -- unlike, say -- medicine.
.Close
. 2009-05-05 Tue May 5 11:02 Server crashed on Monday
The web server went down yesterday. I've restored as much of
the web site as I can.... But some [Buttons] on these
pages do not function. You can search OK. But you can not
use the [Contact] button to send me a message.
Neither can you send me formatted contributions.
Meanwhile use EMail to my CSUSB address.
. 2009-05-04 Mon May 4 16:11 Lost Information
We just lost information on the web server.... it will take me
a while to recover stuff from my back up system. This includes the
tools and pages that let people make contributions. Plus the previous
two archives for 2008 and 2009.
. 2009-05-01 Fri May 1 13:28 John Brunner -- The Shockwave Rider
In a linked data structure horrible things happen if a link is lost. On the web, a bad URL
can lead to "404" and the resource can be lost. However, if someone does not link
their work to previous work there are few obvious effects. Slowly, however the quality of
discipline will fall as it looses its history. So one of the conscious aims of this blog
and the consolidated bibliography behind it is to enable connections to be preserved. Here is an interesting
case history: an idea in an SF story in the 70's is now a technology that thousands are sharing.
Reading a couple of articles on Prediction Markets (Wikipedia
.See http://en.wikipedia.org/wiki/Prediction_markets
.See Goth09
below) and crowdsourcing
(Wikipedia
.See http://en.wikipedia.org/wiki/Crowdsourcing
.See Hoffman09
below)
in the latest Communications of the Association
for Computing (ACM),
reminded me of John Brunner's prescient SF novel, see
.See Brunner75
below. This novel looked
forward to a nationwide network with "worms"( as constructed by
.See SchochHupp82
below) and "Delphi boards" here a collection of people make predictions about things they don't know
and if enough of them take part.... the predictions (according to Brunner) cluster round the
what happens. More the government (in the novel) uses a totalizer/stock market where you can bet
on ideas -- so that the odds can be used to predict the future.
Here are a couple of quotes from my copy of the novel to show what Brunner imagined back in 1974.
.Box
page 16. HOW TO GROW DELPHINIUMS.
It works, approximately, like this.
First you corner a large -- if possible, a very large -- number of people who, while they've never formally studied the subject you're going to ask them about and hence are unlikely to recall the correct answer, are nonetheless plugged into the culture to which the question relates.
Then you ask them, as it might be, to estimate how many people died in the great influenza epidemic which followed World War I, [...]
Curiously, when you consolidate their replies they tend to cluster around the actual figure as recorded in almanacs[...]
[...]
Well if it works for the past, why can't it work for the future?
[...]
Page 39 [...] he stood surveying the high-slung display, tracking the figures with the ease of much practice. He looked first at his favorite sector, social legislation, and was pleased to see he had two won bets to be collected shortly. [...]
.Close.Box
.Open Brunner75
John Brunner
The Shockwave Rider
Harper & Row 1975 ISBN 0-060-10559-3
=NOVEL SF NETWORK WORMS PREDICTION MARKETS TARNOVER TOFFLER
Wikipedia
.See http://en.wikipedia.org/wiki/The_Shockwave_Rider
Review 1976
.See http://doi.acm.org/10.1145/1095302.1095305
.Close
.Open SchochHupp82
John F Schoch & Jon A Hupp
The "Worm" programs -- early experience with a distributed computation
Commun ACM V25n3(Mar 1982)pp172-180
.See http://doi.acm.org/10.1145/358453.358455
=DEMO WORM NETWORK
Refers to
.See [Brunner75]
in a footnote and records the transition from a novelist's idea of a "Tape worm" to a practical technology.
.Close
.Open Goth09
Greg Goth
Betting on ideas
Commun ACM V52n3(Mar 2009)pp13-15
.See http://doi.acm.org/10.1145/1467247.1467252
=ARTICLE PREDICTION MARKETS IOWA IEM PROBABILITY DELPHI
.Close
.Open Hoffmann09
Leah Hoffmann
Crowd Control
Commun ACM V52n3(Mar 2009)pp16-17
.See http://doi.acm.org/10.1145/1467247.1467254
=ARTICLE CROWDSOURCING STATISTICS
Many minds make lite work.... wide band delphi
.Close
. 2009-04-30 Thu Apr 30 17:26 Programming has got better
I have suffered most of the things in this article
.See http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9132061
(Computerworld article found on slashdot), or even worse ones.
. 2009-04-29 Wed Apr 29 13:01 Microsoft Chases after the Verification Bandwaggon
I had assumed that formal verification of programs was a fairly dead technique. I used it
with success in the 1970s, and then watched it become fashionable in the 80's and then disappear
into the sunset during the 90s. But now MicroSoft has developed a Language
.Key Spec#
.See http://research.microsoft.com/en-us/projects/specsharp/
with compilers (Boogie) and other tools that fit
.See ./samples/methods.html#design_by_contract
into the Visual Studio environment and C#. I've checked out the PowerPoint
presentation and it has all the examples that we used use when
.Key program proving
was taught 20 years or more ago plus the later work by Bertrand Meyer.
I'll have to watch this since I'd like to teach students to produce program that are guaranteed to work again.
I had forgotten that one of the great practitioners of computing in the 1960s -- Tony Hoare -- was a
persuasive advocate and inventor of formal methods.
He spoke to the motion the "Algol 68 is not an Algol-like Language" in a sold out debate in London at
the time. He is now with Microsoft.
.Open Shustek09
Len Shustek (Ed)
An Interview with C. A. R. Hoare
Commun ACM V52n3(Mar 2009)p38-41
.See http://doi.acm.org/10.1145/1467247.1467261
=HISTORY HOARE PROGRAM PROVING MATHEMATICS THEORY ALGOL60 STRUCTURED CSP
.Close
. 2009-04-27 Mon Apr 27 13:39 Complexity confronted
Here are a couple of papers presenting solutions to the kind of complexity
that happens when we move from sequential systems to non-sequential ones. Problems
arising for coupling systems that run in parallel. One solution technique is to construct a special
algebra that models the properties of interest -- these tend to be variations of
.See ./maths/math_73_Process_algebra.html
-- and show how they make the calculation of desirable properties feasible. Another approach is
to create new formalisms and concepts that have the same effect. Here are the two recent papers
that illustrate these approaches in wildly different areas.
.Open YeCheungChanXu09
Chunyang Ye & S C Cheung & W K Chan & Chang Xu
Atomicity Analysis of Service Composition across Organizations
IEEE Trans Software Engineering V35n1(Jan/Feb 2009)pp2-28
=DEMONSTRATION MATHEMATICS PROCESS ALGEBRA ALGORITHMS BPEL UML Activity diagrams
How to be sure that the combination of several independent processes, linked by services, are atomic --
they either happen or they have no effect -- despite not knowing all the private details and
using exception handling.
Distinguishes process that are "compensable" and "retriable".
Defines a special process algebra for tracking and computing the atomicity of combined processes.
Demonstration of supply chain and insurance examples.
Experience shows more accuracy than previous attempts via projecting or abstraction.
.Close
.Open ZaveCheung09
Pamela Zave & Eric Cheung
Compositional Control of IP Media
IEEE Trans Software Engineering V35n1(Jan/Feb 2009)pp46-66
=DEMONSTRATION COMPLEX DESIGN NON-SEQUENTIAL MEDIA TELEPHONY PBX SIP IMS flowLink HoldSlot
Usually the channels used to send media through a network are independent of the signalling channels.
This makes it difficult to design protocols and systems that work correctly.
Proposes a couple of abstractions that help: flowLink and holdSlot.
.Close
. 2009-04-24 Fri Apr 24 13:57 Looking backward before leaping forward
I have a student who is willing to work with me to improve this web site.
As a starting point he needs to know something about its vision and
structure.
This blog is just the tip of the iceberg. A lot of my academic work is
publically available on this web site. So first some notes on the
vision -- a repository of information for students and faculty for
my teaching and my research on software development and the MATHS
language that came from that research.
Here is the concept I used to set up my website, some years ago.
Academic life has three components: Teaching, Professional Development (Research), and Administration.
The implementation was by directory within the website. To help avoid the "Lost in Hyperspace"
problem I thought to use background colors for the different components. I also provided
"crumbs" indicating where you were.
I choose a very pale yellow for teaching (this has become white over time),
and a pale blue for research -- especially for MATHS.
.See http://cse.csusb.edu/dick/maths/
Pages that could be useful for students (teaching) and were
based on my research would be green
.See http://cse.csusb.edu/dick/samples/
But I also used green for publications and presentations
.See http://cse.csusb.edu/dick/papers/
I used pink for personal pages. But again these have beome paler and so white.
I've never chosen a color for Admin.... most of it is personal and/or private in any case.
One idea was too cumbersome ... as one got deeper into the web site I thought the background might become
more intense.
Other thoughts -- sticking to a solid subset of HTML and no fixed font sizes -- maximize the number of people
who can use it.
I also had this idea of a "StarTrek, the next generation" theme.
One problem that completely blind-sided me was the length of pages. Most have too much content. Too much
scrolling. Look too complex and off-putting.
Now for some notes on the way I structure the web site.... and some
of its content.
I rely heavily on the UNIX/Linux file system to separate the different
areas.
Here is an annotated list of the main live directories. Several of them
have subdirectories (shown...). I've organized them by function.
.List
Admin
.See ./25th
Celebration of dept 25th anniversary
.See ./seminar
Research
.See ./andor
Work on And/Or tables
.See ./maths
.See ./monograph
.See ./notes
Notes on some bibliographic items
placed in "newbib.html".
.See ./papers
.See ./publications
.See ./samples
Samples of the MATHS language -- languages, methods, etc
Service
.See ./bin
.See ./c++std
.See ./doc
Documentation -- archive of newsgroup FAQ mainly
.See ./examples
C++ code
.See ./src
.See ./SRS
Software Requirements specification
.See ./tools
Mainly scripts
Teaching
.See ./cs201
.See ./cs202
.See ./cs320
.See ./cs330
.See ./cs360
.See ./cs372
.See ./cs375
.See ./cs488
.See ./cs489
.See ./cs546
.See ./cs556
.See ./cs595
.See ./cs599
.See ./cs620
.Close.List
Each directory determines the standard header and format for HTML files in
that directory.
. 2009-04-22 Wed Apr 22 18:10 Architecture and Experience
There has been a lot written about software architecture since Tom Gilb and others started
to use the term in the late 1970's. I've always been a little suspicious of the subject -- from the
definition of the term thru to the various theoretical approaches.
The paper
.See Matsson09
below, describes the area well and then goes on to describe a particuar, large scale and difficult
project that attempted to use Model-driven Development with a specific
architecture. The MDD part worked and ment that designs were easily mapped into code using tools.
However there was no way to state and enforce the rules that the designs had to follow to fit
the required architecture.
.Open Matsson09
Anders Mattsson & Bjorn Lundell & Brian Lings & Brian Fitzgerald
Linking model-driven development and software architecture: A Case Study
IEEE Trans Software Engineering V35n1(Jan/Feb 2009)pp83-93
=EXPERIENCE MDD ARCHITECTURE RULES UML Rhapsody RUP EMBEDDED RISKY Combisoft Saab
The abscence of a formal ay to record architectural rules lead to extra effort being involved
.Close
. 2009-04-21 Tue Apr 21 13:56 Estimation
Trying to estimate the amount of effort needed to complete a software development project is difficult -- if not possible. The whole idea is based on the concept that one knows what a project is before we complete. Whereas, in many projects their is an element of research to add to the development -- things are discovered as the project is worked on. I can well remember, on the 31st of August in 2002, outside the "Duke of Marlborough" pub, in London, searching for a book -- it wasn't in Foyles (an excellent source for technical and mathematical obscurities) or in Waterstones near London University, .... and my last chance was the Science Museum in Kensington ... 40 minutes away via the underground and a long tunnel. I realized that I should have made some phone calls first. And vowed that I would always, in future, make the first step in any plan, a step to reduce the uncertainties in the project. But --
.Key Risk driven development
is now a commonplace in newer processes like
.Key RUP
(Rational Unified Process).
However my experience in 1967-68 developing a program to analyze the statistics of mixed distribution --
.Key Placebo Reaction Model
-- should have told me what I needed to know. I tried to use Critical Path Methods but in the middle of the network was the equivalent of "Here a Miracle Happens". It all turned on whether I could solve a particular problem or not. Without an answer to this question there was no way to predict how long the programming would take. I recently checked back on this field and people are still trying to come up with solutions....
Meanwhile, lots of research is taking place on estimating software projects. According to
.See JorgensenBoehm09
most research is into formula that claim to predict the effort needed in terms of project data,
even though most teams tend to use expert judgement instead.
.See DemirersGencel09
discuss unified and improved methods for measuring the (expected) size of software --
.Key Function Point Analysis.
.See HeartyFentonMarquezNeil09
Advocate a Bayesian network to predict
.Key velocity in XP
-- I've always liked the XP planning game because it is a ritualize negotiation between two experts, the programmer and the client, about what is the best mixture of features to implement later.
.See Jorgensen09
writes about techniques for spotting over-optimistic bids for software development.
So -- estimation -- in many forms is still a lively research topic, as well as something that all developers find themselves having to do.
.Open JorgensenBoehm09
Magne Jorgensen & Barry Boehm
Software Development Estimation: Formal methods or expert judgement
IEEE Software Magazine V26n2(Mar/Apr 2009)pp14-19
=DEBATE ESTIMATION COCOMO
.Close
.Open DemirersGencel09
Onur Demirors & Cigdem Gencel
Conceptual Association of Functional Size Measurement Methods
IEEE Software Magazine V26n3(May/Jun 2009)pp71-78
=CASESTUDIES ESTIMATION FPA FSM UM
.Close
.Open HeartyFentonMarquezNeil09
Peter Hearty & Norman Fenton & David Marquez & Martin Neil
Predicting Project Velocity in XP using a learning Dynamic Bayesian Network Model
IEEE Trans Software Engineering V35n1(Jan/Feb 2009)pp124-137
=EXPERIENCE XP ESTIMATION BAYES BN PV
.Close
.Open Jorgensen09
Magnes Jorgensen
How to avoid selecting bids based on overoptimistic cost estimation
IEEE Software Magazine V26n3(May/Jun 2009)pp75-84
=THEORY ECONOMICS COSTS ESTIMATION BIDDING
.Close
. 2009-04-17 Fri Apr 17 11:14 Something I would like time to try out
Here is a report of how a software development company used open source methods and tools.
.Key Source forges
sound very attractive. I've been tracking Open Source projects in the literature since 2000.
For example
.See [Ambler00j]
reported on some source forge systems.
You can search for "OPEN SOURCE" and find 20 or 30 citations.
The evidence I'm seeing from those who have put an open source process with tool support is that they seem to provide teams with the benefits that individuals got from GUI tools and software IDEs. If there is a niche for "source forges" then it is in research projects rather than finished market-ready projects. And like most open source projects (in house or out sourced) the developers have to overlap with the users -- usage motivates the growth of features and the fixing of bugs.
Perhaps my department should have our own internal source forge for developing student projects?
I would like to spend time contributing to an open source project. But
I don't seem to have time to do so. I'd also like to shift some my tools into an open source mode before I retire.
I checked out
.See http://sourceforge.net
and searched for my particular interests in mathematics and logic.
I found several
projects (
.Key HOL
.See http://sourceforge.net/projects/hol/
and `mathdevlanguage` for example) which are on the system but effectively dead. There are several in the long tail of projects with one or two developers and even fewer users. Which is the rather sad state of my $MATHS project.
However developing traditional software through the early research phase seems to work well with an in-house
source forge.
.Open RieheleEtAl09
Dirk Riehle & John Ellenberger & Tamir Menahem & Boris Mikhailovski & Yuri Natchetoi & Barak Naveh & Thomas Odenwald
Open Collaboration within Corporations Using Software Forges
IEEE Software Magazine V26n2(Mar/Apr 2009)pp52-57
=EXPERIENCE OPEN SOURCE DEVELOPMENT SourceForge RESEARCH PROCESS
Reports on the successful us of internal source forges in SAP, IBM, etc., to develop nsoftware -- mainly research projects.
Principles: Egalitarian Meritocracy & Self-organization.
Contrast with assigned work, status, and imposed process.
A Source forge provides an easy way to discover projects that are going on and join them.
It provides tools for collaboration with many different views of different artifacts.
Each developers has a dash board displaying the status of the projects they are working on.
Benefits: volunteers, motivation, better quality, broad expertise, Wins support and buy-in. Better researc-to-product transfer.
.Close
. 2009-04-15 Wed Apr 15 11:53 Modelling parallel systems
Over the last 4 decades we have developed several disciplines for
analysing and design parallel systems. I've just seen a new
text book on the topic. You can find out short formal descriptions
of the algebras involved in my
.See ./maths/math_73_Process_algebra.html
page. The book uses a new language/algebra called \mu_CRL.
.Open Fokkink07
Wan Fokkink
Modelling distributed systems
Springer 2007 ISBN 978-3-540-73937-1 QA76.58 F65
=TEXT NONSEQUENTIAL FORMAL microCRL ACP DATA TOOLS \mu_CRL
.Close
. 2009-04-14 Tue Apr 14 09:55 A Persistent Question -- does it work
One persistent problem with software has been how you know that it is working. I was reminded of this while reading a paper on automating business processes ($RobinsonjPurao09 below) and service oriented architecture.
When I learned to
program in the 1960s we did a lot of testing. We could also tag statements in our program to either provide debugging data or not provide it. In some platforms you could go to the console and push a button or
flip a switch and a flood of data would come vomiting out of the tape printer or clattering onto the teletype. In less friendly form you would ask the operators to compile in the "traces" or "query prints"
and then have to flip a virtual switch inside the code as the program run. I can recall an embarrassing run where I got the switch backwards. I thought it would start to print about 100 statements before the program crashed. But know, I got the logic twisted, and turned off the trace 100 statements before the bug. I had
enough useless printout to keep me in scribbling paper for another 3 months... Looking back on that particular summer internship.... I'm surprised they offered me a job when I finished.
Notice that the focus was on a temporary source of information on the internals of the code. When testing you could spend the extra CPU (and printer) time to see if all was well with the code as it ran. Once tested you would remove the tracing and run the program at full speed. Given the speed of CPUs in those days this made sense.
During my graduate work I discovered Floyd's ideas
.See [Floyd67a]
about invariant assertions and discovered that given extra time I could prove that certain properties were always true. I didn't have to waste CPU time to monitor them. Since the hardware was delayed while I got on with programming I had time to insert all the needed "annotations" all thru the machine code that I produced and prove that once true they could never be false.... This part of the system never failed. But we are talking of about a days worth of thinking, algebra, and logic for each 50 instructions.
Fast forward to the 1970's and C. The idea of tracing and invariant assertions merged in the C
library. This is now the C++ library. I didn't like it because it relies on run time monitoring rather than logic.... But something similar emerged for Ada. An extra language "Anna" was defined to record annotations -- invariant assertions:
.Open Krieg-BrukenerLuckman80
Bernd Krieg-Bruckner & David C Luckham
ANNA: towards a language for annotating Ada programs
Proceedings of the ACM-SIGPLAN symposium on Ada programming language 1980 pages 128-138
.See http://portal.acm.org/citation.cfm?id=948650
=IDEA ADA PROOF ANNOTATION Floyd INVARIANT ASSERTION
.Close
.Open LuckhamEtAl87
David C Luckham & Friedrich W von Henke & Bernd Krieg-Brukner & Alf Owe
Anna, a language for annotating Ada programs: Reference manual
Springer Verlag LNCS #260 1987
.See http://books.google.com/books?id=tybCNcTXmUkC
=LANGUAGE ADA PROOF ANNOTATION Floyd INVARIANT ASSERTION
"... applications include not only testing, debugging and formal verification of a finished program, but also specification of program parts during the earlier stages of requirements analysis and program design."
.Close
Someone found a way to compile them as a parallel task that monitored the program as it ran. This apparently ound bugs -- I don't have a reference to my source, I think it was in SIGPLAN....
Nowadays we have debuggers that provide many of the features I used in the 1960's onlu through a graphic interface. A lot easier. But I don't use them much. I find that a combination of logic and experience plus Test-Driven Development (with cassert) gets me to working C++ code pretty reliably. Work on the web relies on scripting languages and occasional self tests of my PHP pages.
Now the same problem has emerged at a new level. When you have a solution assembled, dynamically, from distributed pieces supplied by different enterprises how can you be sure it works. What do you mean: "it works". Here is a recent paper with some proposals:
.Open RobinsonjPurao09
William N Robinson & Sandeep Purao
Specifications and Monitoring Interactions and commitments in Open Business Processes
IEEE Software Magazine V26n2(Mar/Apr 2009)pp72-79
=IDEA SERVICE BUSINESS PROCESS MODEL UML SEQUENCE DIAGRAMS OCL TEMPORAL LOGIC REQUIREMENTS MONITORING
When many different components and/or actors provide services to each other ... with the network being
dynamically configured, one must define the interactions precisely and monitor to see if they
are being followed. For example, after a bill is sent to a customer, one expects to be paid...
UML Sequence charts can show the protocols: patterns of messages.
Add to this
.Key conditional commitments
(CC) with four parts
.List
The actor who is committed to bring something about: customer.
The actor who expects the the commitment: biller.
The statement that becomes true: customer send payment.
The conditions under which it becomes true: the biller billed the customer.
.Close.List
Proposes a temporal logic extension to the OCL with clause like "after time until time...", "always....", "never ...", "eventually ...",
By using existing logging service we can monitor the interactions and collect information on how well
commitments are being kept.
.Close
. 2009-04-13 Mon Apr 13 11:18 Eat the frog first
Diomidis recalls a recent experience developing
.See http://www.spinellis.gr/wpl
and comes to a conclusion that I've slowly adopted:
Tackle the risky bits early.
.Open Spinellis09
Diomidis Spinellis
Start with the most difficult part
IEEE Software Magazine V26n2(Mar/Apr 2009)pp70-71
=EXPERIENCE RISK DRIVEN
.Close
. 2009-04-10 Fri Apr 10 11:01 If this is the solution -- what was the problem
One of the life's persistent question is what some software developers where thinking
when the wrote the software. In many cases it is clear that they were thinking about the computer
not the users. This was especially true back in the "bad old days" before Graphical User Interfaces.
These days most software is designed to solve a problem for some class of user or other.
We have a ton of techniques for working with our clients, finding out what they need
(not necessarily what they say they want...), and coming up with solutions that work fairly well.
We developed methodologies that tried to force programmers to look at real people and their
problems write from the begginning.
.Key Systems Analysis
is coeval with the first computers in the 1940s. The key belief of
the discipline was that you should understand the system in which the problems are found
before you try to fix them. And it had a theoretical basis in Bertalanfy's General System Theory.
Systems Analysis became more rigorous with the structured methodologies of the 1970's: SSADM in the UK, Doug Ross's SADT, Gane & Sarson, etc. etc. All of these had to fight with the belief that you had to complete analysis (understanding the problem) before you wrote software. Seeing this only works where the problems are evolving slower than when the solutions can be installed... there was a tendency to abandon the analysis -- looking at the problems. Luckily Object-Oriented technology allows software to be highly modular so that a partial solution will remain pretty much untouched when later solutions are installed. Indeed there are strong arguments for going very directly from talking to the client to implemented code -- XP comes to mind.
We have had many methods and technologies that sit between analysis and Design. In Computer
Science they tend to be called a phrase with the word "Requirements". Thus we have the IEEE standards
for "Software Requirements Specification" (SRS) which includes a format that covers all the basis
.See ./SRS/
which my CSE department
.See http://cse.csusb.edu/
modified to use in every student project at the 500 and above levels. My problem with
this document is that is more focused on the solution than helping people solve problems.
Here is recent discussion of alternate ways of recording what user's want.
.Open RiedemannFreitag09
Catherine Riedeman & Regina Freitag
Modeling Usage: Techniques and Tools
IEEE Software Magazine V26n2(Mar/Apr 2009)pp20-24
=SURVEY USER PURPOSE REQUIREMENTS FORMATS TOOLS Use Case User Story Problem Scenario =ADVERT Use Scenario TABULAR
Good survey of strengths, weaknesses, and tools for documenting how (and why) software will be used.
Use_Scenario::=following,
.Net
Combines the information documented in other techniques.
Provides the user's problem and tasks as the context for their actions.
A narrative table with 4 columns: Key task with subtasks, User Action, System Reaction, Usage Requirements and design hints.
Can be embedded in systems like MS Visual Studio Team System 2008.
Development process should include interaction design.
Ref to W Dzida & R Freitag "Usability Testing -- the DATech Standard", in Software Quality... Ed M Wieczorek & D Meyerhoff 2001, pp 160-177
.Close.Net
.Close
Nowadays more and more systems are multimedia systems, and we have cheap tools for capturing mulitmedia information -- what users and clients are saying, what they are doing. The problem arizes in tracing back from the code to the reason for the code. So we have to
integrate multimedia into text based tools.
.Open GotelMorris09
Olly Gotel & Stephen Morris
More than Just "Lost in Translation"
IEEE Software Magazine V26n2(Mar/Apr 2009)pp7-9
=IDEA MULTIMEDIA REQUIREMENTS TRACEABILITY
Need to elicit, record, analyze, and document requirements that include audiovisual records, videos, etc.
These, in turn, have to be linked to design decisions and artifacts
.Close
. 2009-04-08 Wed Apr 8 12:16 Busy times
I was sick over the break and now have two large classes to teach.
I will announce my schedule by the end of the week.... I hope.
Meanwhile I've just noticed a new language --
.Key Groovy
.See http://groovy.codehaus.org/
There will some more on Groovy later since it is turning up in Comm ACM...
. 2009-03-27 Fri Mar 27 14:44 Making Research Useful
It is end of the Winter quarter at CSUSB, the students are leaving, the pigeons are
nesting, and this blog will take a break until the evening of April the 6th.
Meanwhile,
here is an interesting suggestion: research should be evaluated, not just for accuracy
and correct procedure, but also for its applicability. This would mean I would have more stuff to write about here -- it easy enough to find unsubstantiated recommendations for new tools and methods, and also easy to find rigorous research that doesn't mean much in practice. I try, in this
blog, and its growing bibliography on results that are both reliable and practical.
.Open Glass09
Robert L Glass
Making research more relevant while not diminishing its rigor
IEEE Software Magazine V26n2(Mar/Apr 2009)pp96+95
=SURVEY 2 PAPERS RESEARCH PROCEDURE
Michael Rosemann and Iris Vessey propose that teams doin research in some area
should show their plans and their results to practitioners who carry out a reality check.
They proposed this in "Toward Improving the Relevance of Information Systems Research to practice: the role of applicability checks" [MIS Quarterly (Mar 2008) pp1-22] and in the 2005 "European Conference on Information Systems".
.Close
. 2009-03-25 Wed Mar 25 18:47 Reading and this Blog
This blog came out of my need to save what Krutchen (below) calls "fieldstones".
Pointers to things I have read and did not want to forget.
My first bibliography was done
for my Ph.D. and used small note cards, I still have it. I still remember the
care I used to minimize the amount of typing, while still letting me to
rapidly retrieve items on various topics. It was my first data base design.
In the the early 1980s I started a bibliography
on software development for a book on "Engineered Systems Software".
I added references to my reading for another book -- a monograph
.See ./monograph/
on software development methods. I moved this from a word processor file to
a Macintosh Hypercard stack and added some search and data mining features that
I've yet to duplicate in the current version. I wrote a script that dumped the
bibliography to a file in my $MATHS language... and so put it on this website
with a simple search engine or two. It is 2.5Mbs now.
As I enter new items into the bibliography, I report on them in this blog.
So this little posting of mine includes a citation that will be copied
into the bibliography:
.Open Kruchten09a
Phillippe Kruchten
You are what you read
IEEE Software Magazine V26n2(Mar/Apr 2009)pp10-11
=ESSAY READING RETAINING HOWTO
Software development knowledge has a half-life of about 5 years -- 50% of today's
knowledge will not needed in 5 years time.
Value of reading -- not just Googling on the fly.
Set aside time to read web, journals, and books of interest.
Value of writing reviews.
Need to take note and store the notes.
Keep copies on hard-drive. Use file naming conventions.
Track where important books have been loaned. Prominent Labels.
.Close
. 2009-03-24 Tue Mar 24 08:40 Programmers code or design or both
I just discovered the following contribution to the debate on what the
propper function of a "programmer" is. Are they just "coders" converting some "Design"
artifact into the source code for the software, or do programmers do design as they
produce code. I wonder if there is any evidence one way or another works better.
Personally -- programming includes coding and other important concerns....
.Open Read03
Daniel Read
Software Design and Programmers
developer.* March 20, 2003
.See http://www.developerdotstar.com/mag/articles/read_designprog.html
=SURVEY CODING vs DESIGN XP
Notes that some see programmers as coders -- no design involved.
Others argue that code always includes design decisions.
Notes that agile methodists tend to think in terms of the design evolving
or emerging from the code+test+refactor+test cycle.
Also see
.See [WhittakerAtkin02]
that argues that software engineering texts do not mention code!
.Close
. 2009-03-20 Fri Mar 20 14:51 Not a good week
Sometimes it is the small things that foul you up -- both in real life
and in software development. All programmers (well all but a very
small number) have experience the effect of a missing sign in our code or
the "off-by-one" error. This week my real life provided some examples.
First to come to light was the fact that my iPod had lost all but too
of its Contacts. The chain of causality was as follows:
.List
Apple has decided that if you don't synchronize a particular Address book
then you want it deleted.
I had changed the synchronization rules to only synchronise one address book
with two items in it.
I did that because synchronization was taking forever....
Probably, this was when the iPod software was updated during synchronisation,
silently, with no warning.
.Close.List
Cure -- reset the synchronisation for Contacts and get all my phone numbers
and EMail addresses back.
Second, was discovering that my debit card had vanished. And here
is the causal chain for that:
.List
It fell out of my wallet, probably while getting on a bus.
The bus pass was in my wallet.
And the plastic holder of the debit card was worn and torn,
so that the card fell out easily.
And I had not fixed it.
.Close.List
So I've searched the areas by the bus stops, cancelled the card, repaired
the wallet, and found an
alternate place for the bus pass.
By the way -- this follows the classic list of fixes needed for any
problem:
.List
Band aid.
Repair.
Long term avoidance.
.Close.List
Finally -- after cancelling the debit card, I discover,
(going to synch my iPod) that I didn't have my special VDT/Computer
glasses at home. But I expected to find them in the bag I use to go to
class -- full of chalk, pens, pointers, etc. But they are not in my office.
Or in any of the rooms where I taught yesterday, or on any of the routes I
walked yesterday... Now I don't know how this happened but
I think a prime suspect is the battered ICSE tote bag I used. So,
I've just repacked everything from that bag into a red SIGCSE 2005 bag
that can be zipped closed.
Well -- typing this in bifocals is a pain.... so a bibliographic item
will be posted on Monday, with luck.
Thank you for listening.
TGIF!
And then I swept an old OReilly UUCP mug of my desk smashing it....
. 2009-03-19 Thu Mar 19 04:59 One size does not fit all
I've collecting examples and evidence that there is no one methodology or
process that handles all software development for 13 years now. If you search my
bibliography for "one.size" you'll get a couple of dozen references.
I think that
.See [Royce70]
in the 1970s was the first to make this claim.
In 1995 I presented a faculty seminar here at CSUSB
.See [Botting95b]
(HTML at
.See http://csci.csusb.edu/dick/papers/rjb95b.one.size.html
).
I ended up with a model distinguishing 8 different cases depending on the
number of competitors, the strength of the contract and the number of customers:
.Image http://csci.csusb.edu/dick/papers/rjb95b.fig7.gif [Box with 8 compartments]
Here is a table desicribing the same idea
Winning_devlopment_strategy::=following,
.Table Contract #Customers Few Suppliers Many Suppliers
.Row loose few Unique features Low cost+Quality
.Row loose many First to Market New features + Many releases
.Row tight few Proven Capable Low cost with fixed quality
.Row tight many First in takes risk Highest Quality
.Close.Table
So I'm pleased to see another article making the same case and making a new distinction between
"development methodologies" and "engineering methodologies".
.Open Anguela09
Andrew Anguelo
Software Methodology Wars (Viewpoint)
IEEE Computer Society Career Watch Mailing list (Mar 2009)
.See http://www2.computer.org/portal/web/buildyourcareer/careerwatch/vp4
=ESSAY PROCES METHODS DEVELOPMENT vs ENGINEERING ONE-SIZE ECONOMICS SHORT-TERM vs LONG_TERM
Quote
.Net
.Key Development
is based on iterations of trial and error in the absence of knowledge and
facts. It most often found in organizations that don't value their software
technology as a critical business asset and treat it as a necessary evil or
a cost of doing business. Business executives in these types of
organizations operate very much like those during the dot-com boom days.
Itbis based on iterations of trial and error in the absence of knowledge
and facts. It no surprise that today's more popular development
methodologies are based on principles that shun documentation, engineering
thought patterns, and encourage the use of loosely conceived ideas in
production environments under the guise of flexibility.
[...]
.Key Engineering
methodologies are much more methodical than development methodologies.
Consideration of past, present, and future, as well as adherence to
standards and practices are all core principles of software engineering.
Although not perfect, these methodologies facilitate the design of systems
with intent and that embody the characteristics of reliability,
maintainability, and scalability. Such results come at a price however.
.Close.Net
(dick)|- Ignores the claim that refactoring software can maintain the quality of software.
.Close
. 2009-03-18 Wed Mar 18 19:21 How to use off-the-shelf components
In the world of software development there are many theories -- and most of these theories are
.Key normative Theories
-- they state that developers should do something. Notice the `should` this is setting a norm -- hence normative.
Thus, for example:
.List
You should use top-down stepwise refinement.
You should place each design decision inside its own module.
You should only use the three D-structures.
You should use data directed design,
two versions, one in the 1970s and later in the 2000s.
You should use a object-oriented software.
...
.Close.List
Now it is much harder to come up with theories about what actually is. But here is an example which compares the use of "Off The Shelf" components in the classic normative theories vs what was actually done in some companies. Notice -- the research shows what is, and does not suggest what should be. These experimenters uncovered that previous "should"s do not match the real "is"s.
.Open LiConradiEtAl09
Jinguin Li & Reidar Conradi & Odd Petter N Slyngstad & Christian Bunse & Marco Torchiano & Maurizio Morisio
Development with Off-the-shelf Components: 10 Facts
IEEE Software Magazine V26n2(Jan/Feb 2009)pp80-87
=POLL COTS OSS OFF-THE-SHELF COMPONENTS PROCESS ECONOMICS METHOD
Companies don't change their process because they are using OTS components... they just add special integration steps.
Components are selected informally.
Components are integrated into a system both early and late in the process.
Estimates are base on personal experience.
OTS components usually don't degrade system quality.
OSS and closed proprietary OTS components are used the same way -- no rewriting the open source parts.
Locating and debugging defects is substantial.
The supplier is involved in more than bug fixing during maintenance.
Clients are not usually involved in OTS selection.
Knowledge about non-fucntional properties of OTS components must be managed.
.Close
. 2009-03-16 Mon Mar 16 18:18 The Why of Software
The following part of IEEE's latest Software magazine provides more
evidence for the need to make design decisions in a rational way and to
capture them for when the software is changed. The need is fairly obvious
even if the means for meeting the need is not clear. Can we embed the
reasonning behind a particular design into executable code as the Agile
hope, or do we need complex tool and language based on logic and philosophy
-- as tool vendors say. And what do you do when a large mass of monolythic
code has accumulated so much technical debt that you have to impose an
architecture on it? These articles touch on all of these and more.
.Open Zdun09
Uwe Zdun (Guest Editor)
Capturing Design Knowledge (Special Section)
IEEE Software Magazine V26n2(Mar/Apr 2009)pp25-49
=COLLECTION DESIGN TOOL METHOD ARCHITECTURE EXPERIENCE RATIONALE ARAL
Argues that between the requirements and the software comes a number of design decisions and
that the reasoning behind them may be lost.
Also notes that software rots if it is not looked after well.
Titles
.List
Capturing Design Knowledge
Modularization of a large-scale business application -- A CAse study
The Decision View's Role in Software Architecture Practice
Software Architecture Design Reasoning: A case for improved Methodology Support
.Close.List
.Close
. 2009-03-13 Fri Mar 13 15:31 It is Tool Time Online
If you want to know about websites about software engineering tools and
IDEs you can do better than the following
.Open Doernhoefer09
Mark Doernhoefer
Surfing the net for software engineering notes: Tool Time
ACM SIGSOFT SEN V34n1(Jan 2009)pp7-16
.See http://doi.acm.org/10.1145/1457516.1457519
=SURVEY TOOLS Eclipse NetBeans MySQL PostGresSQL Apache Tomcat JBoss Caucho Resin ArgoUML C# .Net Subversion CVS FindBugs PMD Pentaho W3C VALIDATION LINK CHECKER
.Close
. 2009-03-12 Thu Mar 12 06:03 This just in... Barabara Liskov wins Turing Prize
The source of the Liskov Substitution Principle for OO design
and languages has been selected by the Association for Computing Machinary's
most prestidgeous prize for 2009.
.See http://news.bbc.co.uk/1/hi/technology/7937010.stm
(Thank you Alexander)!
. 2009-03-12 Thu Mar 12 06:03 Samples/methods updated
.See ./samples/methods.html#ALD
.See ./samples/methods.html#iterate
. 2009-03-11 Wed Mar 11 19:03 SMOP -- Small Matter of Programming
I was planning to write about Michael Wing's quirky article showing how a simple C program
can generate many thousands of K of working code for a data base application.
Then I discovered that I didn't have a good example of the
.Key "Gang of Four" State Pattern
, and
that the Wikipedia seems to be stuck in a controversy of what it is. So when I got to
work this morning I sketched out a State Chart for a combined light and heater I met some years ago in
England... and by lunch time I had a UML Design Class Diagram
.See ./cs375/StatePatternExample.html
in Visio. Now, as part of teaching PSP last year I have a logging process running that collects statistics on all
files that I compile or render into HTML etc. So I know that I started coding the test at 1:04pm with 15 lines,
and finished with a 36 line test by 2:46pm. Meanwhile the actual code defining the classes
(all in one file ready for the web....)
.See ./cs375/State.cpp
had grown from 29 lines at 1:06pm to 141 lines by the end of the session at 2:46pm. So that is roughly
one line of tested code per minute. Then back to the drawing board to reverse engineer that discoveries back into
the UML diagram I had started with. Basically I added classes to output some behavior when exercised in the test program.
Conclusions: (1) Expressing the State pattern (at least this version) in C++ taught me much
about what must be defined
in a class before you can do certain things in it. It was like having my nose rubbed in the need to split
the headers from the bodies -- all over again.
(2) OOP is verbose.
(3) perhaps lazy evaluation might be better in this case -- each State class is a Singleton.
Note -- I have old code that creates a new State with each transition which causes a large memory leak. But that
was a $HHOS demonstration of concurrency -- four singers singing "Boom Ooh Yatata".... I may update
it to a better code later.
(4) Perhaps it is time to complete my dictionary
.See ./cs375/patterns.html
of patterns and principles.
So -- yes Software development is all about code -- but drawing the design first made the coding into a
SMOP -- Small Matter Of Programming.
.Open WingM09
Michael Wing
SE Means Programming
ACM SIGSOFT Software Engineering Notes V34n1(Jan 2009)pp5-6
.See http://doi.acm.org/10.1145/1457516.1457518
=DEMO CODE GENERATING CODE DRY CGWOP C Sybase DATABASE TRIGGERS
CGWOP::=`Code Generation without Parsing`.
Repetitive code should be generated by a program rather than written
.Close
. 2009-03-09 Mon Mar 9 19:03 Power laws in Software
I've been seeing a lot about `power laws` in networks for several years ago. Now
we have a thoruough investigation of the statistics of connections between modules
(classes, libraries, subprograms) accross a range of projects that demonstrates that these rules are
pretty ubiquitous. This implies, in turn that 80-20 lawers will fit as well -- the working rule
that 80% of the beer is drunk by 20 percent of the people is apparentlly confirmed by these
results.
.Open LouridasSpinellisVlachos08
Panagiotis Louridas & Diomedis Spinellis & Vasileos Vlachos
Power Laws in Software
ACM TOSEM Trans Software Eng & Methodology V18n1(Sep 2008)#2pp1-26
.See http://doi.acm.org/10.1145/1391984.1391986
published Sep 2008
=ANALYSIS CODE STATISTICS POWER LAWS MODULES CLASSES FUNCTIONS REFERENCES Java Ruby PERL TEX C++ Linux Fat Tail
One piece of code has a number of references to other pieces of code...
One piece of code is refered to or used by other pieces of code...
Suppose we tabulated how many refrences were made to or by a module to another then we get close to a simple rule.
In a
.Key power law
P( X = x) = c * x**(-k)
for some constant c and k>0.
Or equivalently we have:
P(X >= x) = c * x **(-(k+1)).
Compare
.See [ConcasEtAl07]
(not mentioned).
As a rule the distribution on references to a module has a smaller k and a better correlation.
The distribution of the number of references made by a module to others do not fit as well and k is bigger.
.Close
. 2009-03-06 Fri Mar 6 15:03 Network effects on Searching and marketting games
Here are two articles describing trends in our increasingly online life.
One describes how the network allows games to be published and marketted
publishers or advertising agencies. The other describes the increasing power of
one search engine and why this raises ethical questions. Both are about
the right for anybody to get access to everybody. Very much the area carved out
by Clay Shirky, See
.See [Shirky03]
and
.See [Shirky08]
for example.
.Open SwainC09
Chris Swain
Who Needs a Publisher or a Retailer or a Marketeer
IEEE Computer Magazine V42n2(Feb 2009)pp103-105
=ESSAY OPEN MARKETS ECONOMICS iPhone apps Xbox Live Community Valve Software Steam
Risks of your product disapearing in a flood of others... iPhone has 10k apps already.
Hence many cheap and simple apps... complex apps may not get the exposure to
make a profit.
.Close
.Open MowshowitzKumar09
Abbe Mowshowitz & Nanda Kumar
And Then THere were Three
IEEE Computer Magazine V42n2(Feb 2009)pp108+106-107
=ESSAY NETWORK SEARCH ENGINES MARKET ECONOMICS MONOPOLY KNOWLEDGE GATEKEEPER LEGAL ETHICS
Can Google be sued for not showing a relevant page to people looking for it?
.Close
. 2009-03-04 Wed Mar 4 18:03 History of Barcodes
Another intriquing tour through technological history demonstrating the
almost arbitrary, and totally unromantic ways that some technologies come to be
and then are mainstreamed.
.Open Grier09
David A Grier
Scanning the Horizon
IEEE Computer Magazine V42n2(Feb 2009)pp8-10
=HISTORY RETAIL SYSTEM UPC BARCODE ECONOMICS SYSTEMS THINKING
.Close
. 2009-03-02 Mon Mar 2 20:03 Trying to envisage agile software development
It is interesting how hard it is to learn iterative and evolutionary methods. No amount of examples and
descriptions seem to help. So I thouhght for a while and came up with the analogy of eating a large
cake
.Image http://www.go-at-home.com/images/recipes/Died-and-Gone-to-Heaven%20Chocolate%20Layer%20Cake.jpg [A cake]
To get the real cake try the recipe at
.See http://www.go-at-home.com/recipeDetail.asp?RecipeID=865
(I haven't tried it.....)
Now in software cevelopment it is more like this
.Image ./cs375/cake2.tiff [3layered cake = requirements+design+code with tests on top]
Now some people just like to eat the top part: coding and testing and hoping that omitting the design and
requirements analysis can be ignored.
According to the dogmatic "waterfall" model we take it alyer by layer:
.Image ./cs375/cake2fragile.tiff [Layer by layer, bottom up]
But the agile/iterative/evolutionary methods are more like we normally eat a cake: one slice
at a time, each slice with a bit of requuirements, a bit of design, and a bit of coding.... to say nothing
of a cherry on the top = tests.
.Image ./cs375/cake2agile.tiff [Slice by slice]
Now this doesn't prove anything.... but it may make the difference between the different approaches
clear. Let me know what you think....
. 2009-02-25 Wed Feb 25 20:02 TeX MathML MATHS -- Mathematics on the web
This rant comes (1) from reading Brian Hayes article on the start of the art of displying mathematics on web pages -- summary: not good, (2) From getting a thesis in my Email for reading and comments -- in \TeX and rediscovering that I don't have access to a functional system for viewing such documents, and (3) my own attempts, for most of my career, to formulate a system for encoding logic and mathematics using ASCII.
Using Donald Knuth's \TeX gives elegant and intelligent layouts for formula, equations, chapters, sections, subsections, contents lists, and so on. All very laudable in a world of paper and chalk board! But doesn't give me what I want:
.List
Hypertext links between: terms and definitions, labels and formulae, theorems and proofs, names of algebras and their descriptions,
A checkable proof system.
Access and linkages over the web.
Reuse and inheritance of logical/algebraic systems
.Close.List
Brian Hayes describes MathML and where that has got to. It is a verbose notation for formulae that is not honored by any "real" browsers. It does not provide the structures that I'm interested in for connecting formula into a narative: variables, axioms, theorems, etc. as far as I know so far.
My own attempts ($MATHS) are illustrated by the fact that I use the language for this blog
It uses standard HTML but is defeated by certain browsers. For example, one of Maxwell's equations is written like this in \TeX:
.As_is \nabla \times \mathbf{E} = -\frac{\partial \mathbf{B}} {\partial{t}}.
(This is in Brian Hayes's paper). To render it for a browser I'd have to translate the \TeX into a graphic and place it as
an image in this document, or include one of the server- or client-side tools Brian mentions. On the other hand, there is a lot to be said for writing papers in \TeX, going to the effort of installing a LaTeX based set of tools, and learning \TeX.
In MATHS I write:
.As_is \nabla >< E = - \partial B / \partial t.
As you can see I stole the \TeX sysntax for encoding weird sysmbols.
My "mth2html" tool, or my
.See ./hole.html
web tool will render it into standard HTML (even Nabla is an HTML entity!) so that it looks like this
\nabla >< E = - \partial B / \partial t.
Now on many browsers it will be instantly readable but not a beautiful (I'm told) as the rendered \TeX
version. On the versions of MicroSoft Internet Explorer (and without some fonts?) the Nabla appears as a box.
So basically, we have a long way to go before we have the system that I dreamed about when trying to record my Formal Languages and Automata notes in computer readable form during my graduate work in the late 1960's.
.Open Hayes09
Brian Hayes
Writing Math on the Web
American Scientist V97n2(Mar-Apr 2009)pp98-102
=ARTICLE HTML \TeX TeX MathML JsMath FONTS techexplorer
Problems with putting formulae onto web pages.
Where to render the formula: author, server, or client?
Client: Plugin(techexplorer), fonts, special script (JsMath).
Rely on user having the plugins and fonts to work.
Server example -- Wikipedia uses `texvc`, MathTeX, MimeTeX. All make graphic images.
reliable and ugly.
How to render: as a graphical image or using Fonts or Unicode?
Failure of MathML to become mainstream.
(dick)|-Failure of \TeX to express hypertext markup.
(dick)|- No formal syntax and semantics for proofs and logic in \TeX or MathML
(dick)|- Still like my $MATHS language.
.Close
. 2009-02-23 Mon Feb 23 19:02 Visiting Speakers Wednesday
Date February 25th 2009 Time 12-2pm Location College of Education 110
.Box
12-1pm
.Key Yair Censor
is highly respected mathematician and a prolific researcher. Dr. Censor has published over 100 research articles in refereed scientific journals, conference proceedings and as book chapters. B He will be speaking on some recent work he has done on total variation (TV) algorithms entitled:
.Key Projection Methods: Perturbation Resilience and TV-Superiorization
1-2pm
.Key Gabor Herman
is an internationally renowned mathematician and computer
scientist for his work in image processing. B He was a pioneer in computed
tomography, and developer of the algebraic reconstruction technique (ART),
as well as several other reconstruction algorithms. B His talk will be on:
.Key Finitely Convergent Sequential Algorithms and Their Applications to Intensity Modulated Radiation Therapy
.Close.Box
Note: I've updated
.See [SaariluomaIsomki08}
on HCI design.
. 2009-02-18 Wed Feb 18 20:02 Busy Days
It's a kind of triple witching hour/day.
My university is in the throws of Spring Advising, I've chosen a form
of teaching that involves answering a lot of questions on web sites,
and I have had to prepare a review of the book cited below.
And as I typed the above, something broke betwen my DSL and the remote
login server on campus and killed the edit. Luckily I use an editor
that has a recovery function.
As to the book.... too much philosophy, and for details wait
for my reviews in $CR!
.Open SaariluomaIsomki08
P Saariluoma & H Isomki
Future interaction design ii (1st ed.)
Springer Publishing Company, Incorporated, 2008
=THEORY =EXPERIMENT =SURVEY PHILOSPHY USER HCI SOCIOLOGY GERONTECHNOLOGY ANTHROPOLOGY
.Close
. 2009-02-16 Mon Feb 16 16:02 Defects of current software technology
A well known authority -- he has appeared 14 times in my bibliography so far --
famous for distinguishing the orders of ignorance and
knowledge -- has just published an article on the defects of current tools. I've
been hoping and expecting to see a non-text based way of developing software
since the end of my graduate work in 1971. And here is the fact that worries me --
nobody has ever succeeded in mainstreaming a soup-to-nuts tool for developing
software. Many people have tried -- see some of the historical backfill in this
blog -- but none have displaced source code. Why? Are programmers so locked to
text that nothing else sells? Is it just that we don't have a good graphic representation
for software? Perhaps we need to able to work within a 3D virtual world to
model software properly? In fact it might be 2*`n` dimensional where `n` is the number
of parallel parts?
.Open Armour09
Phillip G Armour
The Business of Software: The Ontology of Paper
Commun ACM V52n1(Jan 2009)pp23-24
.See http://doi.acm.org/10.1145/1435417.1435427
=ESSAY DOCUMENTATION PAPER vs
Claims that the industrial revolution did not occur until steam engines were used
to create steam engines.
Claims that current software technology
tends to reproduce the defects of paper-based artifacts.
Describes the properties of paper artifacts:
difficult to link artifacts, not executable, not easily verifiable,
serial access, imposes a hierarchical structure,
places information within a linear context,
inherently single-tasking, ...
Even hypertext does not relax these constraints.
Claims that older systems fitted the paper model well.
New systems need the external linkages and executability of software.
.Close
. 2009-02-13 Fri Feb 13 09:02 Human Computer Interfaces and Psychology
One of the purposes of this blog and bibliography is stop the way
we continuously bury past experience -- even when published.
I've been reading a book (more on that later) that claims that the
time (2009)
has come to apply scientific psychology to interaction design. It took a
while to find the spirited discussion of this topic in the Communications of
ACM back
in 1982.... but here it is. I'm taking this opportunity to update the
bibliographic item for the original article by Barry Dyer.
.Open McMahon82
A M McMahon
Behavior Modification in Programming (Forum)
Commun ACM V25N6(Jun 1982)pp400-401
.See http://doi.acm.org/10.1145/358523.358556
=LETTER USER CRITIQUE BEHAVIORISM PEOPLE HCI BEHAVIOR MODIFICATION
Doubts the morality of behaviorism in HCI as expressed in
.See [Dwyer81]
.But
Using behavioral psychology in HCI is like an automobile engineer using a jointed wooden dummy.
By using it people started to like my work.
"Systems that are aversive to users are destined to fail, even if they are technically perfect."
Common false assumptions: People are rational, Computer save work, users out to wreck the system, computer diagnostics spot the problem
.Close.But
.Close
. 2009-02-11 Wed Feb 11 20:02 Ethical Dilemmas
Here is a nice essay on the ethical dilemmas that confront software developers. It also notes that many developers are not members of the two main professional software bodies: the ACM and the IEEE -- and so are not bound by their codes of ethics.
There is something horribly familiar about their list of defective behavior patterns.
.Open BerenbachBroy09
Brian Berenbach & Manfred Broy
Professional and Ethical Dilemmas in Software Engineering
IEEE Computer Magazine V42n1(Jan 2008)pp74-80
=ESSAY ETHICS NAMEs DILEMMAS MITIGATION IEEE ACM
Named dilemmas
.List
Mission impossible
Mea Culpa
Rush Job
Not My Problem
Red lies
Fictionware versus vaporware
non-diligence
Cancelled vacation
Sweep it under the rug
.Close.List
Proposes mitigation strategies.
Failures of the ACM and IEEE Codes of Professional Behavior.
Notes likely criminal behaviors: Negligent homicide, reckless endangerment, depraved indifference.
Ethical dilemmas tend to be yoked, chained, or coupled.... and this magnifies the damage.
.Close
. 2009-02-09 Mon Feb 9 18:02 Meetings
Phillipe Kruchten's latest article in IEEE Software on meetings gives me a perfect excuse to revisit two of my favorite books and a recent acquisition on the same topic. Kruchten's article is based on Robert's Rules of Order... a book I have yet to read without falling asleep. However the rules of procedure for meetings is a fascinating study.
When I was at college in the 1960's the Student Union rewrote its constitution and we spent many hours discussing "Standard Orders" -- the default procedures for meetings of the student union committees and of all its clubs and societies. The Philosophy Club for example always made use the Standing Order that let Standing Orders be suspended if enough people voted for this motion to open a free and unstructured discussion (typically in a pub). My first or second publication (in the Student paper) demonstrated that a simple automaton could track the state of a meeting under "Standing Orders" and noted the
need for a set of stacks to handle points of order being made about points of order....
But I cut my teeth on Parkinson's little essays on how organization grow and fail, and his advice on how to succeed. I've learned that satire and humor contains a lot of clues to the truth.
And then last week I picked up Stephen Baker's description of why he hates meetings.
I will not go into all the specialized types of meetings I have noted over the years. Perhaps another day.
.Open Kruchten09
Philippe Kruchten
When Robert Rules
IEEE Software Magazine V26n1(Jan/Feb 2009)pp20-21
=PRINCIPLES MEETINGS GROUPS PEOPLE MANAGEMENT PROCESS
Source
.See http://en.wikipedia.org/wiki/Robert%27s_Rules_of_Order
(Henry M Robert, 1837-1923)
Principles
.List
Scope the meeting: agreed and prioritized objectives.
Tackle one issue at a time. Focus on pro and con of one proposed idea.
Get Closure on issues. An agreed conclusion. (1) evolves (2) Ratified.
Be flexible. A way to modify a proposal.
Know when to stop or defer a decision.
Remember what was decided. Minutes or other artifacts.
Know how to undo a decision. Rescind.
Dealing with difficult situations. Need chair/facilitator. Points of order. Politeness, Address the topic not the people.
.Close.List
.Close
.Open ParkinsonCN58
C Northcote Parkinson
Parkinson's Law or the Pursuit of Progress
John Murray London England 1958
=JOKES CLASSIC HHOS BRILLIANT MUST READ PEOPLE HISTORY MANAGEMENT
|- (ParkinsonsLaw): Work expands to fill the available time.
The time spent on an item in a committee is inversely proportional to the cost.
When an enterprise moves into a custom-built head-office it is dead.
Incompetence is determined by the age of retirement and starts 5 years before.
The outcome of a meeting depends more on the seating than on the merits of the opposing views.
Surround weak people with your own people....
Also see
.See [ParkinsonCN62]
.Close
.Open ParkinsonCN62
C Northcote Parkinson
In-laws and Outlaws
John Murray London England 1962 + Penguin 1965
=JOKES HOWTO NONORIGINATION EXPERTISE PUNCTUOSITY CHAIRMANITY PAPERWORK MEETINGS
Demonstrates that it is best to get your superior to have your brilliant ideas.
Shows how to take advantage of people being late and how to plan:
Work backwards from the most important event, subtracting the durations as you go.
How chairpeople get their will: Inanimism, Blahmanship, Browbeatnicism, Confusionism.
How to try and handle the tsunami of paperwork as you get promoted.
Do you have what it takes to be CEO? Can you sack a really nice person who is incompetent and still sleep at night?
(ParkinsonsThirdLaw): Expansion means complexity and complexity means decay.
.Close
.Open BakerLevin83
Stephen Baker & Arnie Levin
I hate Meetings
Macmillan NY 1983 ISBN0-02-506370-7
= JOKES PEOPLE MANAGEMENT MEETINGS
Good explanation why people hate meetings.
Confirms purpose of meetings: too spread the blame/responsibility widely.
Chapter 8: good field guide to problem people from the chair's point of view:
Speech maker, Yawner, Bottom liner, Devil's advocate, Early leaver, late-comer.
.Close
. 2009-02-06 Fri Feb 6 15:02 Open Source quality management and effort
Nice bit of statistical analysis of open source projects.
.Open CapraFrancalanciMerio08
Eugenio Capra & Chiara Francalanci & Francesco Merio
An Empirical study on the relationship among Software Design Quality, Development Effort, and Governance in Open Source Projects
IEEE Trans Software Engineering (Nov/Dec 2008)pp765-782
=EMPIRICAL ANALYSIS 75 OPEN SOURCE PROJECTS METRICS EFFORT PROCESS MANAGEMENT
In open source there is a continuum of governance practices.
Conclusion: Better quality code permits looser governance but that in turn takes effort to coordinate loosely governed people.
(dick)|- results are unlikely to happen by chance but the causality may be reversed.
.Close
. 2009-02-04 Wed Feb 4 18:02 Ontologies and the Tree of Porphyry
I'm a little cynical about attempts to nail down `semantics` without
reference to stuff outside the computer. So the `Semantic Web` will
surprise me if it arrives. However, this article on the ontologies
that have been and are been developed to provide `meaning` to web pages
had an interesting discovery it. Briefly, I have used a tree-like structure
as a theoretical semantics and/or ontology for 10 to 20 years -- purely
out of belief we had expand formal logic in the direction of natural
language.... Anyway this turns out to be ancient, dating back a
thousand or so years -- the Tree of Porphyry.
So here is the citation with links...
.Open Horrocks08
Ian Horrocks
Ontologies and the Semantic Web
Commun ACM V51n12(Dec 2008)pp58-67
.See http://doi.acm.org/10.1145/1490360.1409377
=POPULARIZATION WEB ONTOLOGIES SEMANTICS LOGIC RULES RDF OWL
Figure 2:the
.Key Tree of Porphyry
.See http://en.wikipedia.org/wiki/Tree_of_Porphyry
(Wikipedia) and
.See ./maths/http://csci.csusb.edu/dick/maths/logic_8_Natural_Language.html#Stuff
(MATHS)
RDF expresses labelled directed graphs: subject --(verb)--> Object.
What we used to call semantic nets in the 1970s.
.Close
. 2009-02-02 Mon Feb 2 20:02 Computer graduates and quality Requirements
So after years of forcing computer science students to accept the ambiguous
"specifications" that we use for programming exercises and do the best they
can with them..... is it any surprise that they miss defects in real
requirements?
.Open CarverNagappanPage08
Jeffrey C Carver & Nachiappan Nagappan & Alan Page
The impact of educational background on the effectiveness of Requirements Inspections: an empirical study
IEEE Trans Software Engineering V34n6(Nov/Dec 2008)pp800-812
=EXPERIMENT PEOPLE INSPECTIONS REQUIREMENTS
Provides good evidence of a couple of useful facts:
.List
People who have written requirements are better at finding defects than people who have not written them.
People with Computer or Software Engineering degrees are worse at find requirements defects than those who have other degrees.
.Close
. 2009-01-30 Fri Jan 30 15:01 Correction to previous blog item
OK.... I didn't mean to say that the people who taught me software development in the 1960's should have read a paper published in 1970.
Let me say what I was thinking.... I was taught to program, using
no method in a Stats class in 1964. Or more precisely, we wrote a simple
program, compiled it, ran it, wiped out the compiler and reloaded it,
retyped it, ran it, ..... and iterated from then on. In a Numerical
Analysis class I learned flow charting. Then into an industrial period
working for the Brittish National Physical Lab using Algol 60
to program a stats application and rocking a model boat (fun). No
flow charting stencils -- I should have started a company.... I wrote one
program and it took the whole 6 months... mainly debugging.
In my second industrial period (summer 1964) I monitored the progress of
my programs thru the classic: Analysis->Design->Code->Test-> Release
SDLC
and found that every one of them (with one exception) got stuck in the
"Test" phase. I decided that it was because I did not spend enough
time in the "analysis" and "design" steps.
Now I don't recall being taught the SDLC above. I did write
a report at the end of the period defining it as the standard
way to develop software.
Now, the key point: no online terminals, no PCs. A test run took
a minimum of 24 hours... in a worst case several days or a week could
go by before the operators could run a test for you. Production
work had to come first.
Hence it made a lot of sense in those days to put the efort up
front to try and minimize the number of tests.
Oh, for a time machine... Read on to the previous entry below.
. 2009-01-28 Wed Jan 28 19:01 The Myth of the Waterfall Process
I wish that the people who had taught me software development
and the "waterfall process" had actually read the following paper.
As it is I've only just found a facsimile on the web and
spent a couple of weeks studying it. I'm upgrading my
bibliography to match the description below. It looks as if
all data, even bibliographies, must evolve. And that
iteration is the best way to get an accurate result.
.Open Royce70
Winston Royce
Managing the development of large software systems
Proc IEEE WESCON (1970) pp328-339
.See http://www.holub.com/goodies/royce.waterfall.pdf
=HARMFUL WATERFALL PROCESS ONE SIZE ECONOMICS MANAGEMENT ITERATION PROTOTYPES TESTING DOCUMENTATION CUSTOMER USER
This is the seminal paper on software processes.
It has been widely quoted as proposing the "Waterfall Process"
when it argues that such a process does not work and proposes
alternatives.
p.335: "In my experience,however, the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed."
.List
Complete Program Design before Analysis and Design begins.
Documentation must be current and complete.
Do the job twice if possible.
Testing must be planned, controlled, and Monitored.
Involve the Customer
.Close.List
.Close
. 2009-01-26 Mon Jan 26 18:01 On the Evolution of software
I've just read David Alan Grier noting evolutionary fervor
everywhere --
.See [Grier08a]
in the IEEE Computer Magazine (Dec 2008)
plus an example
.See [DenningEtAl08]
(Communications of the ACM Dec 2008)
of using evolutionary development in a large USA government department.
Note: if you develop software for the USA federal government I think you
need to know about
.Key LTE
-- Limited Procurement Experiments!
Both are recommended.
Too say nothing of previously reported
.See HamiltonHackler08
.See Gabriel08
.See Martin09
that also praise evolutionary/iterative processes.
I was planning to write about switching from a Palm to an iPod... and that
got me back to a
paper I wrote on the evolution of software for a faculty workstation
.See [Botting85c}
but I decided to return to PDA functions topic after rescuing two other
papers from the
1980's demonstrating evolutionary/iterative processes. These were published in
a west coast regional conference on educational computing. It seems to have died.
The paper
.See [Botting84b]
demonstrates how I took a simple editor for my students
.See [Botting85a]
and made it easier to be used by repeatedly replacing error messages by guesses at what the
user wanted to do. I've taken these two papers and scanned them in through OCR software
and marked them up for my MATHS language and hence onto the web as
.See ./papers/rjb84a.FRED.html
(the Friendly edito) and
.See ./papers/rjb84b.Generalization.html
(Generalization - An Alternative to Error Messages).
Enjoy. Comment....
. 2009-01-23 Fri Jan 23 14:01 Speeding up your web site
Here is an article worth reading if you have customers complaining about
the speed of your web site
.Open Souders08
Steve Souders
High-Performance Web Sites
Commun ACM V51n12(Dec 2008)pp36-41
.See http://doi.acm.org/10.1145/1490360.1409374
=ADVERT HOWTO WEB/NET PERFORMANCE TUNING CSS SCRIPTS Javascript AJAX HTTP
Describes (briefly) 10 rules
.List
Make fewer HTTP requests
Use a network to deliver content
Add an Expries header
Gzip components
Put stylesheets at the top
Put scripts at the bottom
Avoid CSS expressions
Make Javascript and CSS external
Reduce DNS lookup
Minify JavaScript (remove whitespace...)
Avoid redirects
Remove duplicate scripts
Configure ETags
Make Ajax cacheable
.Close.List
More in the author's recent book...
.Close
. 2009-01-21 Wed Jan 21 19:01 Recent Writings on Writing
I've recently been studying three different explorations of code writing. Jeff Atwood
pointed out that coding is `just` writing. Peter Gabriel flies in the face of conventional
wisdom at OOPSLA by suggesting that good design does not come from a single
designer's vision, but from a dialog between at least two entities. Even a single
programmer working alone will be interacting with the code. I spent the whole winter
break studying Uncle Bob's latest book "Clean Code" which perfectly illustrates
the dialog between the programmer and the code as it is refactored. I
recommend them all if you work with code.
.Open Atwood08
Jeff Atwood
Coding: It's just writing
coding horror nov10th
.See http://www.codinghorror.com/blog/archives/001184.html
=ESSAY CODING STYLE STRUNK LITERATE KNUTH
.Close
.Open Gabriel08
Richard P Gabriel
Designed as Designer
OOPSLA 2008 & SIGPLAN Notices V43n10(Oct 2008)pp617-632
=ESSAY DESIGN POETRY WRITING
Refs Brookes -- Conceptual Integrity comes from having a single designer.
Gives examples of design emerging from collaboration and help.
The importance of listening to what the product/design is saying.
Design is at least a dialog between Designer and the Designed.
Example: That dome in Florence, TS Elliot and E Pound, ...
Did not mention Umberto Ecco's "Foucalt's Pendulem" arguing the importance of editors.... (dick).
.Close
.Open Martin09
Robert C Martin
Clean Code: A Handbook of agile software craftsmanship
Pearson Education 2009 Boston MA ISBN 0-13-2350088-2
=HOWTO CODE TECHNICAL QUALITY WRITING JAVA
Demands study but tends to change the way you look at code.
All examples are Java 6 but it changed my C++ standards.
Stresses the iterative and evolutionary nature of code -- enhancement and refactoring as the constant change.
90% is well known advice dating back 30 years.
Some of it is startling
.List
Comments should be reduced in favor of more better named functions and variables.
Objects and data structures are different:
Objects hide data and provide functions, but
data structures give access to data and have no other function!
Writing tests is a good way to learn an API and pays for itself by proving documentation.
Refactoring an SQL class leads to a functional decomposition of classes into subclasses.
"Inversion of Control" and "Dependency Injection" -- dependencies are created at run time.
Use Domain Specific Languages at the systems level.
.Close.List
Good list of smells and heuristics in Chapter 17.
Notes and recommend an interesting property of Java 5 "enum"s
-- can specify functions that return different values for each value in the enum.
Better than "switch".
.Close
. 2009-01-14 Wed Jan 14 20:01 Top 25 most dangerous programming errors
A short entry today, about dangerous mistakes that people make when
developing web sites. It starts with a carefully done survey that
ranks errors in terms of the risks involved, however this link
.See http://cwe.mitre.org/top25
takes a long time to download. There is a lot of detailed information.
But "Coding Horror" had an entry that summarizes these mistakes:
.See http://www.codinghorror.com/blog/archives/001210.html
that is both quicker to download and easier to read.
Recommended to anyone doing anything more complex than plain HTML
on their web site.
I'm planning some longer entries when the new term has settled down.
One on the value of evolutionary and iterative processes. Another on the
topic of writing software and coding style. There will also be something
on speeding up web sites.
So watch this place...
. 2009-01-12 Mon Jan 12 18:01 Examples of User Hostile Systems
I've just spent a painful couple of days picking up the online resources
that come with a text book that I am using. I had to register on two
different sites -- and of course I made sure not to use the same password.
I had to supply superfluous information. Then both sites sent me
confirmation EMail complete with their own password `en clair` ready for
every hacker from here to Long Beach and back to the East Coast to sniff it.
So I thought it wise to log in to the sites and change the passwords
(and hope that they would not Email them...). You will have had similar
experiences. So has today's featured author below. Well worth a read.
.Open Santini08
Simone Santini
Madrid's Brilliant Idea
IEEE Computer Magazine V41n12(Dec 2008)pp128+126-127
=ANECDOTE USER WWW SECURITY CLEVERNESS POSSESSIVENESS
Gives an example how a combination of too much security, too many
assumptions, and trying to stop you from leaving a web site leads to a
system not being used at all.
.Close
. 2009-01-11 Sun Jan 11 13:01 Another hiatus
The dept web server has been down.... this is a test post to see if it is 100% up yet.
Erick Behr has spotted a typographical error in my
.See ./syllabus.html
generic syllabus. I've fixed
it but won't be able to publish the result until I can upload changes to
the web server.
. 2009-01-07 Wed Jan 7 19:01 Methodology remembered
When I read $HamiltonHackler08 below I was reminded of an over-hyped
program development method I had seen in books and articles in the 1980's.
The Apollo mission at NASA had discovered that most programming errors where
incorrect interfaces between "modules". They developed a mathematical/logical
model for systems which allowed `functional decomposition` and a tool for
checking the correctness of the discussion. Functions were described
in terms of their name and there inputs and outputs. For example,
`MUL` might have two numbers `X` and `Y` as input and a single number `PROD`
as an output. To solve a quadratic equation
a*x^2 + b*x + c =0,
one would have three inputs: a,b,c and two outputs: root1 , root2. Part
of the computation finds the discriminant
\Delta := b^2 - 4*a*c.
And so on into more and more detail.... down to multiplying a by c.
This was for programs written in machine code.
The tool would check that all the data for the calculation of \Delta was
available, and that \Delta was available before it was used.
After Apollo, in the 1980s the same ideas emerged into the commercial world as
a tool USE.IT, marketted by "Higher Order Software" or "HOS". One very
nice attribute of the tools was the use a graphics to display and input
the decompositions and error reports.
To a large extent the wide spread use of high level languages and
static data flow analysis made the ideas redundant and,
as far as I know, the tool is no longer with us.
Note: This my own summary of the history based on articles, books, and advertising
that I have kept in my office since 1984. If you differ use the [Contact]
button above to submit a rebuttal that could well be published here.
.Open HamiltonHackler08
Margaret H Hamilton & William R Hackler
Universal Systems Language: Lessons Learned from Apollo
IEEE Computer Magazine V41n12(Dec 2008)pp34-43
=HISTORY CORRECT DESIGN EVOLUTION HOS USL FUNCTIONAL DECOMPOSITION
Apollo space mission 1961-1975.
Functions and maps decomposed using three structures: Join, Include, Or. (=~= ";", "&", "|" in MATHS).
Theories of correctness and tools to check such decomposition.
Still blindsided by events. Reality had unexpected properties.
The power of a global reset when an inconsistent state occurs.
Asynchronous process and asynchronous software,
(dick)|- further developed into language AXES, tool USE.IT and company HOS in the 1980's.
.Close
. 2009-01-05 Mon Jan 5 19:01 Review Published and Software Quality Assurance
First a boast... Computer Reviews ($CR) has published my review
of
.See [SchattkowskyForster07]
as review 0901-0062 in Volume50, Number 1 (Jan 2009)page 46.
I've spent some time studying attempting to `precis` the following
study of how research has impacted practice in the area of SQA. I'll
let my summary speak for itself.
.Open RombachEtAl08
Dieter Rombach & Marcus Ciolkowski & Ross Jeffrey &Oliver Laitenberger & Frank McGarry & Forest Shull
Impact of Research on Practice in the field of Inspections, Reviews and Walkthroughs
ACM SIGSOFT Software Engineering Notes V33n6(Nov 2008)pp26-35
.See http://www.acm.org/sigsoft/SEN/
.See http://doi.acm.org/10.1145/10.1145/1449603.14496009
=SURVEY =POLL HISTORY SQA RESEARCH PRACTICE
Measure impact by: # licenses, documented uses, evidence of effect on use.
Defines terms. Refers back to QC in 1920 manufacturing, 1960s need for early detection of defects, Weinberg, Fagin, ...
NIST 2000: estimates $22 billion could be save each year by best-practice defect detection.
Wide range of practices and formality.
Poll 2001-2002: regular but unsystematic reviews. Not enough early in cycle. People skip steps: preparation and detection. Companies do not make it part of a process evaluation and improvement process.
Can we trace successful use back to research? Evidence in 1970s, pilots, in-house evidence, standardization.
Some ideas with experimental evidence are not sustained -- PBR.
Need: management support, technology champion, convince the developers.
Need collaboration between practitioners and researchers, a charismatic champion, prior quantitative evidence (pilot) in-house.
Human-based techniques may not work outside the lab.
Sustained success: management support, evidence, repeatable analysis and measurements, accepted standard process, easy adaption to changing environment.
Three factors: Adhering to process, systematic reading techniques, optimization.
.Close
. 2009-01-03 Sat Jan 3 09:01 Happy New Year
I've archived the previous entries on this blog.
I plan to continue this blog as a mixture of personal observations on my life and software development with
links to recently published URLs, articles, and papers. The goal is to document the soundest practices
and the must useful theories.
I've looked at my schedule
.See ./plan.html
for the coming quarter and I am not sure whether I will be able to stick to the MTWRF postings.
So I will be making entries every Monday, Wednsday and Friday starting next week... plus some extra ones
as and when the spirit moves me or circumstances conspire.
I also plan another change that will make it easier to pickup the latest entry without having to download all the previous ones.
I will be archiving entries into
.See ./blog009.html
on a regular basis... weekly or after each new posting...
As before I love to hear from my readers and any thing you send to me:
.See ./mailme.html
may well be published and credited to you. In time, I hope to develop a set of regular contributors...
. Invitation to Contribute
If you have read something about software development that you think
is worth reading you can share it and earn a small piece of fame merely
by following this link
.See ./hole.html
and filling in the form. I will review and post it if it
fits with the goals of this blog: The most practical theories and the
most sound practices associated with software development.
. Previous Archived Blogs
(Blog to December 2009):
.See ./blog009.html
(Blog to December 2008):
.See ./blog008.html
(Blog to December 2007):
.See ./blog007.html
(Blog December 2006):
.See ./blog006.html
(Blog December 2005):
.See ./blog005.html
(Blog December 2004):
.See http://csci.csusb.edu/dick/blog004.html
(Blog December 2003):
.See http://csci.csusb.edu/dick/blog003.html
(Blog July 2003):
.See http://csci.csusb.edu/dick/blog002.html
(Blog June 2003 and before):
.See http://csci.csusb.edu/dick/blog001.html
. Latest
.See http://csci.csusb.edu/dick/blog.html
. Glossary and Links
above::=`using the above statements...`.
bibliography::=http://www/dick/newbib.html,
(source
.See http://www/dick/newbib.mth
)
a
large collection of publications on software development.
a place to search for data on my site. Now recovered from damage
done in the latter half of 2003.
dick::=`indicates my own opinion in and of a bibliographic item`.
given::=`the data and input into a proof, construction or other thinking`.
goal::=`the current conclusion, target or unknown of the thinking, construction, or proof`.
Haiku::poem="A 19 syllable Japanese poem that captures one moment but implies the universal",
All Haiku are supposed to indicate the season of the year and Japanese has many
words and phrase that are used for these purposes. Most Haiku also have a
caesura (pause) that is counted as a single syllable. Writing Haiku
in English is like trying to clap with one hand.
languages::=http://www/dick/samples/languages.html,
information on computer languages.
latest::=http://csci.csusb.edu/dick/blog.html,
MATHS::=http://csci.csusb.edu/dick/maths/,
a language for semiformal documentation including
ontologies, logics,
conceptual models, specifications, and algorithms
that I also use for weblogs, essays, lecture notes, etc. etc.
methods::=http://www/dick/samples/methods.html,
links and definitions about software development methods and processes,
plus some jokes. Also see
.See http://www/dick/samples/methods.glossary.html
instead.
monograph::=http://www/dick/monograph,
a study of software development methods 1940-1990 attempting
to show how simple mathematics can avoid common errors.
papers::=http://www/dick/papers,
pre-publication drafts, local seminars, unpublished essays, etc..
people::=http://www/dick/samples/people.html,
prostate::gland=`a walnut sized gland found in human males that has cells
that have a tendency to turn cancerous as the male gets older`, see $PSA.
.See http://www.healthopedia.com/prostate-cancer/
(not checked for accuracy, includes adverts).
PSA::`blood test`=`Prostate Specific Antigen`, the cells in the $prostate
generate a particular chemical in the blood and this test measures
how much. High values (40+) show rapidly growing cancer. From my
experience -- values like 5, 6, and 7 are a cause for concern ..
but it all depends on age and whether heart disease or some other
problem will get you first. To get a score of zero (undetectable <0.01)
the cells must be gone or not growing.
samples::=http://www/dick/samples/, samples of documents prepared using
$MATHS.
se::=http://www/dick/samples/se.html,
links to things about software engineering and software development.
source::=http://www/dick/blog.mth,
I use my own $MATHS language to write these blogs.
standards::=http://www/dick/samples/standards.html,
STANDARD::=http://www/dick/maths/math_11_STANDARD.html,
my personal standard definitions for $MATHS.
subjects::=http://www/dick/samples/subjects.html,
tools::=http://www/dick/samples/tools.html,
vita::=http://www/dick/VITAble.html,
.See ./short.vita
(plain text).
XBNF::=`eXtreme Bachus Naur Form`, a metalanguage based on EBNF that
can handle some forms of context dependency in an intuitive way, as
part of the $MATHS language.
Z::=http://www/dick/samples/z.html,
specification language.
.Close RJBottings Research Web Log 2009