.Open My Research Area
This page is under construction and replaces
a previous description
.See ./research.old.html
of my research area.

Note: Research papers are colored green and blue.
. Problem Statement

.Image bridge.jpg Engraving of John Roebling's Brooklyn Bridge

Why is it that John Roebling could design and construct
a bridge that is still in use today
despite problems with the quality of the supplied components and the 
unknown stability of some of its foundations,
and yet our software seldom works for than a month at a time?

Many people have proposed ways to improve software development --
but how many of these have worked in practice?

Many people have managed to produce better software on budget,
but what did they do right?

How do our notations, processes, methods, languages, and paradigms
effect our productivity and the qualities of our software?

. What is Known and Thought about Software Development
I have collected a large bibliography of papers and books about
developing software, and a repository of definitions, links,
and commentary on $methods, $languages, $standards, $tools, $etc.

To search this resource try
.See ./lab.html
my research search engine.

(methods): See
.See ./samples/methods.html
(languages): See
.See ./samples/languages.html
(standards): See
.See ./samples/standards.html
(tools): See
.See ./samples/tools.html
(etc): See
.See ./samples/etc.html

.Open What I Have Done
. MATHS
Because engineers use mathematics to design and evaluate solutions
to problems I developed a way to encode mathematical and logical
arguments and formula in ASCII.

This turned out to be a useful way to develop technical web pages.
This page and most other pages on this web site are written in this language
and translated into HTML using tools that I have developed.

The language I use is called MATHS. See
.See ./maths/
for details. The MATHS pages are colored blue.

I have many
.See ./samples/
of how to use MATHS to document things.
. The ROOT Project and UML
I have been instrumental in introducing object orientation
and the UML into the
CSUSB Computer Science department -- the ROOT project.
.See ./papers/rjb00a.ActiveROOT.html
.See ./papers/rjb99a.ROOT320.html

I proposed using the UML to express the semantics of programming
languages:
.See ./papers/rjb99b.sigplan.html
.See ./papers/rjb99c.umlpl.html
.See ./papers/rjb99c.umlpl.ps
(postscript).

I have recently been working on the changes as UML has evolved
into 
.Key UML 2.0
.See ./papers/20050502Abstract.html
.See ./papers/20050502Body.html
.See ./papers/20050502Outline.html
. Papers
.See ./papers/
. Publications
.See ./publications/
.Close
. Projects I Am Working On
For specific examples of projects and theses for graduate students
see
.See ./projects.html
and
.See ./theses.html
on this web site.

(blog): To see what I'm doing on a day-to-day basis look at
.See ./blog.html
my Weblog.

. Key Terms in my research area -- Software Development
.See ./map.gif
(Graphic) and
.See ./map.html
(Listing).

.Open My Personal Theory of Software Development
. One Size Does Not Fit All
Different processes and methods fit different situations:
.See ./papers/rjb95b.one.size.html

What niches exist? What works in them?
.Table Paradigm	Niche
.Row Engineering	Expensive high quality products
.Row MicroSoft	cheap mass produced and field debugged
.Row XP	Medium scale evolving high quality code
.Row ??	??
.Close.Table
. Think Outside the Box
There is more to good software than its code and function. See
.See ./papers/rjb01a.pqrst.htm
for a partly baked idea --- cooking for 25 years...

It is a matter of the `fitness` of the software to it's environment.
Hence: 
.Key Software Evolution
and co-evolution
need to be studied in both theory
.See ./papers/rjb02a.hack.html
.See ./papers/rjb02a.hack.txt
.See ./papers/rjb02bEvolve.pdf
and practice.

Further, this implies that software developers must understand
the world (`domain`?) in which their software will be running.
For more see the writings of
.Find Michael A Jackson
on 
.Key Data Directed Design
, 
.Key Dynamic Analysis and Design
,
and understanding the realities of the outside world.

. Somewhere between the World and new Software Things get Formal
Our software must survive in an informal, changing, continuous world
and yet it is expressed in formal languages, static, and discrete.

. No Projects = No Problems
By continuously developing software, making small, evolutionary
changes we may end up getting more for the money, than if
we launch a large scale revolutionary project that changes
much of a system.  Hence, we should avoid revolutionary projects
and design software to be evolving.




.Close My Research Area