	Biography portal This article is within the scope of WikiProject Biography, a collaborative effort to create, develop and organize Wikipedia's articles about people. All interested editors are invited to join the project and contribute to the discussion. For instructions on how to use this banner, please refer to the documentation.BiographyWikipedia:WikiProject BiographyTemplate:WikiProject Biographybiography
	This article is supported by the science and academia work group (assessed as Low-importance).

Ireland Low‑importance

	Ireland portal This article is within the scope of WikiProject Ireland, a collaborative effort to improve the coverage of Ireland on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.IrelandWikipedia:WikiProject IrelandTemplate:WikiProject IrelandIreland
Low	This article has been rated as Low-importance on the project's importance scale.

Technical Realism

Would anyone be so kind as to explain what "technical realism" means in this instance?

Cohesion and Coupling

Parnas is often credited with introducing these concepts, but I've just gone back to the classic 1972 ACM and these concepts, while implicit, are not explicitly mentioned.--RichardVeryard 09:53, 28 September 2006 (UTC)[reply]

A review of the ACM Digital Library uncovers a single instance in all of Parnas's writing [Parnas, Schouwen, and Kwan. "Evaluation of safety-critical software," CACM, 33 (6), June 1990] where he used the terms coupling or cohesion--in that instance without attribution. If he is "often credited" where and by whom?Stirrer (talk) 18:18, 18 November 2007 (UTC)[reply]

The metrics of coupling and cohesion were originally proposed by Larry Constantine as correctly referred in Coupling_(computer_science). David Parnas did not contribute directly or indirectly to these metrics. The original reference is the seminal 1974 IBM Systems Journal paper Structured Design, which describes nearly 10 years of pioneering research by Larry Constantine. The ideas behind Coupling and Cohesion were initially published in "Segmentation and Design Strategies for Modular Programming." In Barnett and Constantine (eds.), Modular Programming: Proceedings of a National Symposium. Cambridge, MA: Information & Systems Press, 1968 and “The Programming Profession, Programming Theory, and Programming Education,” Computers and Automation 17, 2 (Feb. 1968) pp. 14-19. —Preceding unsigned comment added by 193.136.232.3 (talk) 08:40, 19 November 2007 (UTC)[reply]

Parnas hosted an IRC or mail group that provided reporting on software errors, near misses, and generally on software failures. In Hamilton, Ontario we had a computer club with researchers and technicians from McMaster, Stelco, Dofasco and the populous. The club sponsored a conference at Brock University where Parnas presented on Data Hiding. The concepts of cohesion and coupling were well discussed. Also discussed at the conference was the RCA 1802 with its double stack and use in satellites and industrial applications under the Forth language. 198.103.184.76 (talk)

Information Hiding not being mentioned by Parnas

Contrary to what is stated in the references section, Parnas mentions information hiding in his 1972 ACM article on page 1056 (bottom left) and he refers to himself: Parnas, D. L. Information distribution aspects of design methodology. Tech. Rept., Depart. Computer Science, Carnegie-Mellon U., Pittsburgh, Pa., 1971. Also Presented at the IFIP Congress 1971, Ljubljana, Yugoslavia. - However, I was not able to obtain a copy of that article, but nevertheless, information hiding is mentioned by Parnas in his 1972 ACM article. —Preceding unsigned comment added by 88.65.64.49 (talk) 13:36, 27 March 2009 (UTC)[reply]

Software Cost Reduction Project

I think this entry should say something about Parnas's participation in the U.S. Navy's Software Cost Reduction project. I actually came here to look for a reference to an example of the SCR's diagrams for specifying requirements. (See Heitmeyer (2007) "Formal Methods for Specifying, Validating, and Verifying Requirements".) 151.190.254.108 (talk) 14:52, 24 May 2011 (UTC) --RLV[reply]

LTV A-7 Corsair II The LTV A-7 Corsair II is a carrier-capable subsonic light attack aircraft ...

Heninger, Kathryn L.; Kallander, John W.; Parnas, David L.; Shore, John E. (1978). Software Requirements for the A-7E Aircraft. Naval Research Laboratory. NTIS ADA061751, NRL Report 3876. The Naval Research Laboratory and the Naval Weapons Center are engaged in a joint project to redesign and rebuild the A-7E Operational Flight Program (OFP) using several advanced software engineering principles. ... It describes the required behavior of the OFP without describing an implementation. It also describes relevant characteristics of the A-7 computer, sensors, and display devices.
Alspaugh, Thomas A.; Faulk, Stuart R.; Heninger Britton, Kathryn L.; Parker, R. Alan; Parnas, David L.; Shore, John E. (1992). Software Requirements for the A-7E Aircraft. Naval Research Laboratory. NTIS ADA255746, NRL/FR/5530—92-9194. The Software Cost Reduction (SCR) research project introduced a new approach to specifying requirements for real-time embedded systems. The principles were applied in the development of the Software Requirements for the A-7E Aircraft, as an example of the use of the approach.

RDBrown (talk) 11:13, 9 July 2020 (UTC)[reply]

Quotations out of context are not a good idea in any article.

David Parnas is an important researcher, one part of this wikipedia entry, refers to flow-charts against structured programming, because a confusion common in those days.

Structured programming was wrongly taken by many people as programming without GOTOs, because an anecdote about the change of title of the GOTO considered harmful written by E.W.Dijstra, but renamed by N.Wirth (the author of Pascal,Modula, Step wise refinement, programs=data structures + algorithms, etc.)

Structured programming is basically programming by composing (reusable) parts on the basis of a mathematical structure. Data types are mathematical structures, programming structures too. Like deriving theorems from axioms.

Data-flow diagrams do not encourage an structured thinking, the introduction of "structured languages", (i.e. languages with assignment, if-then-else, while, for-next, repeat-until, and subroutines, making much more less use of GOTOs). Did not automatically solved the problem, take into account that the predominant languages of those days used floats, integers, characters, strings, arrays and records in some languages like COBOL. (this before Pascal, Algol existed but was not very known to business applications programmers)

Artificial intelligence on those days was very experimental and the quotation based on cite 4 where Parnas said that Turing Machines and Gödel theorems where irrelevant, could be because many people on those days argued that IA research where looking for impossible goals due to the incompleteness theorem. I could not download the document, the date of the original publication is also omitted.

Turing Machines originated by an engineering thought on how an human computer worked at those days, using the minimal elements. The Universal Turing Machine was the basis for the stored program computer. John Von Neumann new Turing. The famous Gödel theorems are related to arithmetic, and Recursive Functions (a class of functions, mathematical systems, not the simple use of the word to denote a program that calls it self) Seen in that way, I do not believe that Parnas ignored that. But the quotation based on citation 4 seems to be out of context, mixing a his opinion on the AI research with Software Engineering.

For that reason, I think that the quotations are out of context, and should be removed.

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on David Parnas. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 10:59, 10 December 2017 (UTC)[reply]

Other publications by David Parnas

Mr. Parnas published a short (6 page) paper in 1986, called "A rational design process: how and why to fake it". It's really worth reading, and I'm surprised that there is no reference to it here in this article. Ifdef (talk) 16:44, 28 January 2021 (UTC)[reply]