Contingency Planning by John-Jan Popovic

Before we start coding
-------------------------------------------------------
REFINEMENT OF THE PRODUCT REQUIREMENTS
------------------------------------------------------
“The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements.”
—Fred Brooks


The basic concept is
a) to define a specification of a program // REQUIREMENTS & SPECIFICATION
b) to define a solution to that specification // DESIGN & CODING
c) prove that a program meets that specification // TESTING & VERIFICATION

Omissions and errors occur in all three stages a), b) and c) and not only during the stage b). It is misconception that errors occur only during Design & Coding.

-----------------------------
DATA AT THE BEGINNING
-----------------------------
At the beginning I am focused on DATA, all files in the system: structured and non structured data, input data, output data, error logs, configuration files, etc. A database as a collection of related information and their data records structure. And what must be done in order to process input files into desired output behaviour and data. What are the test scenarios, and if the customer has provided production-quality test data together with requirements? Is it possible to provide realistic production data sets upfront for the future system?

---------------------------------------
• Create the user manual upfront
---------------------------------------
Some organizations have had good success creating their user manuals as a substitute for or supplement to a traditional requirements specification. End users and customers, seem to be better able to understand the contents of a user manual than a traditional requirements specification, and requirements elicitation goes then more smoothly.

---------------------------------------
Architecture - Frederick P. Brooks
---------------------------------------
By the architecture of a system, I mean the complete and detailed specification of the user interface. For a computer this is the programming manual. For a compiler it is the language manual. For a control program it is the manuals for the languages or languages used to invoke its functions. For the entire system it is the union of the manuals the user must consult to do his entire job.
The architect of a system, like the architect of a building, is the user's agent. He is end-user advocate. It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user, as opposed to the interests of the salesman, the fabricator, developer, etc. [2]


----------------------------------------------------------------------------------------
Cone of Uncertainty - DEVELOPMENT PLANNING & PREREQUISITES
----------------------------------------------------------------------------------------

To be able to make more realistic estimate of the workload and start planning, we should have answers to these two CRUCIAL questions:

A1. Enlist, what assumptions and preconditions have NOT been yet fulfilled; so we can not start to make any estimate of the volume of work and start planning development?
A2. Have the end user/ client CONFIRMED the future solution mockup (interface layout and operating procedures), before the coding has started!?
A3. Create clear Startup Conditions Checklist - Explain what each activity and deliverable is.

Most software projects are subject to inherent errors in early estimates.
The Cone of Uncertainty represents the best-case reduction in estimation error and improvement in predictability over the course of a project.
Skillful project leaders treat the cone as a fact of life and plan accordingly.

Software development is a process of continuous refinement.
A well-run software project attacks areas of highest variability first to narrow the cone as rapidly as possible. Active control is needed throughout the project to keep the cone from widening again.

0. Initial concept
Systems analysis, requirements definition: Defines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.

1. Approved product definition
Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
2. Marketing / business requirements complete
3. Detailed technical requirements complete
4. Detailed design complete

5. ONLY NOW YOU CAN START TO CODE!
---------------------------
Requirements
---------------------------
Requirements describe in detail what a software or web system is supposed to do, and they are the first step toward a solution. You decide on the scope of the system before you begin programming or web development.

---------------------------
Requirements Checklists
---------------------------
Requirements checklists should address and identify:
- duplicated information
- missing information
- vague or unclear information
- Use cases set and scenarios/ will help gathering, organizing and verifying requirements.
- review - feedback from previous work efforts

-------------------------------------------
Why Have Official Requirements?
------------------------------------------
An explicit set of written requirements, specifications and design guidelines is important for several reasons.
Explicit requirements help to ensure that the user/customer rather than the programmer drives the system's functionality. If the requirements are explicit, the user can review them and agree to them.

Explicit requirements also help to avoid arguments. If you have a disagreement with another programmer, designer or customer, about what the web system, program or applications is supposed to do, you can resolve it by looking at the written requirements, specifications and design guidelines.

------------------------------------
Backlog or ToDo or task-list list
...........................................
Creating a task-list list helps you define the work that needs to be done. Once you have a backlog, you can use it to help manage when that work gets done, as well as associate items on the backlog with check-ins, acceptance tests, or other criteria.


---------------------------------------------------------------------------------------------------
BIG PICTURE ROADMAP: Where you're, and where are you going?
---------------------------------------------------------------------------------------------------
★ Programming without an overall architecture or design in mind is like exploring a cave with only a flash-light: You don't know where you've been, you don't know where you're going, and you don't know quite where you are.
- Danny Thorpe, former Chief Architect of the Delphi programming language

---------------------------
Proactive vs. Reactive
---------------------------
Contingency planning is the process of identifying potential risks to the business and developing a comprehensive plan that enables the company to respond to any threat or disaster and quickly restore normal business operations. Contingency planning is a proactive strategy that emphasizes preparation over response. Crisis management is the process of managing the response to a major incident after it has occurred. It is a reactive strategy that emphasizes response over preparation.

Project health checks
Tracking projects at a low level is part of ongoing project management, but you must also be able to every now and then during the project’s existence sit back and review the project from a higher level to gain a view of the project’s overall health and status. By taking a weekly summarized view of the project, you will be able to more effectively manage the project and lead the team.


.
Software strategic planning is the process by which the customers and developers envision the future together and set the necessary procedures and operations to achieve the desired software solution.

We think that tracking development milestones is a great way to monitor development progress and see which parts of the software are being developed, improved or fixed.

We can also see which parts of the software have not been planned, designed, coded and tested yet. The hardest single part of building a software system is deciding what to build, and how to approach to difficult problem, decomposing its complexity, by maintaining high development standards.

PLEASE NOTE: The planning process can be viewed as a somewhat spiral flow of topics and action steps, where the results from one step initiate study and action in the next step.

However, the development process does not necessarily always flow in one direction. Issues that arise in a particular solution may cause the planning team to go back to an earlier step to do additional work, implement new features and insert new milestones in the roadmap or refine the application functionality.

If desired, the order of the MILESTONES can even be altered to suit the particular needs of the planning team. The implementation step also does not end the planning process. Analysis of results could easily result in additional analysis or a change in strategic direction. Also, it is recommended that the plan be reviewed periodically, sometimes even on a daily basis in order to verify that all the base assumptions are still valid and that the implementation plan is progressing according to expectations.

------------------------------
Grow, Don't Build
------------------------------
Create a tiny seed of working code with CORE FUNCTIONALITY that can grow into what you desire.
Working software is constantly released in a sequence of tiny iterative and incremental testable commits — becoming progressively more useful as it is developed.