Author and computer consultant specializing in project management.

http://www.atlsysguild.com/GuildSite/TDM/Tom_DeMarco.html

His books:
	* Structured Analysis and System Specification [ISBN: 0-138543-80-1]
	* Controling Software Projects
	* PeopleWare 
	* WhyDoesSoftwareCostSoMuch?  [ISBN: 0-932633-34-X]
	* TheDeadline
	* SlackByTomDeMarco  [ISBN: 0-767907-69-8]
	* WaltzingWithBears

Articles:
	* Both Sides Always Lose: LitigationOfSoftwareIntensiveContracts

Tom spoke at XpImmersionThree.

The Structured Analysis book is copyright 1978.  It is a very instructive book, concerned with creating "a new kind of Functional Specification, the Structured Specification" (pg 3).  This explains how to create a DataFlowDiagram description of the problem domain.

The DataFlowDiagram seeks to represent the problem as a network of four constructs.  These are the Data Flow (a connecting link), the Process (a bubble, hence DFD aka Bubble Charts), external entities (a box), and Data Stores (two parallel lines, with the 
name of the data store between the lines).

The original intent of this approach was to reduce the problem by removing physical details of data movement, databases, files, timing, platforms, and people.  Instead, the problem would be stated in terms of Processes that had to have certain Data Flow inputs, and would produce Data Flow outputs, with Data Stores to store information that needed to be stored, and External Entities to provide data sources and sinks of the needed data.

I found this approach to be extremely helpful in creating software systems, as it succeeds in focusing your attention on the details that really do matter -- like the interfaces between objects, what inputs are really needed, what transforms needed to be accomplished, and trying to make sure you do each thing once, and only once.

This approach has been extensively modified and enhanced in various methodologies since 1978 -- OO is one way of packing the results of the analysis.  

----
CategoryPerson