FDE.LI Six Delivery Standards v1.0

Foreword

Version
1.0
Maintained by
Yanhuang Epoch (Shenzhen) Technology Co., Ltd. (credited as the Yanhuang Epoch FDE team)
Licence
CC BY 4.0

Contents

  1. 1 Scope
  2. 2 Terms and definitions
  3. 3 Requirements of the six standardsnormative
    1. 3.1 Invisible Clause text still being finalised
    2. 3.2 Emergent Clause text still being finalised
    3. 3.3 Fault-tolerant Clause text still being finalised
    4. 3.4 Bounded Clause text still being finalised
    5. 3.5 Traceable Clause text still being finalised
    6. 3.6 Measurable Clause text still being finalised
  4. 4 Onboarding (early stage)
  5. 5 Design (early to middle stage)
  6. 6 Acceptance and redeployment (middle stage)
  7. 7 Iteration (later stage)
  8. A Annex A (informative) Pattern library
  9. B Annex B (informative) De-identified cases

1 Scope

This standard covers one thing: how to do FDE well.

It sets out the six standards that FDE delivery must meet (chapter 3), and the practice for each of the four stages: onboarding, design, acceptance and redeployment, and iteration (chapters 4 to 7). The pattern library in Annex A and the de-identified cases in Annex B are informative.

4 Onboarding (early stage)

When we start on site, we check what we know against the six standards and note how each gap would affect delivery. A gap the client has explicitly accepted is acceptable.

The first four weeks on site go in this order.

Week 1: we shadow the work as it is actually done, not as it is documented, and start measuring the baseline on day one. That measurement is time-sensitive: once the system begins to affect how work happens, the window to record the before has closed for good.

Week 2: we mine the history (tickets, chats, mail and documents) for the vocabulary, the precedents and the exceptions that no one ever wrote down. Every integration point is tested by hand, because the API documentation is usually missing or wrong. We draft the high-risk operations list and the data classification.

Weeks 3 and 4: we collect three signatures: the high-risk operations list, the data classification, and a written acknowledgement of anything the client has chosen to go without. The human fallback is tested for real response time, not promised. The capability map is closed.

Then: with the signatures in hand, the baseline recorded and the capability map final, we write the first line of code.

5 Design (early to middle stage)

The text of this chapter is still being finalised and will be published here.

6 Acceptance and redeployment (middle stage)

Mid-project, each process is checked against the six standards, item by item.

Redeployment comes first (people follow the bottleneck). We do not take on designs whose goal is to cut jobs, and we would not do them well.

7 Iteration (later stage)

The text of this chapter is still being finalised and will be published here.