Service   |  Products   |  Resources   |  Careers   |  Company   |  
  Overview   |  Software Development   |  DDF   |  Infastructure Management   |  Consulting Services  |  Delivery Models  |




Service > Software Development >

Tailoring Guidelines

Experience has shown that SDLC-Model needs to be customized as per the project requirements i.e. size and complexity.



 Process  Element  Process Element  Example  Changes  Alternatives  Considerations

SDLC Model

-Waterfall
-Reverse  Engineering
-Porting
-Bug Fixing
-Architectural re- engineering
-RAD
-Verification

Phase Merger

Phase exclusion

Testing phases can be merged as per requirements

HLD phase can be skipped

LLD phase can be skipped

Size of the project is small

Number of integral modules is less than 3

HLD phase can be skipped

LLD phase can be skipped
     

Partial SDLC model can be followed e.g. only requirement analysis & design or only coding & testing etc.

Project requirements should clearly state that a partial model is to be followed




 Process  Element  Process Element  Example  Changes  Alternatives  Considerations

Entry Criteria

-RFP
-Project Proposal
-Baseline SRD
-Baseline HLD
-Baseline LLD
-Baseline Code
-Baseline Test  Plans/ Test Data

Formality

Project specific inputs

All inputs other than the customer supplied information (hardware, software and documents) should have been base lined and should have been managed and controlled

Customer supplied inputs should have been controlled

The entry criteria for requirement analysis phase can be minutes of meeting with the customer or any other form of customer communication

Any project specific input or entry criteria should be defined in the project plan
  
   

Some form of document stating the customer requirements should exist as input to requirement ;analysis phase

The need for the project specific input should be traceable to the requirements





 Process  Element  Process Element  Example  Changes  Alternatives  Considerations

Phases

-Requirement

 analysis
-High level design
-Low Level Design
-Coding
-Unit testing
-Integration testing
-Acceptance testing

Phase overlap

Tasks

Tasks can overlap or can be done in parallel

Any project specific tasks in a phase should be clearly specified

The completion of a task in a phase can extend to the next phase

The need of task overlap should be clearly specified. The changes in ETVX criteria of the tasks due to overlap should be clearly mentioned.

Need for the phase specific tasks should be traceable to

project requirements

This should be indicated in project specific process




 Process  Element  Process Element  Example  Changes  Alternatives  Considerations

Validation


Exit Criteria

-Reviews

-Code Walkthrough

Approval

 

Formality

Formality



Authority

Reviews can be formal or informal

Code walkthrough needs to be formal

Approvals can be through sign-off or e-mails

Approving authority for each Customer Interface should be clearly specified in the project plan. As per requirements customer can be the approval authority

Mode of review as required should be specified in the project plan

Signed-off hardcopies and approval e-mails should be controlled and easily traceable

For project management documents like SRD, Project plan etc, Program Manager is the suggested authority.

For reviews, reports, test logs etc approval authority can be project specific.

 




 Process  Element  Process Element  Example  Changes  Alternatives  Considerations

Roles

-Customer
-Reviewer
-Approver
-Designer
-Coder
-Tester
-Auditor
-Quality Manager

Responsibility

-Reviewer(s) for each Interface should be clearly specified in project plan.

-Requirement for external reviewer(s) or customer reviews should be clearly specified.

Specified quality auditor should do startup, closure and phase end audits.

Design, coding and testing responsibilities within the team should be identified.

The Configuration manager for the project should be identified in the project plan

- For project management documents like SRD, Project plan etc Program Manager is the suggested reviewer.

- Quality Manager/Auditor should also review the project plan.

- For design documents, code, test plans etc, Project Manager and specified team members are the suggested reviewers.

- Any need for external reviewer should be specified.

- For reports, test logs etc reviewer can be project specific.

The auditing authority for each audit item should be clearly specified.

It is suggested that the responsibility of test planning and testing at integration /acceptance stage should not be the coder

 




 Process  Element  Process Element  Example  Changes  Alternatives  Considerations

Input / Output / work products

-Document
-Code
-Report
-Logs

Formality

Document Scope

All input/output/work products should be under Configuration Manager.

Scope of document should be specified as standard, suggested etc.

The Configuration Manager level should be specified for each item as managed & controlled or managed.






Service l Products l Resources l Career l Company l
Copyright © 2006 Softbrains Infotech Limited