|
Commonsense CM Strategies to Meet Good Quality Requirements Quality requirements are an elusive goal for any complex product development effort. A strong process and good tools can help advance requirements toward higher quality over time. The product development team plays an important role in establishing quality requirements. In a well-oiled customer/ developer relationship, frequent feedback will go both ways. Unknowns will be explored and change will occur. It's important that CM/ALM tools can clearly track requirements and their changes in a way that helps to capture increasingly improved requirement baselines.
|
|
|
The One Right Way to Achieve High-Quality Requirements: Many authorities have undertaken to lay out the one right way to engineer system requirements. Although there are similarities among them, what is most striking is the diversity in approaches and, in some cases, conflicting philosophies. What are we to make of these dueling authorities and their competing guidelines?
|
|
|
Traceability and Auditability: Satisfying your Customers When we deliver software products, we need to be able to tell our customers what they're getting. Not only product documentation, but specifically, every time we deliver a new release we need to relay what problems were fixed and what new features were added. If the software is subject to periodic audits, we need to tell them even more, especially the abiltiy to trace a requirement or change request to what was changed.
|
|
|
How Audit Trails and Traceability Mitigate Risk Traceability doesn't prevent errors and an audit trail does little to help me to recover from one. Does this mean they aren't valuable CM tools? On the contrary, audit trails and traceability are two of our most important CM tools for learning how to mitigate risk.
|
|
|
Lean Development Principles for Branching and Merging By reworking lean principles for the branching and merging arena, we're able to create automated builds and unit tests to increase effectiveness and improve quality in software configuration management. Individual developers and teams alike can benefit from this process-improving strategy.
|
|
|
Configuration Management Planning: What To Do Before you Start Configuration management planning should not start as you put together your CM Plan. By then, you've already predisposed yourself to how your plan is going to play out.
|
|
|
Why It's Important for CM and Project Management to Work Together One of the problems with Configuration Management (CM) and Project Management (PM) is that the tools and the data repositories for each are separate. As a result the processes are quite separate. The project manager takes a set of requirements and decomposes them into tasks, which are then prioritized, scheduled and assigned. The CM team creates configuration items and tries to tie the CIs back to the requirements so that they can be properly audited. When CM and PM work together they tend to enhance each others function, and eliminate potential overlap in the processes.
|
|
|
Allowing Project Management (PM) to Help Configuration Management (CM) Is there a place for project management in the establishment of a configuration management (CM) infrastructure? If so, then how much project management should be included? A thin but strong layer of PM may be helpful to tie tasks together and keep project team members in-sync with one another.
|
|
|
How to Make Your CM Process Agile To make your CM process agile, go through it and identify how you can reduce end-user complexity, tool misfits, and areas of greatest risk. An agile CM process is one that supports all team members, making them more productive and simplifying their management tasks.
|
|
|
‘Oh Process!' - How does it matter? Location: IT organization with clients all over the globe
Scenario: Project team busy in getting things ready for code delivery to client. They are infuriated when Quality Auditor comes for audit.
Background: Project facing schedule overrun
Actors: Developers, Testers and Team Leader
Though this is a common scenario faced in majority of software organizations across the globe, it cannot be written off by saying that, it is got to do with the people who resist process or process which doesn't aid delivery.
|
|