|
Software Development Life Cycle (SDLC)
A template of how great products are developed carefully and
methodically
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: June 20, 2004
Requirements/Features Gathering
All requirements captured will have clearly stated source (customer
contact name, title, and phone number), description, business case, and
detailed specifications (if any).
-
Requirements gathered from existing customers
at minimum twice a year and when opportunity presents (source Product
Managers)
-
Market drivers defined by competitive
analysis (source Marketing)
-
Requirements from bugs found in existing
product releases (source Operations)
-
Other requirements gathered (source
developers and company architect)
Product: Requirements to be presented to the
development design team will be prioritized by requested timelines and
revenue opportunity.
Responsible Party: Product Manager(s),
Operations, Marketing
Design Team Review
Design team will review requirements as
presented above and determine what if anything must be done to individual
products to support these requirements. The design team prioritizes the
development of features and
 may elect to table certain feature requests
based on complexity, chosen product/company direction, financial,
reusability of the feature for other existing or potential customers. The
design team will also formalize and expand these requirements in terms of
how they should be implemented within products they are destined. Finally
the design team will also determine which developer to provide the final
specifications to in preparations for ongoing development cycle deliverables
and actual coding.
Design team will “initially” consist of the
following members
-
Engineering Manager
-
Senior Product Architect
-
Development Team Lead
Product: Detailed development specifications
provided to specified developer
Responsible Party: Design Team
Design Document Creation
Selected developer will receive a listing of
detailed development specifications from the design team and be
 responsible
