Q4Software Testing and Project Management

Software Project Planning is the rigorous, absolute first phase of management. It is not guesswork; it is a highly disciplined mathematical and logistical exercise designed to establish a concrete architectural blueprint before a single line of code is written. The process involves:

• 1. Scope Definition: Violently establishing the exact boundaries of the project to completely eradicate "Scope Creep." Identifying exactly what features will and absolutely will not be built.
• 2. Sizing and Cost Estimation: Utilizing mathematical models (like COCOMO or FPA) to calculate the massive total lines of code (KLOC), the required man-months of effort, and the exact financial budget required.
• 3. Resource Allocation & Scheduling: Utilizing CPM/PERT network diagrams and Gantt charts to mathematically map task dependencies and assign specific engineers to the Critical Path.
• 4. Risk Management Planning: Proactively identifying catastrophic threats (server crashes, staff loss) and engineering mitigation protocols.

Engineered by Barry Boehm in 1981, COCOMO is an absolute foundational algorithmic software cost estimation model. It relies on a highly complex mathematical regression formula that takes the estimated physical size of the software (measured in Kilo-Lines of Code, KLOC) and calculates the exact Total Effort (in Person-Months) and Total Development Time.

The Three Mathematical Modes of COCOMO

• 1. Organic Mode: Utilized for small, simple projects executed by highly experienced teams with extremely flexible requirements (e.g., a small internal payroll app). The mathematical constants applied are small.
• 2. Semi-Detached Mode: An intermediate mode for medium-sized projects requiring a mix of experienced and junior engineers with moderately strict requirements (e.g., a new database management system).
• 3. Embedded Mode: The most catastrophic and complex mode. Utilized for massive, highly coupled hardware/software projects operating under absolutely rigid, non-negotiable constraints (e.g., avionics software for a fighter jet). The mathematical constants are massive, aggressively inflating the cost and time estimations to account for extreme complexity.

The Basic Mathematical Formula (Effort)

$$Effort(E)=a_{b}cdot(KLOC{)}^{b_b}$$

Where $E$ is the total Person-Months, and $a_b$ and $b_b$ are strict constants defined by whether the project is Organic, Semi-Detached, or Embedded.

A massive flaw in COCOMO is its reliance on KLOC (Lines of Code). You cannot accurately guess the Lines of Code before writing the software. Function Point Analysis (FPA), engineered by Allan Albrecht, solves this. FPA completely ignores physical code and instead calculates the size of the software purely based on the mathematical complexity of its architectural features (the UI and Database).

FPA rigorously counts five specific user-facing domains:

• 1. External Inputs (EI): Forms or screens where users violently inject data into the system.
• 2. External Outputs (EO): Reports or screens where the system calculates and blasts data out.
• 3. External Inquiries (EQ): Simple read-only database queries.
• 4. Internal Logical Files (ILF): The massive, complex database tables physically maintained within the system boundary.
• 5. External Interface Files (EIF): Database tables shared with external 3rd-party systems.

Each of these elements is mathematically weighted based on its complexity (Low, Average, High) to calculate the Unadjusted Function Points (UFP). This is then multiplied by a massive Value Adjustment Factor (VAF) based on 14 system characteristics (like required performance and distributed processing) to yield the absolute final Function Point count.