The-Software-Experts




Google
 




   catch your bugs!
  Home
  Newsletter
  Forum
  Shop

  SW-Training
  - Software Design
  - Safe Coding in C
  - Software Inspection
  - Software Testing
  

  SW-Design
  - Architecture
  - Module Design
  

  Coding in C
  - Safe Coding in C
  

  Refactoring
  - Principles
  - Methods
  

  SW-Testing
  - Principles
  - Static Analysis
  - Inspections
  - Module Tests
  - Functional Tests
  - Integration Tests
  - Test Documentation
  - Links
  

  SW-Documentation
  - SGML Principles
  - Printing SGML
  - Links
  

  SW-Processes
  - Process Descriptions
  - Process Assessments
  - Self Evaluation
  - Food for Thought
  - Links
  

Safety Software
Design Training

IEC 61508 compliant
Safety Software
Design for Microcontroller

SW Document
Templates

CMMI and SPICE
compliant document
templates

SW Process
Description

CMMI Level 4 and
SPICE compliant SW
development procedure

SGML Package for
Documentation

Edit and print SGML
Documemts. Professional.
fast, easy to use.

Test Bench
for C/C++

Perl based test
environment for easy
component testing

Free SW Development Process Evaluation

This form provides a free self-evaluation for you SW development processes. Mark the appropriate answers if they are true for your project / organization, or leave them unchecked if they do not apply. The results of the evaluation will be mailed to you automatically. Please note that the evaluation is not intendet to be a proper CMMI or SPICE assessment or replace it. It only can give you a rough impression of where your project and organization can be located on the scale of maturity. If you have additional requests for consulting or any questions, please fill in the address part of this form completely and we will contact you.



Title         
First name  * 
Family name * 
Company       
Street        
Post code     
Town          
Country       
Telephone     
E-Mail      * 
Request       

Fields with * have to be filled in!

Key Process Areas for CMMI Level 2

Requirements Management

We have a defined and documented way to come to an agreement about requirements with our customers (an internal department may be also regarded as a customer).
All our technical requirements are defined and documented.
All our non technical requirements, such as delivery dates and delivery contents are defined and documented.
All requirements are reviewed with the appropriate stake holders and the reviews are documented.
The requirements are the basis for further activities, especially planning, design and testing.
The requirement can be traced into the other work products as e.g. the time schedule and design documents.
We have a training for the appropriate project members about requirements management.
We have a documented way to measure the status of the implementation of the requirements in the project.
The implementation of the requirements is verified by a periodic check by the quality group.


Software Project Planning

The technical requirements of the product, the goals and constraints are clearly defined and documented. (best case this is settled at the start of a project, if not there are iterations to come to a clear definition).
The project content is split up into clear steps and work packages.
There is a defined way to estimate the size of the work packages, and the estimation results are documented.
The work package estimations are the basis of a time schedule and assignment of work packages to project members.
The resource estimation is performed properly, based on the work package estimation.
There is a SW development plan (project handbook) where the goal, constrains, deliveries and milestones of a project are documented. The responsible persons for roles and work packages in the project are assigned in this plan.
We have a meeting to collect possible risks. The risks are documented and possible measures against the risks are identified. In case of constant high risks the risk meeting is repeated periodically.
A regular project meeting is taking place to address and discuss changes in the project planning and the related changes in the work packages of the project members.
The project meetings are documented in minutes and the resulting changes to the project are reflected in updates of the SW development plan, time schedule and resource planning.
The project progress is measured and compared to the actual planning. (E.g. completion of work packages and work products at certain milestones)
The project planning and progress is reviewed on a periodic as well as event driven basis with the senior management.
The project planning and progress is reviewed on a periodic as well as event driven basis with the quality group.


Software Project Tracking and Oversight

