Each term will be described in separate post. But please note: This blog addresses each part of the lifecycle in a holistic way. Just defect tracking is not interesting.
ALM is a live organism. One part cannot live by itself. Each aspect is a part of the whole, and this is the way I will address it.
ALM - Application Lifecycle Management, ALM 2.0, ALM for medical, SDLC - Software Development Lifecycle Management, SLM - Software Lifecycle Management, project management, process flow, risk management, high level/low level Requirements Management, high level/detailed design, R&D tasks, unit tests, test management - Test plan, Test automation, test run, test results, defect tracking, build manager, source code integration, change management, analytics, coverage matrix, traceability matrix, release manager, tracking and reports, Regulations, The PLM/ALM aspect, 3rd party integration, customer management, action items, release notes.
Friday, February 27, 2009
140 words on ALM prediction
140 words on ALM Prediction benefits
Why do managers need prediction? Why they know more than any ALM system.
True. No ALM analytics system can replace an experienced manager.
Well, prediction is not a replacement. It’s a decision support tool.
It can tell you when you should stop the development and check if you exceed the planed release; when your QA is diverging; when customers defect reporting trend is more than the organizational average. It can help you take decisions whether to implement a change in your product; asses the impact of change in terms of time and cost; asses affect on other components in your product.
To summaries – ALM prediction is not the new sheriff. It is a decision support tool helping us to cope with the ever-changing environment we all live in, and see what’s under the ground…
Why do managers need prediction? Why they know more than any ALM system.
True. No ALM analytics system can replace an experienced manager.
Well, prediction is not a replacement. It’s a decision support tool.
It can tell you when you should stop the development and check if you exceed the planed release; when your QA is diverging; when customers defect reporting trend is more than the organizational average. It can help you take decisions whether to implement a change in your product; asses the impact of change in terms of time and cost; asses affect on other components in your product.
To summaries – ALM prediction is not the new sheriff. It is a decision support tool helping us to cope with the ever-changing environment we all live in, and see what’s under the ground…
ALM blog - 140 words posts
I want to thank all of you readers for the emails, and my apologies for being away for 2 weeks.
I guess application lifecycle management is really a growing trend and I see lots of interest in the ALM area, both in the Internet and during my work.
The ALM posts from now on will be as short as possible and as focused as possible.
I am going to start 140 words posts (seems it's the spirit these days…)
I will make it as interesting and as strait to the point as possible.
I will talk about a research my company does these days, in the area of Application Lifecycle Management prediction, such as predict of future defects, a change impact on overall project, estimated cost, and much more.
Sounds like science fiction?
I agree.
Well, 140 words are over…
I guess application lifecycle management is really a growing trend and I see lots of interest in the ALM area, both in the Internet and during my work.
The ALM posts from now on will be as short as possible and as focused as possible.
I am going to start 140 words posts (seems it's the spirit these days…)
I will make it as interesting and as strait to the point as possible.
I will talk about a research my company does these days, in the area of Application Lifecycle Management prediction, such as predict of future defects, a change impact on overall project, estimated cost, and much more.
Sounds like science fiction?
I agree.
Well, 140 words are over…
Sunday, February 8, 2009
Useful Requirements Definition
Overview
This post describes the guidelines for a superior Requirements definition
Guidelines for requirements management:
1. Make short requirements
2. Make testable requirements
3. Make precise requirements
4. Make unique requirements
5. Manage requirements traceability in all ALM aspects (management, development, QA)
6. Define requirements workflow in order to manage requirements lifecycle effectively
7. Use hierarchy to manage a set of requirements by category (functional, security, general, safety, etc.)
8. Manage relations between requirements
9. Distribute requirements in different releases
Benefits of good requirements management:
1. Assisting in customer needs traceability. Basically, the SRS (Software Requirements Specification) will provide feedback to the customer
2. Setting clear expectation between development teams
3. Preventing scope deviations
4. Reducing development efforts
5. Providing the input for the testing team, in the validation and verification process
6. The first stage of requirements definition forms the basis for the project’s effort estimation
7. Good software management decompose the problems into component parts which are easy to understand, trace and cover by other ALM artifacts
The lifecycle of requirement definition process
Requirement first revision
“User shall be able to pay in several payment terms”
The revised requirement
“System will have a payment form, and user shall be able to enter this form and select a specific payment term”
This requirement can be broken down to several sub requirements, so we will use hierarchy to manage this set of requirements:
1. HEAD: Payment Module
1.1 REQ-112: Payment form
1.2 HEAD: Payment methods
1.2.1 HEAD: Credit card
1.2.1.1 REQ-114: Pay by Visa
1.2.1.2 REQ-115: Pay by Amex
1.2.2 REQ-116: PayPal
This post describes the guidelines for a superior Requirements definition
Guidelines for requirements management:
1. Make short requirements
2. Make testable requirements
3. Make precise requirements
4. Make unique requirements
5. Manage requirements traceability in all ALM aspects (management, development, QA)
6. Define requirements workflow in order to manage requirements lifecycle effectively
7. Use hierarchy to manage a set of requirements by category (functional, security, general, safety, etc.)
8. Manage relations between requirements
9. Distribute requirements in different releases
Benefits of good requirements management:
1. Assisting in customer needs traceability. Basically, the SRS (Software Requirements Specification) will provide feedback to the customer
2. Setting clear expectation between development teams
3. Preventing scope deviations
4. Reducing development efforts
5. Providing the input for the testing team, in the validation and verification process
6. The first stage of requirements definition forms the basis for the project’s effort estimation
7. Good software management decompose the problems into component parts which are easy to understand, trace and cover by other ALM artifacts
The lifecycle of requirement definition process
Requirement first revision
“User shall be able to pay in several payment terms”
The revised requirement
“System will have a payment form, and user shall be able to enter this form and select a specific payment term”
This requirement can be broken down to several sub requirements, so we will use hierarchy to manage this set of requirements:
1. HEAD: Payment Module
1.1 REQ-112: Payment form
1.2 HEAD: Payment methods
1.2.1 HEAD: Credit card
1.2.1.1 REQ-114: Pay by Visa
1.2.1.2 REQ-115: Pay by Amex
1.2.2 REQ-116: PayPal
Wednesday, February 4, 2009
Requirements Management - Traceability Matrix
Requirements traceability is about tracing the lifecycle of requirements in all ALM aspects. It can be established using a variety of tools including Application Lifecycle Management (ALM) software, requirements management software, databases, spreadsheets, in-house tools or even with tables or hyperlinks in a word processor.
A requirements management traceability matrix is created by associating requirements with the other ALM artifacts that satisfy them, while the relationship of driver to satisfier can be one-to-one, one-to-many, many-to-one, or many-to-many.
Following relationships form the traceability matrix:
A requirements management traceability matrix is created by associating requirements with the other ALM artifacts that satisfy them, while the relationship of driver to satisfier can be one-to-one, one-to-many, many-to-one, or many-to-many.
Following relationships form the traceability matrix:
- High level and low level requirements
- Traceability from marketing department to R&D
- Risk management – relate requirements to risks
- ALM artifact such as code, test cases, test results, defects, tasks, detailed design
The following image illustrates the different relationships valid for requirements traceability:
- Traceability from marketing department to R&D
- Risk management – relate requirements to risks
- ALM artifact such as code, test cases, test results, defects, tasks, detailed design
The following image illustrates the different relationships valid for requirements traceability:
Sunday, February 1, 2009
What is Application Lifecycle Management (ALM)
Application lifecycle management becomes more and more crucial to project success as software becomes a major part of our lives. As offshore becomes an integral part in high-tech companies, each software development company must have a full visibility and control on the development process, in terms of quality, budget, and time to market. Furthermore, there is an increasing demand for compliance mandates by customers and the on going changes require an efficient change management.
According to Forester, Application Lifecycle Management, ALM, is “the coordination of development life-cycle activities, including requirements, modeling, development, build, and testing, through: 1) enforcement of processes that span these activities; 2) management of relationships between development artifacts used or produced by these activities; and 3) reporting on progress of the development effort as a whole”
So, there are 3 main pillars combining an ALM solution:
· Traceability of relationships between artifacts in ALM
· Automation of high-level processes in Application Lifecycle Management
· Analytics to provide visibility into the progress of development efforts in ALM
ALM 1.0 is talking about a single tool for each role; Application life-cycle management tools feature an impressive amount of redundant and usually inconsistent functionality in areas like workflow, collaboration, reporting and analytics; Repository synchronization is the primary means for integrating application lifecycle tools today - even when the tools concerned are all from the same vendor, but it is often difficult to establish, costly to maintain, or flat-out unworkable; Effort spent building and maintaining synchronizations leads to No single source of truth, and leads to overspending on ALM licensing.
ALM 2.0 talks about a single platform for the coordination and management of development activities, and not a collection of life-cycle tools with limited ALM features.
The advantages of ALM 2.0 over ALM 1.0 include:
One integrated system to manage all ALM artifacts
Product packaging - provide end users with simpler, cheaper tools, as one ALM platform provides a set of natively integrated tools.
Use of open integration standards - use of Web services APIs to ease and deepen integration between ALM tools with already existing legacy systems or single ALM tools.
Subscribe to:
Posts (Atom)
Posts
