Talk:Fagan inspection

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.

Software: Computing Low‑importance

	This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software 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.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Computing.

Shouldn't the backarrow in the graph go out from the `Follow up` step, since in `Rework` the author only corrects the errors and in `Follow up` the organizer decides on whether to start anew? --Antonrich (talk) 15:07, 22 August 2019 (UTC)[reply]

At the moment this is not an encyclopedic article about Fagan inspections as much as an overview of how a Fagan inspection can be performed. It would be more suited to wikibooks. S Sepp 20:38, 13 January 2006 (UTC)[reply]

Could I also point out that this is a direct copy of http://www.answers.com/topic/fagan-inspection - is this acceptable in Wiki?

Yes, it is a mirror, and gives credit. 10:40, 5 March 2006 (UTC)

Where does it give credit? I can't see it. S frankish 16:55, 13 March 2006 (UTC)[reply]

Talk:Fagan inspection/Follow-up[edit]

Per Wikipedia:Articles_for_deletion/Follow-up, the contents of Follow-up were merged into Fagan inspection and a redirect created. The redirect has subsequently been successfully nominated for deletion. I have moved the Follow-up page to this talk page to maintain the edit history for GFDL compliance. -- JLaTondre 16:53, 8 October 2006 (UTC)[reply]

Name origin[edit]

Where does the name "Fagan" come from? — Preceding unsigned comment added by IngoS (talk • contribs) 15:52, 20 December 2011 (UTC)[reply]

Apparently Michael Fagan, the software designer credited with the invention of the software inspection, or Fagan inspection. Wbm1058 (talk) 12:16, 17 May 2013 (UTC)[reply]

Merge proposal: to Software inspection?[edit]

It seems to me that this should probably be merged with Software inspection. They may not be quite the same, but there is a great deal of overlap. The could be a new section Software Inspection#Methodologies and sub-section Software Inspection#Fagan Inspection where specific features of Fagan are described. A difficulty is, however, that this article suggests Fagan is applicable to more than just software development. (N.B. Articles Follow-up and Major and Minor defect seem to have been merged here.) PJTraill (talk) 12:01, 23 January 2015 (UTC)[reply]

Merge: The overlap outweighs the differences PJTraill (talk) 12:29, 23 January 2015 (UTC)[reply]
Completely disagree. This is like saying the article on automobiles should be merged into the article on Honda Civics. If anything, Software inspection should instead be merged here as a subtopic. — Preceding unsigned comment added by 192.100.72.2 (talk) 15:23, 22 July 2016 (UTC)[reply]

Example missing diagram[edit]

What has happened to the section Fagan inspection#Example? It refers to a non-existent diagram! Either the diagram should be added or the reference removed. PJTraill (talk) 12:01, 23 January 2015 (UTC)[reply]

Outdated / non-neutral point of view[edit]

The statement "As the costs to remedy a defect are up to 10 to 100 times less in the early operations compared to fixing a defect in the maintenance phase,[1] it is essential to find defects as close to the point of insertion as possible." is somewhat out of date. Modern research has shown that the large costs associated with defects in early software engineering studies were more a product of the development methods used rather than an innate feature of software development. The waterfall model influenced these studies in that the waterfall process is inherently costly and long, and defects found later in development (during testing or deployment) could mean that the development team needs to restart with requirements and specifications. In contrast, agile models that rely less heavily on defined processes and requirements and specifications do not exhibit this large cost. 172.221.186.254 (talk) 02:43, 29 October 2019 (UTC)[reply]