Author Topic: Software Engineering Standards - IEEE SRS SDD  (Read 10572 times)

thomaskilian

  • Guest
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #45 on: December 07, 2007, 01:23:43 am »
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 :'(
« Last Edit: December 07, 2007, 01:24:01 am by thomaskilian »

ukmtk

  • EA User
  • **
  • Posts: 34
  • Karma: +0/-0
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #46 on: December 07, 2007, 02:41:58 am »
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

  • Guest
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #47 on: December 07, 2007, 04:18:55 am »
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

  • EA Guru
  • *****
  • Posts: 5874
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #48 on: December 07, 2007, 05:06:01 am »
Quote
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
« Last Edit: December 07, 2007, 01:39:41 pm by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #49 on: December 07, 2007, 07:51:21 am »
... most consistent, insistent and obsistent use of the abstruse concept merynominomy (whatever)  ;D

bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5874
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #50 on: December 07, 2007, 02:16:43 pm »
Quote
... most consistent, insistent and obsistent use of the abstruse concept merynominomy (whatever)  ;D

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

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
« Last Edit: December 07, 2007, 02:17:01 pm by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #51 on: December 07, 2007, 02:49:20 pm »
Quote
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
Verbal Use Cases aren't worth the paper they are written upon.

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #52 on: December 10, 2007, 02:43:35 am »
Quote
[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  ???  :o

Arrh, someone will probably come up with that sometime.



as ever, cynically yours
bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

skiwi

  • EA Practitioner
  • ***
  • Posts: 1727
  • Karma: +23/-49
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #53 on: October 27, 2010, 08:07:42 am »
Bump.
Perhaps the 'EA wiki' could be the Community site.
Orthogonality rules
Using EA12.1 (1229) on Windows 10 Enterprise/64 bit. Repositories in SQLServer2014 R2 & Access2003/JET4.0

DanG83616

  • EA User
  • **
  • Posts: 183
  • Karma: +0/-0
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #54 on: October 28, 2010, 05:24:31 pm »
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