Software Engineering Standards - IEEE SRS SDD

[thomaskilian]

My truth is rarely my customers truth. It always needs cycles to have a common understanding. Documenting these cycles helps reducing their numbers. Having a good blueprint is desirable but unlikely to have. A bad blueprint with history is almost the best you ever can get. Using UML (tools like EA) the right way improves the cycle process enormously. It took me several years to elaborate a nice way to document my projects effectively (!) with EA. If I had the time (and talent) I should write a book. Unfortunately I'm not DeMarco

[ukmtk]

I suspect that some ideas of how you go about using EA effectively may be appreciated by newbies.

If you are not able to provide a brief (long!?) howto then some pointers as to how you arrived at your enlightened state would be appreciated. I.e. books, papers, courses or even just experiences.

[thomaskilian]

The problem is: this is a long story and I'm short of time since a longer period. You could hire me for such consultancy but I'm fully booked. I just can spend the time to answer a few questions on this board.

[Paolo F Cantoni]

If you are not able to provide a brief (long!?) how to then some pointers as to how you arrived at your enlightened state would be appreciated. I.e. books, papers, courses or even just experiences.

If you mean the EA guru state, I got mine by reporting bugs...  Each post counts toward your status...  

It's amazing how quickly you can find bugs in EA and accumulate Guru status... I hold a number of records...  Most bugs reported by a single user.  Most bugs reported in a single day.  Most bugs found and reported inside 1 hour (6).  

HTH,
Paolo

[sargasso]

... most consistent, insistent and obsistent use of the abstruse concept merynominomy (whatever)  

bruce

[Paolo F Cantoni]

... most consistent, insistent and obsistent use of the abstruse concept merynominomy (whatever)  

bruce

Meronymy is passe.... I've recently discovered connascence!  The interrelationship of coupling and cohesion!  

Came across it in: "What every programmer should know about object oriented-design" by Meiler Page-Jones.  From it's title you can see it wasn't published yesterday...

Paolo

[jeshaw2]

connascence occurs between two software components when ...

• It is possible to postulate that some change in one component requires a change in the other component to preserve overall correctness.
• It is possible to postulate some change that require both components to change together to preserve overall correctness.

from this source

Sounds like the o'le tightly coupled dragon again.  :-/

I need enlightenment I think 'cause Paolo knows better.  ;D

-Jim

[sargasso]

[L. con- + nascentia birth, fr. nascens, p. pr. of nasci to be born.]

1. The common birth of two or more at the same tome; production of two or more together. Johnson.

2. That which is born or produced with another.

3. The act of growing together. [Obs.] Wiseman.

Ya know, I kinda like it.

Sort of like the product and the specification are developed at the same time.  Like the idea and the reality mature together and synergistically.

Prob'ly be a good idea for a methodology    

Arrh, someone will probably come up with that sometime.



as ever, cynically yours
bruce

[skiwi]

Bump.
Perhaps the 'EA wiki' could be the Community site.

[DanG83616]

Thanks for the bump.

Near the end there was discussion about how structured techniques failed in the past. I have been working on the idea that they failed due to inadequate specification technology.

Products implemented with software can be very much more complex  than products implemented with hardware. Software devices are not subject to constraints so concisely defined by the laws of physics (f=ma, v=ir, ...). The lack of constraints frees us to make really complex things. It is not that software makes things more complex; rather, it is that we can do more complex things with software.

The greater complexity requires greater ability to specify. We simply not up to the task with the tools and experience we had back in the 70's. When complexity exceeds ability to specify it we can use artists and craftsmen to do the building. They don't always get it right but often enough it is close enough and sometime some of them can actually get it right. Agile methodology is a really good way of getting the very most out of a artisan/craftsman workforce.

Improved ability to specify (describe that which does not exist such that it can be made to exist) improves productivity. The cost of attaining that ability and practicing it have to be economical compared to the artisan/craftsman method. Currently the artisan/craftsman method is economical for all but the most safety critical systems. Those  systems are the ones where close enough or occasionally right production is not economical.

I do not know what will change the economics. It might be that we discover new laws of physics that apply to software devices. Without the scientific discovery that occurred in the 19th century we would not have had the industrial revolution. Those latent laws might provide the constraints that we now unknowingly violate and build systems that fail. In the mean time, we can work on optimizing our ability to specify software more efficiently without them.

The UML and tools like EA improve specification efficiency. The UML provides the means to express aspects of software devices more concisely than we had back in the 70's. Tools like EA provide an economical way to organize and maintain those expressions. Standardizing the organization of them as in the IEEE standards would provide a baseline from which to start incremental improvement.

Having said all of that, I think the user community has to learn to utilize and improve the standards. I don't know that Sparx can do anything to specifically address Keven's suggestion.

Oh, and where is the EA wiki?

Dan