Classic Mistakes in Software Projects

I am Reading “Rapid Development: Taming Wild Software Schedules”, this book talks about Four Dimensions of Development Speed

• People
• Process
• Product
• Technology

It talks about classical mistakes ; here i have list out mistakes from book and some from my own experience, do add to it..we need to learn from others mistakes

People Related Mistakes

1.   Undermined motivation

2.   Weak personnel

3.   Uncontrolled problem employees

4.   Heroics

5.   Adding people to a late project

6.   Noisy, crowded offices

7.   Friction between developers and customers

8.   Unrealistic expectations

9.   Lack of effective project sponsorship

10.  Lack of stakeholder buy-in

11.  Lack of user input

12.  Politics placed over substance

13.  Wishful thinking

14.  Lack of team sprit

15.  Communication gap , No knowledge sharing

16.  Lack of Assertive communication

Process Related Mistakes

17.  Overly optimistic schedules

18.  Insufficient risk management

19.  Contractor failure

20.  Insufficient planning

21.  Abandonment of planning under pressure

22.  Wasted time during the fuzzy front end

23.  Shortchanged upstream activities

24.  Inadequate design

25.  Shortchanged quality assurance

26.  Insufficient management controls

27.  Premature or overly frequent convergence

28.  Omitting necessary tasks from estimates

29.  Planning to catchup later

30.  Code-like-hell programming

31.  Poorly managed critical path or critical chain

32.  Poor task prioritization or Sequencing

Product-Related Mistakes

33.  Requirements gold-plating

34.  Feature creep

35.  Developer gold-plating

36.  Push-me, pull-me negotiation

37.  Research-oriented development

38.  Not using value engineering

Technology-Related Mistakes

39.  Silver-bullet syndrome

40.  Overestimated savings from new tools or methods

41.  Switching tools in the middle of a project

42.  Lack of automated source-code control

43.  Lack of Automated test tools 

Function Point Analysis, Transactional Function

IFPUG’s definition of transactional function, Transactional functions provide the means for a user to transact with the application. These functions facilitate the processing of data contained in the system, and convert and present it in a form desired by the user. Following rules can be used to identify transaction

•          The transaction is visible or accessible to the user
•          All transactions are identified to be outside the boundary but within the scope of the application being counted
•          The various data elements that constitute the transaction necessarily move from outside to inside the application boundary and vice versa.
•          The transaction could be invoked through various means of input (batch or online) or through a variety of hardware devices, sensors and more.

IFPUG defines EI, EO and EQ as follows:

External Input (EI)

An external input (EI) is an elementary process that processes data or control information that comes from outside the application’s boundary. The primary intent of an EI is to maintain one or more ILFs and / or alter the behavior of the system

External Output (EO)

An external output (EO) is an elementary process that sends data or control information outside the application’s boundary. The primary intent of an external output is to present information to a user through processing logic other than or in addition to the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, or create derived data. An external output may also maintain one or more ILF and / or alter behavior of the system.

External inquiry (EQ)

An external inquiry is an elementary process that sends data or control information outside the application boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data. No ILF is maintained during the processing, not is the behavior of the system altered.

Determining Complexity of EI, EO and EQ

Two components of any transaction decide its complexity; that us, Data Elements (DET) and File Type Referenced (FTR)

DET: A data element type is a unique user- recognizable, non repeated field. In simple terms, it is a filed in a file or a column in a database table, but the mapping of a field or column in the file should be with respect to the data element recognized from the user’s point of view.

FTR, a file type referenced (FTR) is a file, internal or external, that has been accesses by the transaction.

EI Complexity Factor

Range	1 to 4 DET	5  to 15 DET	16 or More DET
0 to 1  FTR	Low	Low	Average
2 FTRs	Low	Average	High
3 or more FTRs	Average	High	High

EO / EQ Complexity Factor

Range	1 to 5 DET	6  to 19 DET	19 or More DET
0 to 1  FTR	Low	Low	Average
2 to 3 FTRs	Low	Average	High
4 or more FTRs	Average	High	High

EI/EQ FP Contribution

Functional Complexity Rating	Unadjusted Function Points
Low	3
Average	4
High	6

EO Contribution

Functional Complexity Rating	Unadjusted Function Points
Low	4
Average	5
High	7

CRUD Transactions

If we evaluate the elementary process involved in CRUD transactions, we find that except in the case of a Read transactions, all others are unique, As such, while counting EI for a data maintenance transaction, we count them three EI, One each for Create, Update and Delete. The complexity of these three EIs might vary depending on the number of data element involved in each of the transactions.