Routine Maintenance After Launch: Handling Reports, Periodic Checks and Maintenance Reports

Post-launch work follows a fixed order and cycle, and every item leaves a record, so the project team knows the next step at each point. The reasons for continued maintenance are covered in why software needs maintenance after launch; this article covers only the practice.

How a report moves from logging to closure

When a user or venue staff member calls or emails, the project team first logs the report in the shared report list, then posts in the discussion thread, tagging the responsible engineers and attaching the list item. POLISH replies first that the report is received and under investigation, fixes the problem once the cause is found, deploys the fix, and states in the reply on the same report that it has been handled. The steps below are summarized from multiple reports.

1. Log: the project team logs the report in the shared report list with the page, the time of occurrence and a screenshot, and explains why it needs priority handling.
2. Assign: the list item is posted in the discussion thread, naming the responsible engineer.
3. Acknowledge: POLISH replies that the report is received and under investigation.
4. Reproduce: the engineer first reproduces the problem in the engineer's own environment.
5. Request details: the reporter is asked for the time of the operation or a screenshot of the entered content.
6. Interim measure: an interim measure is given together with the expected completion time.
7. Fix: the fix goes to the test site first and, once confirmed, to the production site.
8. Close: the reply on the same report states that the issue is handled or updated.

For reports that need manual data corrections, the project team collects supporting evidence from the user, and POLISH handles the correction in the back office and then replies. When a restore is needed, the project team confirms the original state with the user so that the data can be restored. When a system problem occurs, POLISH will arrange staff to handle it immediately.

Issues found in testing and results from external inspection go through the same records

When testing finds a problem, POLISH posts the situation and a screenshot in the discussion thread and names the responsible front-end and back-end developers, asking the two sides to align on the basis for the diagnosis first and to fix the problem before testing. After the developers report the root cause and the handling status and deploy a new version, POLISH retests and records the result in the quality-check list. Fixed parts can also be handed to the project team for testing. Problems and retest results both stay on the list, so a record is available later.

When results arrive from an inspection or vulnerability scan arranged by the supervising agency, the engineering lead posts a screenshot of the report and states the deadline for handling. The engineering lead determines the cause first, then proposes one or two handling options, for example adjusting a default value, or changing the error page to a simplified version that shows plain text only, and asks the developer to confirm that the change causes no side effects. After the developer makes the adjustment, a corrected version is deployed first, then the developer replies that it is handled, and the engineering lead rechecks. For remediation priorities, false-positive appeals and retesting, see what to do after a vulnerability scan report.

Notifications from outside are triaged by type before deciding whether to act

Notifications from the search engine management tool are forwarded by the project team to the discussion thread with a question, and POLISH replies after triaging by type. Notifications about page redirects are left unhandled for now. Notifications about pages not found mostly come from old links that users saved: after a site redesign, old links are still visited, and a wrong address naturally returns a not-found response. The project team accepted this judgment and took no action for the time being.

One reason for triage is that interruption has a cost. Mark et al., 2008 found in an experiment that interrupted work was completed in less time with no difference in quality, but people compensated by working faster, at the price of more stress, frustration and time pressure. The study used laboratory tasks, and the point taken from it here is that interruption has a cost. POLISH triages first, so notifications that need no action do not break into a fix in progress.

What each periodic check records

When maintenance is outsourced, the agency carries a duty to select and supervise the contractor. Article 7 of the Enforcement Rules of the Cyber Security Management Act provides that when an agency outsources the construction or operation of information and communication systems or the provision of information and communication services, the selection and supervision of the contractor should take into account staffing, subcontracting, security testing of customized systems, incident reporting, and data handling upon contract termination, and that the contractor must be audited periodically, or inspected when an incident becomes known. For audits the article says only "periodically" and gives no specific number of days.

The FAQ of the Administration for Cyber Security, Ministry of Digital Affairs explains that the selection of the contractor needs attention before outsourcing and supervision is needed afterward, with contract provisions and project management recommended as the means. The same explanation notes that for core systems, or where the commissioned amount reaches ten million New Taiwan dollars or more, testing must be carried out by the agency itself or separately commissioned to a third party.

As part of the Ministry of Education project, POLISH moved from the design tender to the engineering tender and maintains the Outdoor Education Resource Platform over the long term, cooperating with the scans, the remediation of medium- and high-risk findings, and the false-positive appeals that the supervising agency requires. The annual penetration test and vulnerability scans are arranged by the supervising agency, and POLISH supports remediation and retesting. The table below lists the periodic items and the records each one leaves.

