• Reference for explicit versus implicit methodologies

    From matt.jaffe@gmail.com@21:1/5 to All on Wed Feb 8 14:43:37 2017
    Years ago (well decades, actually ;-) one of my software engineering professors (Dr. Peter Freeman at UCI) talked about the difference between implicit and explicit software engineering methodologies for requirements and design. Explicit methodologies
    were based on the assumption that the two phases (requirements and design) could be kept pretty separate --- requirements were always black-box and design was not started until the appropriate set of (black-box) requirements was documented/specified.
    Implicit methodologies recognized the fact that the two could be intertwined in that developing and documenting requirements could be based on, or use, abstract design entities like data flow bubbles or the object-classes of OOA. I would like to refer
    to this distinction (explicit versus implicit methodologies), in the lecture notes for a class I teach, but I can't find any references to them (explicit and implicit methodologies) in the literature. Any references would be much appreciated.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Julio Di Egidio@21:1/5 to matt....@gmail.com on Wed Feb 8 20:23:53 2017
    On Wednesday, February 8, 2017 at 11:43:38 PM UTC+1, matt....@gmail.com wrote:

    Years ago (well decades, actually ;-) one of my software engineering professors (Dr. Peter Freeman at UCI) talked about the difference between implicit and explicit software engineering methodologies for requirements and design.

    In engineering (not just software) there is a distinction between *explicit and implicit *requirements** (not methodologies), the former being those explicitly coming from the customer side, the latter being the technical requirements the customer won't even know about (unless these are not there...) but that should be there, like maintainability or acceptable performances and similar.

    Explicit methodologies were based on the assumption that the two phases (requirements and design) could be kept pretty separate --- requirements were always black-box and design was not started until

    That's really the bullshit spread by 20 years of fake agility and the scum by two generations now of self-appointed gurus, coaches, consultants and of course the tool vendors, who have started it all. They have literally made a misery and a long term damage to an entire industry for their own immediate advantage, and not per chance 80% of the software projects keep failing miserably.

    Any references would be much appreciated.

    My advice is just get a decent book on software engineering, Pressman's remains a classic although across the years even him has lost it a little bit, IMHO, indeed I think in an attempt to embrace some of the "novelties": I still keep the second edition...

    HTH,

    Julio

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)