Mostrar mensagens com a etiqueta ISO 15504. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta ISO 15504. Mostrar todas as mensagens

quinta-feira, 12 de maio de 2016

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.

segunda-feira, 2 de maio de 2016

The Phases vs. Processes "mess"

The Short Story


For the "mess" topic jump to the section marked with... "The Mess".

The Long Story


What are these terms: phases, processes, activities and tasks and how do they relate themselves between each other?

Phases, a series of distinct steps in carrying out a project that together constitute the project life cycle [Space Engineering (Software), ECSS-E-40b]. To assure effective phasing and planning, the life cycle shall be broken into phases, each having its with associated milestones.
Processes, are a set of inter-related resources and activities which transform inputs into outputs [ISO 8402:1994].
Activities, are a engineering or management practice that contributes to the creation of the output (work products) of a process or enhances the capability of a process, same as practice in [ISO 15504-9]. An activity may be described by a separate document, designated procedure, or directly by a set of tasks (may be based on a template).
Tasks, are a specific piece of work to be done to perform an activity. An activity is implemented by one or more tasks.

The QMS Engineering Processes

In waterfall, for new development projects (software development projects) we need phases to carry on the main work products we need in order to produce a deployed working solution (the final information system).

For that we typically use a process called "Software Development Process" (inputs: customer problems; output: deployed working solution).

This process makes use ("instantiates") other QMS processes, delegating to them the specifics of dealing with requirements, design, the code and the tests we need to do.

The most widely used QMS Engineering processes are:
  • ENG.1 - Requirements Analysis: Think what to do - SRS.
  • ENG.2 - Software Design: Think how to do - SAS, SDD.
  • ENG.3 - Software Construction: Do as we said we would do (acc. to SRS, SAS, SDD) and unit test
  • ENG.4 - Software Testing: Verify and Validate; Verify = test against requirements (are we doing things right, as specified?); Validate: Are we doing the right things (to solve the customer problems?) - TCS, TR
  • Sometimes you will find that QMS have one additional ENG process. 
  • ENG.5 Maintenance, that guides the maintenance team (a small part f the project team) through the last (post-delivery) phase.


Obs.: You'll need more processes (like te "Project Management Process", "Risk Management Process", "Scope Management Process" to mention a few) in order to carry out successfully a project. Above we are only referring to Engineering Processes.

The Relation Between Phases and QMS Engineering Processes (AKA "The Mess")

These processes are instantiated (used) in the several phases. So you can think of a matrix between phases and the processes that are needed to carry on the work needed to complete the phase and achieve successfully the milestone we are working to.

Typical milestone names are: PDR, CDR, QR, AR. KOM and PCM could also be milestones in the QMS SDP.

The world is not in black and white, so there is some overlapping in the effort spent by the team doing for instance requirements (even though the phases are mostly disjoint between each other: we finish the first phase and do formal milestone meetings in order to start the next one).

But for a typical project:
  • The [effort] peak for using ENG.1 should be at the requirements phase.
  • The peak for using ENG.2 should be at the design phase
  • The peak for using ENG.3 is at the SW Construction phase
  • The peak for using ENG.4 is at the last 2 phases (Validation Phase and Acceptance Phase)

PS. For systems development (think hardware + software) the V-Model is more widely used, even though you can see things like that just for software development (V-Model for software).

(2016-05-05: Formatting; 2016-05-18: Formatting and add.hyperlinking; 2016-07-20 minor formatting; 2016-10-03: short story link; formatting and minor rephrasings)