The host vulnerability scan runs monthly. After receiving the scan report, the project team notifies the engineering lead and sends the report. The engineer makes the fix within the deadline set by the supervising agency and replies when it is handled, and the project team then enters the handling description in the improvement progress sheet and reports it to the supervising agency. When only server settings are adjusted and the code is unchanged, the system change form need not be filed at first, but a brief description of the adjustment must still be provided for the sheet. Every scan has an owner, a reply and a record.

The annual penetration test proceeds in stages: a briefing on the work description comes first, then testing in rounds, followed by a briefing on the initial test report, and after remediation, a briefing on the retest report. The schedule and materials for each stage are relayed by the project team, and anyone who did not attend can watch the recording and slides after the briefing.

Before a backup restore drill, the project team first lists the requirements: after the standby machine is activated, the team must verify that the data is correct, and the verification steps, the comparison method (record count, content, file size) and screenshot evidence must be stated. After the drill, the engineer places the record and evidence in the shared cloud storage and provides a reachable test URL so that screenshots can be added. After the project team confirms that the evidence is sufficient, the machines and related settings used for the drill are cleaned up. The order is to keep the evidence first and clean up the drill environment afterward.

Static code analysis follows no calendar and runs automatically each time the main branch is updated.

Data for the maintenance report is prepared at handover

A maintenance report needs traceable data, and when an existing system is taken over, its current state must be established first. POLISH lists the preparation work from two perspectives.

• Building from scratch: set up automatic backups, make sure the logging mechanism is complete, and confirm that report data can be retrieved quickly with a program.
• Taking over an existing system: first confirm the software installed on the server and the deployment method, the backup scope and storage path, the logging settings and storage path, and whether a data-retrieval program already exists.

The monthly report is delivered to the project team at the beginning of the following month and forwarded to the supervising agency. After reading it, the supervising agency points out statistical trends in the monthly report that call for attention, the project team relays this, and POLISH replies that it is received and analyzes the cause further.

For the code review when an existing system is taken over, see a full-code health check when taking over an existing system. For how delivery and maintenance evidence is organized, see delivery and maintenance evidence in public-sector projects.

Routine items and exceptions are recorded separately

The routine task each month is to collect the data needed for the maintenance report and produce the report in a format the project team accepts. Exceptions are written into that month's maintenance items and come from the following sources:

• Changes made in response to security notices
• Changes made in response to vulnerability scans
• Support for security audits

Keeping routine items and exceptions apart lets the report show what was done on a fixed basis during the month and what extra support was given. Sudden incidents follow a separate handling process; see the incident response process. For systems that include AI question answering, the practice of maintaining the refusal threshold and credibility is covered in maintaining an AI Q&A system after launch.

Work after delivery is often grouped under the single term maintenance and divided into four categories: perfective, adaptive, corrective and preventive. Rajlich and Bennett, 2000 argue that the period after delivery is in fact a series of different stages, each with different activities, tools and business consequences, and that both industry and engineering can benefit from understanding these stages and the transitions between stages. Because POLISH records routine items and exceptions separately, the maintenance report can present the two kinds of work separately.

The questionnaire study by Lientz et al., 1978 found that maintenance and enhancement take up most of the resources of systems and programming development groups, and that maintenance problems lean toward management. The study dates from 1978, and the point taken from it here is that maintenance problems lean toward management. Logging reports, periodic checks and maintenance reports address exactly this kind of management work. In long-term maintenance and platform development, POLISH uses a single list to record routine items and exceptions separately and delivers a monthly report in a format the project team accepts.

Situations where this approach does not fit

This order and cycle give limited help in the situations below, and the preconditions need to be addressed first.

• There is no plan for updates and maintenance after launch: reports and periodic checks have nothing to apply to, and no monthly report can be produced.
• There is no fixed project team or point of contact: reports have nowhere to be logged and no one to be assigned, so it must first be settled who takes calls and emails and who fills in the list.
• Records and backups are not retained: the maintenance report has no data source, and the logging settings and backup scope need to be completed before a monthly report is discussed.

What to prepare before starting

For post-launch maintenance to run smoothly, the following items should be ready before starting:

• A shared report list and a point of contact: who logs, who assigns, who replies to close.
• The supervising agency's requirements for scans, remediation deadlines and the improvement progress sheet.
• Backup scope and storage path, and logging settings and storage path.
• The format of the maintenance report, and the method for obtaining report data.
• The verification steps, comparison method and screenshot evidence requirements for backup restore drills.

The post-launch order and cycle can be written into the documents at the requirements stage. To discuss scope and approach, talk with POLISH about long-term maintenance.