Estimation Process and related artifacts

Your QMS could include a process on estimation (that presents the estimation techniques and the associated activities to be executed in order to produce the final estimation sheets that are input for ROMs, Proposals, Change Requests, ...).

One example (INTERNAL):

• https://quality.critical.pt/qmsunified/SUP-support/SUP-09-estimation/CSW-QMS-2010-PCS-00878-estimation-process.pdf#search=sum%20up%20xls

Some common artifacts include templates and models to help you estimating (INTERNAL, use the QMS Portal with the doc id enclosed in double quotes):

• Estimation form (template): CSW-QMS-2011-TPL-02102-estimation-sum-up.xls (now a xltx)
• Planning Poker form (template): CSW-QMS-2015-TPL-02398-planning-poker-estimation.xltx
• Effort Per Phase Model: CSW-QMS-2009-DOC-04974-effort-model-2014-baseline-data4all.xlsx
• Safety Critical Estimation Model: CSW-QMS-2014-DOC-01296-asd-estimation-model.xlsx
• Estimation @ CRITICAL Software - Study on the Estimation Process for CRITICAL Software Projects: CSW-ESTIMATE-2009-PCS-00707-estimation-process.doc

PS. If you're interested in estimation models, google for them. They are very dependent on the business you're working on although there are some attempts to generalize them. 

Example: COCOMO Estimation Model.

Key Process Areas in your QMS (ISO 15504, ISO 12207)

In a QMS several types of processes will be needed in order to accomplish your work. 

For a software development company, lots of core processes will be defined (engineering ones) but they are not enough. In the end you'll end with dozens of processes so it's a good idea to organize them in order to allow for some roles (e.g. engineers, project managers) not to get lost while starting. 

So, one of the main issues here is how to do this split between them? Again the main keyword is REUSE. Let's not invent the wheel. 

The key process areas in a Quality Management System can be based on the ISO15504/SPICE process model as well as the ISO12207 Life Cycle Model standards.

According to SPiCE for SPACE (ISO/IEC TR 15504 Conformant Method for the Assessment of Space Software Processes - Part A: SPiCE for SPACE Assessment Model, Issue 1.1 Draft C, 27.07.01, PASCON/WO6-CCN5/TN7A.) the following description is provided for each dimension:

Primary life cycle processes, includes customer-supplier processes and engineering processes. Customer-supplier processes have directly impact on the customer, support development and transition of the software to the customer, and provide for the correct operation and use of the software product and/or service. Engineering processes consists of processes that directly specify, implement, or maintain the software product, its relation to the system, and its customer documentation. In circumstances where the system is composed totally of software, the engineering processes deal only with the construction and maintenance of such software.

Supporting life cycle processes, includes processes that may be employed by any of the other processes (including other supporting processes) at various points in the software life cycle.

Organisation life cycle processes, includes management and organisation processes. Management processes contain practices of a generic nature that may be used by anyone who manages any type of project or process within a software life cycle. Organisation processes establish the business goals of the organisation and manage process, product, and resource assets that, when used by the projects in the organisation, will help the organisation achieve its business goals.

INTERNAL RESOURCE: The 5 QMS Engineering Processes

The QMS Software Development Process (SDP) delegates details to 5 engineering processes: 

1. ENG01 - Requirements Analysis: Think what to do - SRS.
2. ENG02 - Software Design: Think how to do - SAS, SDD (also named sometimes as DDS, DDD), DBS.
3. ENG03 - Software Construction: Do as we said we would do (acc. to SRS, SAS, SDD, DBS) and unit test, code review (if applicable), ... 
4. ENG04 - Software Testing: Verify and Validate; used for validation tests/acceptance tests.
5. ENG.5 - Maintenance: Keep the system operating (and eventually expand it with new features); corrective maintenance, evolutionary maintenance, preventive maintenance, predictive maintenance, etc.; SLAs and 24/7 requirements could be applicable, depending on the maintenance contract; warranty period depends on target customer country legislation. 

PS. Remember that Agile/Scrum projects will typically follow another SDP and that you'll need lots of other Support (SUP.) and Management (MAN.) processes in order to execute with success bespoke development (and/or maintenance) projects.

Related lower level docs in the SDP might include procedures and guidebooks and/or templates (PRO, GBK, TPL):

• ENG01 related: Requirements Elicitation Procedure; Analysis Model initial structure (initial contents template) (GBK); Requirements Standard (GBK); 
• ENG02 related: Interface Specification Procedure; System Architecture GBK; 
• ENG-3 related: DD Procedure;

@2016-11-03: Updated links to Unified; added related docs section as per 2016-11 QMS;
@2017-04: Process links updated
@2017-11: Updated ENG01 and 02-related links

Main Work Products for Software Development Projects (Waterfall)

The waterfall phases aim to define:
- What to do? - requirements catalogue (mapping to features; features could map to requested features)
- How to do? - high-level architecture and (if needed) detailed design
- Execute! - produce the code, unit tests and reverse engineer the detailed design (if possible)
- Validate! - validate the system against requirements (are we doing things right?)
- Accept! - prove that the system solves the customer problems (to the customer or a customer representative). Are we doing the right things? Deploy (transfer).
- Maintain! - keep the system up and running (and optionally evolve it - new features, changed features)

The core work products (outputs of applying QMS Engineering processes) are:
- SRS (Requirements Spec)
- SAS (Architecture Spec document - High Level Design; could include sections for ICD, DBS)
- SDD (Detailed design which could include a section for the DBS)
- The Code
- STS (and the STR, i.e. the test report)
- ATS (and the ATR)

In order to execute the project you'll also need plans (management documents, outputs of applying QMS Management or QMS Support processes) as well as present reports:
- PMP (Project Management Plan),
- CMP (Configuration Management Plan);
- CIL (identifies the review strategy for each item - and lists external CIs)
- QAP (Quality Assurance Plan)
- SVP (SVVP, and some similar docs could exist due to regulatory requirements)

- SPAR (SW Product Assurance Report - metrics per milestone)
- Milestone Reports
- Progress Reports (per milestone or per time period - e.g. monthly)
- etc.

PS. Remember that not all these documents need to be deliverables: A Deliverable requires extra peer review and formal customer acceptance (and all this takes you away precious time). Typically the project proposal identifies the minimum set of deliverables.

(@2016-10-13: rephrases, expanded acronyms)