A project manager is designated to be responsible for the project activities and results.
Our projects follow a written organizational policy for managing projects.
The basis for tracking activities is a written software development plan (project handbook), the related time schedules (these may be done in a different tool but have to be referenced by the software development plan) and the related estimation documents.
We have defined milestones for our projects at which defined and agreed results of the project should be accomplished.
We have periodical checks on the projects to compare the planned and estimated work package size, efforts and costs against the actual performance of the project.
Corrective measures are taken to either adapt the plan to the real situation or to improve the performance of the project.
Corrective actions are always communicated to and agreed with the concerned groups and individuals.
There are adequate resources assigned to perform a periodical project tracking.
The project managers are especially trained to manage projects. The training includes the planning, estimation and tracking processes.
There are formal reviews at defined milestones in the project lifetime to check the deviations between the agreed plans and the project performance.
The tracking results are periodically communicated to and discussed with the senior management.
The quality group will periodically check for deviations between the plan and the project performance.


Software Subcontract Management

Check this box if you do not have any subcontractors for your projects (consider all! Software, Hardware, Mechanical), and leave all other checkboxes of this section unchecked!
Our projects follow a written organizational policy for subcontract management.
A subcontract manager is designated and responsible to establish and manage subcontracts.
The projects are provided with adequate resources and funds to select subcontractors and manage the subcontracts.
Subcontract managers and other involved persons are trained to be able to perform the establishing and managing of subcontracts.
Subcontract managers receive support from the appropriate groups and individuals to deal with the technical aspects of subcontract management.
The work to be subcontracted is clearly defined and planned according to a written procedure.
The subcontractor is selected on evaluation of the bidder's ability to perform the work. This is done according to a documented procedure.
An agreement is established between the prime contractor and subcontractor and is documented in a contract. This is used as a basis to manage the subcontract.
The subcontractor's software development plan is reviewed and approved by the prime contractor.
Periodical meetings are held with the subcontractor to track the project management of the subcontractor and review the progress of the technical work.
The quality assurance group of the prime contractor periodically checks the software quality activities of the subcontractor according to a defined procedure.
The configuration management group of the prime contractor periodically checks the configuration management activities of the subcontractor according to a defined procedure.
There is a defined acceptance testing at the prime contractor for any deliveries from the subcontractor.
The prime contractor collects project and performance data for a statistical evaluation of the subcontractor.
The quality group of the prime contractor evaluates and audits the subcontractor according to a defined procedure.


Software Quality Assurance

There is a written organizational policy about software quality assurance which the projects will follow.
There is an independent sofware quality assurance group. It has to be independent from the project organization and has to have a reporting possibility to senior management.
There are adequate resources and funds to perform software quality assurance. This relates to the independent SWQA group but also to the project itself.
The members of the SWQA group are trained to perform the software quality assurance activities.
The members of the project receive orientation about the SWQA activities performed by the quality group.
The project has a software quality assurance plan according to a documented procedure.
The activities of the SWQA group are performed according to the SWQA plan.
The SWQA group participated in the preparation and review of the project's software development plan, standards and procedures.
The SWQA group reviews periodicallly the activities of the project group to verify the compliance to the plans and standards.
The SWQA group verifies designated work products to check the compliance to the standards.
The SWQA group reports periodically to the project manager and project group about deviations from the standards and plans. Deviations are documented and handled according to a defined procedure.
Measurements are performed to evaluate the performance and activities of the SWQA group and to determin the costs of SWQA activities.
The SWQA group reports periodically to the senior management about SWQA activities and project status.
The activities of the SWQA group and project work products are periodically checked by independent experts.


Software Configuration Management

