from specified features to implementation details

SW Projects - Roadmap
Definition of the SW project
Understanding the needs of the customer and make it clear specifications and system requirements, is the crucial first step.

We should try to estimate realistically (time, cost and working methods) for the realization of future system.
We should define necessary human and technological resources.

Implementation roadmap is an execution plan that matches short-term and long-term goals - MILESTONES with specific technology solution to help meet those goals.

- It helps reach a consensus about a set of tasks, needs and the development required to satisfy those needs;
- it provides a mechanism to help forecast developments and it provides a framework to help plan, monitor and coordinate work to be done
Project Methodology is structured into the following phases.

Project preparation - This phase provides initial planning and preparation for the project. Each project has its own unique objectives, scope, and priorities. The deliverables described in this phase assist in completing the initiation and planning steps in an efficient and effective manner – like setup of project governance, project plan and project schedule are prepared at this stage.

Scope validation - The purpose of this phase is to achieve a common understanding of how the company intends to run SAP to support their business. It focuses on the rapid setup of environment that is available for validation workshop with business users to confirm scope and determine delta requirements that will be realized in the next phase to enhance the baseline provided by pre-assembled RDS.

Realization - The purpose of this phase is to implement all the business process delta requirements defined during the Scope Validation phase. The team configures, develops, tests and documents the solution in series of time-boxed iterations. Before the solution is released to next phase it is fully end-to-end integration tested and accepted by end users.
Customers sometimes have only a vague idea of what may be required for certain features to cost. For this once communicated clearly the costs, you can readjust the features specification, and get a second, more contained, project definition with the budget acceptable to the customer.

Why plan?
Before talking why planning is often ignored, it is important to discuss why it is needed in SW projects.
In short, the planning serves to:
* Define and manage project scope - Requirements specification
* Establish the detailed technical requirements, including the interfaces to people, to machines, and to other software systems - Design
* Sw architecture and interchangeable, interoperable compartmentalised software components - Design
* Identify and minimize risks to the project - Design
* Securing the necessary resources: expert team with the right skill set, time allocation for different development tasks, cash flow - Planning
* Establish the sequence of realistic goals - Roadmap
* Separate the project into phases and activities clearly manageable - Roadmap
* Assess the time allocated to the project in stages of development - Roadmap
* Keep track of your progress and monitor the project - Roadmap

These points apply to web projects of all shapes and sizes. Not being able to satisfy all of these points at all stages of any project, often can compromise the success of the project.

Linux, Chrome and Mozilla are examples of good planning and fine management.The incremental development model, with rapid iterations can deliver satisfactory software solutions. It is good to start with small working code, and carefully extend it with new features. Problem solving deals with finding out what is the problem and then figuring out different alternative ways to fix the problem. While developing an improved solution, often the greatest technological innovations are created. All with a small increments.
It is good to have in your project:
- Well defined modular architecture.
- Compartimentalised software components with clearly defined interfaces.

"According to program manager Anthony Laforge, the increased pace is designed to address three main goals:
- One is to get new features out to users faster.
- The second is make the release schedule predictable and therefore easier to plan which features will be included and which features will be targeted for later releases.
- Third, and most counterintuitive, is to cut the level of stress for Chrome developers.

Release is like a predictable train and features like wagons added when ready and not before.
Laforge explains that the shorter, predictable time periods between releases are more like “trains leaving Grand Central Station.” New features that are ready don’t have to wait for others that are taking longer to complete—they can just hop on the current release “train.” This can in turn take the pressure off developers to rush to get other features done, since another release train will be coming in six weeks. And they can rest easy knowing their work isn’t holding the train from leaving the station."

---------------------
Core functionality
---------------------
Start small! Iterate! As long as the core requirements remain, everything will be fine. Additional functionality can always go into "the next release," but if you don't deliver the core functionality, there won't be a next release.
A really experienced project manager might even include in his project with a little superfluous functionality that could be sacrificed if/when the crunch comes, and it will come sooner or later.
Cutting functionality may seem a drastic measure, but an experienced project manager will happily whittle away functionality as if they were peeling a potato.
Scope creep is the almost unstoppable tendency a project has to accumulate new functionality. Some scope creep is inevitable since, early on, your project will be poorly defined and will need to evolve. A large amount of scope creep however can be disastrous.

--------------------------------------
MILESTONE development planning
--------------------------------------
Quality Assurance QA test planning, precedes code crafting, growth and refinement. We must creates a test plan and populate it with test cases from trivial to complicated one with desired results outcome. We should also relate test cases to functional requirements, deploy a test plan, start executing test cases and designate them as successful or failed. We must create the software which generates reports on our test cases.
During the development we should also be able to:
- specify valid test parameters
- create a sequence of test instances in a batch,
- MILESTONE development planning, starting with simple but functional code
- monitor test case execution in a Log file, and report success, failure, and a type of error or warning during and after the execution of the code
- add and to remove particular test cases from the test batch
- do requirements tracking
- track the software growth, mutations and evolution on the roadmap milestones
- do bug reporting and solution tracking
The Milestones and Incremental Development process is not only a great way to map out complex functionality, it's also IMPORTANT to test out critical features before they're launched. During our INCREMENTAL DEVELOPMENT process we can make some changes in the application structure in an effort to better organize bug-tracking, development and feature releases.

-----------------------------------------------------------------------------------------
Additional Tasks:
- Use early product prototypes -mockups to bridge the gap between marketing and engineering
- User Manual / mockup & menus
- Approved product definition
- Terminal Diagnostic
- System diagnostic (echo, log monitoring, health monitoring)


------------------------------
Nightmare liner
-----------------------------
The Boeing Dreamliner programme, announced in 2003, was supposed to cost $6 billion and see the plane take to the air in 2008. The final bill was $32 billion and the 787 Dreamliner arrived three years late.

The result of a combination of various technical failures and supply-chain chaotic mess. With engineers, designers and other resources diverted into saving the Dreamliner production plans, the rest of its production were delayed.