Sunday, April 25, 2010

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.