There is a written organizational policy about software configuration management which the projects will follow.
We have a software change control board established which has the authority to manage the project's baselines.
There is a designated group or individual which is responsible to implement the configuration management for the project.
There are adequate resources and funds to implement a configuration management for the projects.
The members of the configration management group are adequately trained to perform all configuration management tasks.
The members of the project are adequately trained to perform their configuration management tasks.
A configuration management plan is established for each project according to a defined procedure.
The documented and approved configuration management plan is the basis for the CM activities.
A configuration management library (version control system) is established as a repository for the software baselines.
The work products which have to be under configuration management are clearly identified.
Change requests and problem reports for all configuration items are recorded, reviewed, approved and tracked according to a documented procedure.
Baselines and their related products are released according to a clear procedure and their content is reconstructable at later times.
The status of the configuration items is recorded according to a defined procedure.
A CM reporting about the CM activities and baselines is performed by the CM group. A CM auditing is performed to report the status and quality of the CM activities.
Measurements are performed to collect data about the CM activities and baselines.
The CM activites, baselines and their compliance to the defined procedures is periodically checked and reported by the quality group.




Key Process Areas for CMMI Level 3

Organization Process Focus

The organization follows a written policy to coordinate the development and improvement of software development processes across the whole organization.
Senior management sponsors and controls the organization's efforts of process development and improvement.
There is a group which is responsible for the process activities in the organization.
There are adequate resources and funds to perform the process activities of the organization.
The members of the process group receive adequate training to perform the task of process definition and improvement..
The members of the organization receive adequate orientation and training to be able to fullfill their designated roles and activities as defined in the process.
The processes are assessed periodically and action plans are set up to improve the processs according to the assessment findings.
The organization maintains a plan and coordinates its process development and improvement activities.
Your activities for developing and improving the software processes are planned and coordinated at organization level.
There is a software process database and it is coordinated at organization level.
New processes, methods, and tools are monitored and evaluated and their use is adapted according to the findings of the evaluation.
There is training for the software processes and it is coordinated across the organization.
The persons and groups involved in the implementation of the software processes are informed periodically about the overall activities for software process development and improvement.


Organization Process Definition

Your organization has a documented procedure which describes how the software process is developed and maintained.
Your organization has an applied standard for documenting the software process.
Your organization has a description of the software life cycle which is used for all projects.
There are guidelines and criteria for the projects' tailoring of the organization's standard software process, and these guidelines are applied.
You organization has a maintained library of software process related documentation.


Training Program

Each software project has a training plan that specifies the training needs of the project members.
The organization has a training plan which is developed and revised according to a documented procedure.
The trainings for the employees in the organization are performed in accordance with the organization's training plan.
The training courses for the organization are developed and maintained according to organization standards.
There is a procedure which enables your organization to determine whether individuals already possess the knowledge and skills required to perform in their designated roles.
Records are maintained for all trainings.


Integrated Software Management

Your project's software processes are developed by tailoring the standard software process of the organization and this is performed according to a documented procedure.
The software processes of the projects, which were generated by tailoring, are revised according to a documented procedure.
The software development plans of the projects, which describe the tailoring of the standard software process, are developed and revised according to a documented procedure.
Each software project is managed in accordance with the project's defined software process.
The software process database of the organization is used for software planning and estimating..
The size of the software work products is estimated and managed according to a documented procedure.
The software efforts and costs of the projects are estmiated and managed according to a documented procedure.
The project's critical computer resources are estimated and managed according to a documented procedure.
The critical dependencies and critical paths of the project's schedule are managed according to a documented procedure.
The project's risks are identified, assessed, documented, and managed according to a defined procedure.
Periodical project reviews are performed to determine which actions are needed to bring the project results in line with the planning and actual needs.


Software Product Engineering

Appropriate software engineering methods and tools are established and integrated into the software process of each project.
The requirements are developed, maintained and documented by a systematic analysis and this activity is reflected in the project's software process.
The software is design developed, maintained, documented, and verified, according to the project's software process.
The implementation of the requirements is traced into the design, so that it can be verified that the requirements are implemented completely and correct.
The developed software code is maintained, documented, and verified, according to the a defined process.
It is verified that the software design is implemented correctly and complete in the software code.
Software testing is performed according to a defined procedure.
System and acceptance testing of the software is performed to verify that the software satisfies its requirements.
The documentation that will be used to operate and maintain the software is developed and maintained according to a defined software process.
Data about defects, as identified in peer reviews and testing, is collected and analyzed.
It is guaranteed that consistency will be maintained across software work products, as e.g. software plans, process descriptions, requirements, software design, code, test plans, and test procedures.