to formulate and write a design document that captures the essence of the
requested development. If the requested new development is part of an
existing product, it will be added to the most recent design document with
change tracking turned on. All design documents will begin using the
approved format available from the Release Engineering Manager. The design
team will be available as resources during this process. Also, developer
should have draft reviewed by at least 1 or 2 developers.
Product: “Draft” Design Document
Responsible Party: Developer
Design Document Review
Design document created by developer will be presented to design team and
representatives of QA for a detailed review. Developer will be asked to
explain the overall goal his/her design, review the changes to the code in
detail, and field questions regarding the impact of the changes on the
product as well as the compatibility with previous releases.
Product: Changes (if any) to Design Document
Responsible Party: Developer
Attendees: Developer(s), QA, Documentation and
Design Team
Change Design Document
Any changes to the design document that result
from the Design Document Review will be made and this document and than
submitted to release engineering.
LIVING DESIGN DOCUMENT – upon completion of
changes, the design document will remain a living document receiving regular
updates as development proceeds and reflect any changes to the design as
required by the developer or dictated by other limitations.
Product: Final Approved Design Document
Responsible Party: Developer
Propose Timeline
Developer will analyze the scope of work
defined by the design specifications and the design document to come up with
a proposed timeline to complete all coding and developer testing for desired
functionality or product.
Development timelines of more than 2 weeks will
be broken down into at least two phases (however, ideally phases will be in
two week intervals). At the end of each phase there will be something to
visibly demonstrate or show to a design team member.
Product: Proposed timeline for development
Responsible Party: Developer
Negotiate Timeline - Development related
Proposed timelines will be submitted to the
design team for review. The review will consist of one or more of the design
team members discussing the proposed timelines with the developer to
understand his/her reasoning for various portions of the timeline. If any
timelines are deemed excessive, a compromise will be negotiated between the
developer and the design team. The result of this review will be an approved
timeline for development. At the completion of the approved timeline the
product will be deemed ready for quality assurance testing.
Product: Approved Development Timeline
Responsible Party: Developer, Design Team
Development Commences
Development begins on the product or requested
features following the phased timeline provided. Various design team members
will check on the progress of the development per the approved timeline
phases as well as be a resource to answer questions regarding design
decisions not covered within the preliminary design documentation stage.
Developers will be responsible to updating
changes in the design documentation during development. Spot checks on these
documentation updates will be made during demonstrations at various phases.
Developers are must to have all documentation updates made before providing
demonstrations at the completion of each phase in the development per the
timeline.
Product: Developed product ready for qualify
assurance testing
Responsible Party: Developer, Design Team
Confirmed Plan – Project Schedule
A confirmed plan will trigger a project
planning exercise where development, QA, and projected release dates are
scheduled out. These dates will remain firm unless impacted by unknown
development issues or rescheduling performed by the design team.
Project plans will be available for operations
and management to view. Development and QA resources will be listed on
higher level charts to show utilization. In addition, a high level
development and QA chart will show available gaps in the QA and development
cycles.
Product: Project plan
Responsible Party: Design Team, QA
QA Lead Announced
The Quality Assurance Manager will assign a QA
Lead for the specific project. The QA Lead will be responsible for updated
the necessary parties in regard to the project at hand. Also, the QA Lead
will guide the project throughout the entire Software Development Life Cycle
(SDLC).
Product: QA Lead assigned
Responsible Party: QA Manager
Review of Design Document
The QA Lead will be responsible for reviewing
the design document created by the lead developer. At this phase, both QA
and development will work as a team to assist QA in better understanding the
current project, as well as, making the testing process as smooth as
possible. Once the QA Lead has a firm understanding of how the project
functions, he/she will be responsible for filtering all valued information
to his/her colleagues. Also, the testing environment can be determined at
this step.
Product: Design Review
Responsible Party: QA Lead, Lead Developer
Test Plan/Test Matrix
After the design document is reviewed and
understood, the QA Lead will create the master Test Plan and Test Matrix
(test cases) in accordance to the design document. After completion of the
Test Plan and Test Matrix the master documents will be submitted to the lead
developer for review. It is the QA Lead and lead developer’s best interest
to review the documents in full and determine that all test cases and test
environments are defined.
Product: Test Plan/Test Matrix Created
Responsible Party: QA Lead, Lead Developer
Submit Test Plan/Test Matrix to Management
After thoroughly reviewing the documents, the
QA Lead is responsible for submitting both documents to management for
approval. Management will have final say for approving both documents.
Product: Test Plan/Test Matrix submitted
Responsible Party: QA Lead
Unit Test Results from Development
Once all documents are approved, the lead
developer will provide the QA Lead with all necessary Unit Testing results.
The QA Lead will approve of the Unit Test results. If the results are
declined the lead developer will need to make the necessary revisions in
order for the product to be accepted into the QA testing phases.
Product: Unit Test Results
Responsible Party: QA Lead, Lead Developer
QA Testing Phases
QA Testing phases will begin once the design
document, test plan and test matrixes have been approved. QA will then
perform the following testing procedures:
- Functional Testing
- Regression Testing
- Performance Testing
- Load Testing
- Manual Testing
- Exploratory Testing
Also, all test results will be submitted to
management for review. The test results must include the following:
- Location of the files tested
- Screenshots of all errors
- Steps to Reproduce
- Testing environment – Operating Systems, Memory, CPU etc.
- All bugs will be logged into the software release management database.
Product: QA Testing Phases Begin
Responsible Party: QA Staff
Open Issues
The Management Team, QA Lead, Lead Developer
and Product Manager (if necessary) will review all open issues that remain
with the current product. This team will determine if the issues can be
addressed in the Next Release, addressed in this version or is a Potential
Revision for the future.
Product: Open Items reviewed
Responsible Party: QA Lead, Lead Developer,
Management Team, Product Manager (if necessary)
Retrospective Meeting
During this meeting the QA staff and QA Manager
will review the entire testing process. The review will enable us to address
any issues that we may have encountered during our testing phases. The
primary goal of this meeting is to learn from our mistakes and make our
entire process work as smooth as ever.
Product: Meeting
Responsible Party: QA Staff, QA Manager
Feedback:
Afzal Mohammed:
Friday, December 26, 2008 12:51 AM
I have a concern related to the Test Plan generation activity.
Here in our organization, we need to map every software engineering activity to the respective SDLC as described below.
Requirements Gathering activity would be mapped to Requirements Phase of SDLC.
Similarly “Design Document” shall be mapped to the Design phase of SDLC.
As we all know in V-Model, we would generate the Test Plan during the design phase. The concern is that, whether to map Test Plan generation activity to the Design Phase or to the Testing Phase.
It would be of great help if you can give clarification on this.
Author's Repsonse:
You pose a good question.
In my experience, the design document provides a good “guide” for how development “should” happen and as such some aspects of the test plan could be “planned”. However, like any software development activity, it is not all an exact science and not all projects turn out how they are designed. As such, a bulk of the test plan “should” come after the design document as milestones of the development are reached and as the dust settles on how the overall software is coming together.
I personally like the idea of software developers contributing unit test code as well as some aspects of unit test methods to the evolving test plan. In this way, QA has a guide as to what specifically has been tested leaving them with a much easier task of determining where the delta lies. It is also a time saver as some of the baseline code from unit tests can speed follow on test automation.
Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white
papers hot off
the presses by adding our RSS feed to your reader.
|
|