What Is Actually Managed During Development

In one line

What is actually managed in the development phase of SI is not code quality but three things, standards, configuration and progress, because the people who built this system will be gone in two years.

Why standards come first

With 20 developers you get 20 styles. Each is reasonable in its own way, but the person maintaining it three years later has to read all 20. An SI system usually lives 7–10 years, and the people who built it are usually gone within 2 years, so the reader's time is far more expensive than the writer's taste.

So standards exist not to produce good code but to produce predictable code. If the same thing is in the same place whichever file you open, you can fix even a module you are seeing for the first time within 30 minutes.

Development standards come first

The first week of development in an SI project starts not with coding but with reading the development standards document. It describes the package structure, class naming rules, log-level usage criteria, exception handling approach, how to use common code, and query-writing rules (the permitted scope of dynamic queries, whether hints may be used).

The reason is simple. With 20 developers you get 20 styles, and the person maintaining it three years later has to read all 20. An SI system usually lives 7–10 years, and the people who built it are usually gone within 2 years.

For public-sector projects, the eGovFrame (the e-Government standard framework) is layered on top. It is Spring-based and provides common components (login, file upload, bulletin board, code management). The version and JDK combination is specified in the project notice, so "a newer version would be better" doesn't fly.

Configuration management — 'tags and release notes' rather than branches

These days SI uses Git too. But an open-source-style branching strategy doesn't fit well as it is. The reason is that the unit of deployment is not a 'feature' but a 'phase'.

• Phase 1 go-live: members/orders
• Phase 2 go-live: settlement/statistics
• Stabilization patches: every Thursday night

So three things actually matter.

1. Does what was deployed match the source? — If you deploy without a tag, three months later you cannot find what to roll back to.
2. Who changed what, when and why? — This is why you put the requirement ID or defect ID in the commit message. A commit message like fix bug gives the maintainer no information at all.
3. Production deployment history — Separately from the source history, you need a ledger of "which version went into production and when".

In a closed-network project, external GitHub is not available, so configuration management is an in-house GitLab or, at worst, a file server plus zip files. Even in such an environment, if you keep to the principle that a tag = a snapshot of the deployment artifact, you avoid the worst.

Unit testing — what this word really means in SI

You need to know the terms precisely. The unit test you learned in school (JUnit) and the 'unit test' as an SI deliverable overlap but are not the same.

Category	Target	Deliverable	Who
Unit test (UT)	One program/screen	Unit test scenarios and results report	The developer themselves
Integration test (IT)	Business flows, integration between systems	Integration test scenarios and defect log	QA/PL, both systems
Acceptance test (UAT)	Customer business scenarios	Acceptance test results report, acceptance confirmation	Customer business users

An SI unit test results report is usually a table like this.

TC-207 | 주문 조회 - 정상 | 조건: 고객ID=C001, 기간=2026-01~2026-06
       | 기대: 12건 조회, 응답 3초 이내
       | 결과: 12건, 1.8초 | 판정: Pass | 시험일: 2026-08-11 | 시험자: 김영주

What matters is 'how many exception cases there are'. A unit test results report with only normal cases deserves to be rejected in review. At the very least, these must be there.

• Missing required value
• Length exceeded / type mismatch
• User without permission
• Zero results
• Concurrent modification (optimistic lock conflict)

Code review and static analysis

Large projects usually have quality targets in the contract. A static analysis tool (such as SonarQube) is used to set targets such as zero critical defects and zero security vulnerabilities.

What newcomers often experience: they run static analysis for the first time right before the deadline and get 2,000 findings. You have to run it daily from the start. The realistic approach is for the team to agree on and lock the rules at the project start, and from then on block only the newly introduced violations (the new-code baseline).

The honesty of progress rates

The progress rate in a weekly report is usually 'completed programs / total programs'. So the progress rate only means something if the program list is accurate.

And one rule: without a unit test results report, it is not done. If "the coding is finished, only testing is left" piles up, everyone spends the last 2 weeks writing test results reports retroactively. Everyone knows what that document is worth, and nobody says it.

What you see in the field

Progress reporting is distorted most often in this phase. A typical sign is a report of "80% done" that stays at 80% for several weeks.

The cause is usually that there is no unit to count. With a program list, progress becomes a countable number such as "92 of 118 unit tests passed", but without a list you end up averaging everyone's gut feeling. And gut feeling always stalls around 90%.

Configuration management goes wrong for the same reason. However well you design a branching strategy, in a project whose unit of deployment is a 'phase', what went out and when matters more. Without tags and release notes, no one can say for certain during an outage "which point in time is the code currently running in production from".