Intergroup Coordination

All relevant groups as e.g. software engineering group, other engineering groups, customer or end users are involved in the establishing of the system requirements.
Members of the software engineering group cooperate with members of the other engineering groups to monitor and coordinate technical activities and resolve technical issues.
A documented plan exists, which is used to communicate intergroup commitments and to coordinate and track the work performed.
The critical dependencies between engineering groups are identified, negotiated, and tracked and is this documented.
The work products which are an input to other engineering groups are reviewed by members of the receiving groups to ensure that the work products meet their needs.
There is a procedure to escalate or handle intergroup issues which are not resolvable by the individual representatives of the project engineering groups.


Peer Reviews

Peer reviews (examination of technical documents and source code by experts) are planned, and the plans are documented in your projects.
Your peer reviews are performed according to a documented procedure.
The data on the conduct and results of the peer reviews are recorded.




Key Process Areas for CMMI Level 4

Quantitative Process Management

There is a strategy and definition on organizational level which process performance data (process metrics) shall be collected and how they shall be collected and analyzed.
The projects maintain a plan for quantitative process management according to a documented procedure.
The software project's quantitative process management activities are performed in accordance with this quantitative process management plan.
The software process of each project is analyzed and brought under quantitative control according to a documented procedure.
There is a defined reporting for the results of the software project's quantitative process management activities.


Software Quality Management

The project's software quality plans are maintained according to a defined procedure.
The project's software quality plan is the basis for the software quality management activities.
The project's quantitative quality goals for the software products are defined, monitored, and revised throughout the software life cycle.
The quantitative quality goals for the product are communicated to the subcontractors delivering software and the goals are monitored.






Key Process Areas for CMMI Level 5

Defect Prevention

Your software projects maintain a plan for defect prevention activities.
The members of the team working on a task are trained for the related defect prevention activities.
Defect analysis meetings are performed according to a defined procedure to find the rout cause of defects.
The implementation of action proposals from the defect analysis meetings are coordinated and tracked.
Defect prevention data are collected and their use is tracked across the projects.
If defect prevention activities result in process changes, the revisions of the organization's standard software process, or the revisions of the tailored process of the projects, are incorporated according to a defined procedure.
The members of the software engineering group and related groups receive feedback on the results of the defect prevention activities on a periodic basis.


Technology Change Management

The organization maintains a plan for technology change management.
The group responsible for the organization's technology change management activities cooperates with the software projects in identifying areas of technology change.
Software managers and technical staff is informed of new technologies.
The technology change group of the organization systematically analyzes the standard software process to identify areas that could benefit from new technology.
Technologies are selected and acquired according to a documented procedure.
New technologies are piloted before they are introduced into normal practice.
Appropriate new technologies are incorporated into the organization's standard software process and into the projects according to a documented procedure.


Process Change Management

A software process improvement program is established in your organization. This empowers the members of the organization to improve the processes.
There is a group responsible for the organization's software process activities and it coordinates the improvement activities.
The organization maintains a plan for software process improvements according to a documented procedure.
The software process improvement activities are performed according to an improvement plan.
Software process improvement proposals are handled according to a documented procedure (e.g. a change management system).
Members of the organization actively participate in teams to develop process improvements for assigned process areas.
Software process improvements are piloted to determine their benefits and effectiveness before a general rollout is performed.
There is a documented procedure which describes how to transfer software process improvement into normal practice.
Records of software process improvement activities are maintained.
Software managers and technical staff receive feedback on the status and results of software process improvement activities.


     












Imprint