Anika, an experienced programmer, takes a job with a small company in her hometown. In the first few days, it is apparent that the system she inherited maintenance responsibility for is poorly documented and, therefore, difficult to interpret, test, and debug. She concludes that the organization does not have adequate segregation of duties in place. Which kind of segregation of duties could have prevented this problem?

Anika, an experienced programmer, takes a job with a small company in her hometown. In the first few days, it is apparent that the system she inherited maintenance responsibility for is poorly documented and, therefore, difficult to interpret, test, and debug. She concludes that the organization does not have adequate segregation of duties in place. Which kind of segregation of duties could have prevented this problem?

• A. Separating new systems development from maintenance
• B. Separating the database administrator (DBA) from systems development
• C. Separating systems development from computer operations
• D. Separating programming from accounting

Answer: (A)

Separating development from maintenance creates a clear boundary so changes to production software go through the development process with proper documentation, testing, and approval. When maintenance activities are performed by a separate group, undocumented or ad hoc modifications are less likely to slip in, because any change must be captured in change records, tested, and understood by those who originally built the system. This improves interpretability and testability of the system, making debugging easier since there’s a defined owner of the code and its documentation, and a formal process to track what changed and why. Other forms of separation address different risks (like who can alter database structures or who can deploy code to production, or separating programming from accounting). While useful in their own right, they don’t directly tackle the problem described—untracked, undocumented changes that make the system hard to interpret and debug—quite as effectively as keeping development separate from maintenance.

Separating development from maintenance creates a clear boundary so changes to production software go through the development process with proper documentation, testing, and approval. When maintenance activities are performed by a separate group, undocumented or ad hoc modifications are less likely to slip in, because any change must be captured in change records, tested, and understood by those who originally built the system. This improves interpretability and testability of the system, making debugging easier since there’s a defined owner of the code and its documentation, and a formal process to track what changed and why.

Other forms of separation address different risks (like who can alter database structures or who can deploy code to production, or separating programming from accounting). While useful in their own right, they don’t directly tackle the problem described—untracked, undocumented changes that make the system hard to interpret and debug—quite as effectively as keeping development separate from maintenance.