SDLC Development

Get *ALL* 100+ Editable Word, Visio, HTML & Project Source Documents (500+ Files) Totaling 1000+ Printed Pages for Only $497 - Buy I.T. Now!

SDLC

*DOWNLOAD NOW $497

SOP 1200: Development

Objective:

The objective of this Standard Operating Procedure (SOP) is to document the design and implementation of projects.

Scope:

This SOP focuses on activities performed during the design of technical design, implementation and testing of project deliverables after project detail design is complete. The goal of development is to produce a deliverable as close to production-quality as possible.

Owner:

Development

Sections:

i	Definitions
1	Process Flow Diagrams
2	Roles and Responsibilities
3	Metrics
4	Procedure Activities
5	Forms
6	Exceptions
7	Tools/Software/Technology Used
8	Attachments

Related Standard Operating Procedures:

1000	Program/Project Management
1005	Release Planning
1040	Requirements Definition
1041	Detail Design

Get "IT"
ScalabilITy - ReliabilITy
FlexibilITy - AgilITy
LongevITy - QualITy
.doc .xls .ppt .mpp .vsd .htm EdITable; Policies, Processes, Procedures, Projects Tasks, Diagrams, Forms & Files.
DOWNLOAD
Satisfaction Guaranteed.

-->

SDLC Standard Operating Procedures:

SDLC Framework:

SDLC Gates:

SDLC Roles and Responsibilities:

SDLC Forms:

SDLC Templates:

SOP 1200 - Development Definitions

Term	Definition/Description
*Program/Project Management* .	The systematic execution of a System Development Life Cycle (SDLC) for a release or projects that have significant impact on an organization’s service delivery. This procedure oversees the SDLC execution; thus, it relies heavily on defined procedure activities and acceptance criteria for inputs and outputs Note: Every unit within SDLC interacts with Program/Project Management. Every release of new and enhanced features and functionality requires the commitment and effort from all departments.
*Project Manager*	The focal point throughout a project who ensures that the responsible party has completed with quality and comply with defined acceptance criteria. The *Project Manager* also acts as the conduit for communicating the progress of the project and decisions made throughout the process to the *Project Sponsor, Contracting Organization, and the Performing Organization*.
*Program Management*	Addresses oversight for a group of projects. *Program Managers* shoulder the responsible for the successful completion of program objectives by supporting and developing project staff. Reporting at this level provides *Executive Management* with the information necessary to make informed decisions and execute actions that optimize benefits to the organization.
*Program Manager*	The tactical manager who facilitates, monitors and communicates the progress and issues in implementing the strategic objectives of an approved program. The *Program Manager* works cross-functionally to develop the blueprint that integrates multiple release deliverables that enhance the program’s portfolio.
*PMO*	The *PMO* is the organization that consolidates all project plans and reports the status to executive management. Impacts from individual projects can be seen from an organizational perspective and responded to rapidly. The *PMO* is where project and program standards, procedures, policies and reporting are established.
*Business Gate*	defined milestone in a project lifecycle when specific requirements must be met in order to make or validate business decisions relating to the project.
*Lock-Down*	The milestone in a project schedule achieved when agreement exists between the Performing Organizations and the Contracting Organizations for the delivery of a defined project scope of work within a defined schedule at a defined cost.
*Management Phase Review*	An event associated with selected business gates where specific decisions concerning the project are made by appropriate levels of management. Deviations in deliverables or timeframe are handled by convening the Gate 6 Review Board. This group will make any decisions concerning scope, cost, and schedule tradeoffs. These business gates are: G-11: Project Strategy Lock-Down G-10: Requirements Scope Lock-Down G-6: Project Lock-Down G-4: Begin Validation G-2: Begin FOA G-0: General Availability
SDLC Business Gates	The foundation is Program/Project Management in the SDLC Business Gates. This Systems Development Life Cycle (SDLC) begins at project initiation and moves through deployment to the production environment.
*Phase*	A collection of logically related project activities, usually culminating in the completion of a major deliverable. The conclusion of a project phase is generally marked by a review of both key deliverables and project performance in order to determine if the project should continue into its next phase as defined or with modifications or be terminated and to detect and correct errors cost effectively.
*Program*	A defined set of projects containing common dependencies, and/or resources and/or objectives overseen by a Program Manager
*Project*	A temporary endeavour undertaken to create a unique product or service. A project has a defined scope of work (unique product or service), a time constraint within which the project objectives must be completed (temporary) and a cost constraint. In the context of SDLC, a project may be one of: an individual feature a collection of features making a release a collection of product releases making up a portfolio a new product development
*System Development Life Cycle (SDLC)*	A predictable series of phases through which a new information system progresses from conception to implementation. All of the activities involved with creating and operating an information system, from the planning phase and/or the initial concept to the point at which the system is installed in a production environment. The major phases are Release Planning, Definition (Requirements and Specifications), Development, Test (Validation), and Deployment.
*Scope of Work*	The Scope of Work (SOW) contains a listing of all internal and external needs for the project. This user requirements specified in this list define the goals for the project.
*First Office Application*	The First Office Application (FOA) is the first installation and use of the product/project at one or more designated user/client sites.
*Training Needs Form*	This document outlines all of the functionality that will require training within a product/project release, who will provide training, who needs to receive training and whether or not there will be an FOA rollout training and controlled rollout training.
*Internet Service Provider*	The Internet Service Provider for SDLC provides access to the internet including hardware and software required to establish, maintain and monitor connectivity.

1. Process Flow Diagrams

Development Overview

Click Image to Enlarge

2. Roles and Responsibilities

Role	*Responsibility*
Development Team Leaders	*Development Team Leaders* are experienced and knowledgeable individuals responsible for a group of *Developers* and lead the development and delivery of code underlying release features and functionality. Each *Development Team Leader* has a broad knowledge of all software infrastructure tools used at SDLC, the SDLC web site and mastery in at least one of the following areas: active server pages (ASP), Java or database.
*Developers*	*Developers* are a group of software engineers, at various levels of proficiency and knowledge of the SDLC site, under the supervision of a *Development Team Leader*. They generate and pre-QA tests the code.
*Engineering Department*	The Engineering Department consists of *Development* (Sustaining, Advanced and Strategic), *Quality Assurance, Operations* (OCC, Release Engineering, Database Administration, Network, Unix, and Operations Engineering), *Systems Engineering* and *Program Management*.
*Product Design Group*	The *Product Design Group* is the client-facing area in product that prototypes and mock-ups client specifications, reaches consensus with clients on requirements, and insures that requirements are delivered as defined in the Scope of Work document.
*Program Manager*	The *Program Manager* is the point individual in the *Engineering Department* who oversees one or more releases from inception through delivery of the solution by the *Engineering Department*.
*Project Manager*	The *Project Manager* is the point individual in the *Product Department* who oversees one or more releases from inception through delivery into production.
*Project Sponsor*	The *Project Sponsor* is assigned by *Senior Management* during the concept phase and is responsible for all project start-up activities. The *Project Sponsor* must be a member of *Senior Management, as this person needs to get backing, commitment and support from top-level management. The Project Sponsor* develops a release strategy (project strategy) which includes a timeline, research and development budget, affordability percentage, service requests to be included, and any additional anchor objectives. The *Project Sponsor* is empowered by *Senior Management* to arbitrate amongst projects for resources, commit the organization to specific deliverables and timeframes, and facilitate resolution of obstacles to the successful completion of a release.
*Senior Management*	*Senior Management* is the executive management team at SDLC. They establish business strategy and commission projects.

3. Metrics

Metrics covers from Technical Design through Development. Defect tracking metrics against Development efforts is addressed in the Quality Function Procedure..

Metric Description

Technical Design Reviews

The number of times a technical design specification is reviewed by QA before acceptance.

Smoke and Integration Test Defects

The number of smoke and integration test defects fixed prior to code reaching quality level and readiness for QA testing. Defects will be recorded by Developer and reported by Development Team Leader.

QA Smoke and Integration Test Defects

The number of defects reported at QA’s smoke and integration test prior to QA acceptance. Defects will be recorded by Developer and reported by QA.

4. Procedure Activities

Throughout the technical design and interface specification, and software development activities interactions with areas outside Engineering Department will be funnelled through the Program Manager. The Program Manager will capture the issue, constraint or opportunity raised by the Developers to their Development Team Leaders. These open items are captured and tracked in the project Issue Log (Program/Project Management Procedure – SOP 1000). Based on recommendations from the Development Team Leaders and/or management the issues will be handled either through a request for a meeting or through the Program Manager communicating with the Project Manager.

*Gate/Activity*	*Description*
*Click Image to Enlarge*
*Project Manager*	The program manager escalates issues as follows: Loss of functionality or change in scope: The project manager contacts the Project Sponsor/Senior Management. MIS Tracking, Performance, navigation and scalability: The project manager contacts the Product Design Group.
*Development Team Leader(s)*	Technical design commences with the kick-off meeting where the System Requirement Specifications (Business Requirements Procedure) are vetted and work assignments determined. The high-level requirements, database tables and infrastructure build-out concerns are discussed. The *Program Manager* captures the assignments in an Excel spreadsheet, broken out by activity, is used to create the detailed in Project Plan.
*Development Team Leader(s)*	Technical Design within each of the development areas has a common approach, but with some differences. Interface technical design is accomplished through focused discussions between the *Development Team Leader* and the *Developer. The Developer’s experience level, knowledge of client requirements and the novelty of the feature or functionality to be developed determine the depth of the dialog necessary. Database Development Team Leader* develops the logical and physical model design in teams meetings using a whiteboard. Finalized designs are implemented through changes to the database. Major changes to the database are developed and distributed to *Development, Operations, Quality Assurance* and *MIS. MIS* is updated per Build.
*Development Team Leader(s)*	Technical Design is documented in each of the development areas using both system and manual documentation. Manual documentation for all areas follows the Technical Design Template form (Appendix A). The level of detail capture on the form is directly proportional to the novelty of the coding requirement and at a level necessary for troubleshooting. Technical Design documents are maintained in the *Program Management* assigned Project Library and in the VOB prior to the code validation by QA.
*Quality Assurance*	Technical Designs are quality reviewed by QA. Each document is maintained by the *Developer* through acceptance by QA, which is required prior to code moving to the QA environment.
*Developer(s)*	Technical Design for feeds is defined via contractual agreement. The *Developer* is responsible of completing the appropriate form (Appendix B and C) and delivering it to *Quality Assurance* with code turnover. In addition, the *Developer* is responsible for coordinating feed related operational issues with the *Operations Manager* and the *OCC. Documentation standards used for technical design and coding are divided into categories: Feeds have well defined standards. Feeds are more commonly assigned to contract/consultant staff and are well-defined requirements contained in the corresponding contract. ASP uses both Developer* comments located in each file and VOB self-documentation. Database procedures are documented by the Developer. Logic is handled in Methods and Classes via the VOB. API interfaces with Customers and Site Resources are documented in the code via comments. Tools are generally developed for a specific feature. These are documented through the Scope of Work document (Release Planning Procedure). Technical Design documents are used downstream in the SDLC by *QA,* *Operations* and *IT.*
*Developer(s)*	Development process begins with the implementation of the Technical Design by the *Developer* assigned. The division of coding responsibilities is: ASP – features and elements Logic – DLLs, scripts and feeds Database – tables and stored procedures *Developers* design and create source code following SDLC coding standards/guidelines provided by the *Development Team Leader. This work is completed on the Developers* computer.
*Development Team Leader(s)*	Each *Development Team Leader* conducts a code review for each release. Generally speaking, a walk-through is done to review any completed significant work product. The objectives of a walk-through include the following: Formally walk through work products to identify errors, omissions, ambiguities, and/or misunderstandings that may cause problems at a later stage of the project. Walk through different aspects of a project with constituents and/or senior management. Use the walk-through technique as an education/explanation medium to ensure that all members of a team or all participants in a portion of a project have a clear understanding of the purpose of the tasks to be completed and their respective roles and responsibilities. Ensure that the work products meet quality standards.
*Development Team* *(Recording Secretary)*	Although individual walk-throughs may be organized somewhat differently, the following procedures and guidelines are generally used: Establish who will be the coordinator and the role they will play. Define who the presenters will be. They should be the producers of the work products to be discussed. Limit attendance to members of the project team able to make the best contribution. Give participants (reviewers) are the review materials before the walk-throughs and set an expectation to be familiar with them. Emphasize error detection rather than error correction. Designate one person to act as a recording secretary. Schedule a predetermined time period (normally two to three hours). If the objectives have not been met in that time, another meeting should be scheduled. The persons developing the work product are responsible for the presentation of the material. The entire review team is responsible for the final product that is delivered because it is the review team's responsibility to detect the error. The recording secretary documents the detected problems and errors. The person whose work is being reviewed must formally respond to the documented problems.
*Developer*	Once the code is generated the *Developer* builds code creating executables and stores features in the VOB. Approved Technical Design documentation is stored in the designated public project folder if this has not been done. Unit testing is performed on this code to ensure it is defect free and in full compliance to the Technical Design. The *Developer* corrects identified errors, and then build and testing are repeated until acceptable results are achieved.
*Developer and Development Team Leader*	The code that passes *Developer* smoke tests and *Development Team Leader* review is merged into the VOB branch in development environment for the appropriate release. This build is the image of the code that will move to production (less emergency pushes and downstream bug fixes). Once the VOB is built, the *Developer* smoke and integration tests the code to ensure that: *Developer’s code works in the integration environment All system specification requirements are me Aggregated source code is functional in the integration environment. Developer* unit and smoke tests include the tests defined on the *Technical Design. The responsible Developer* corrects identified errors, and then build and testing are repeated until acceptable results are achieved.
*Quality Assurance*	QA reviews all quality approved Technical Design documents. QA and *Development* resources meet and review the testing and critical points that will impact the site. At the completion of this meeting QA will perform a series of integration tests in the development environment after which QA will accept or reject the turnover. Accepted release code is authorized to move to the QA test environment.
*Quality Assurance and Development Manager*	Acceptance criteria for the QA smoke test are established and agreed to by QA and *Development Manager*.
*Click Image to Enlarge*
*Technical Writer*	Technical Writer creation of preliminary documentation for *Technical Support’s* training requirements (Training and Documentation Procedure SOP – 1101)
*Quality Assurance*	QA development of integration test cases based on Technical Design documents (Quality Function Procedure SOP 1210)
*Post Development*
*Quality Assurance*	Bug/Defect identification by area performing acceptance testing Bug criticality determined by QA Bug entered into SQA Manager by QA with “Open” status
*Developer*	*Developer* looks up reported bugs and fixes them based on priority *Developer* performs build, unit, integration and smoke testing *Developer* reports the bug is fixed and verified
*Quality Assurance*	QA updates SQA Manager to “Resolved” status QA verifies then authorized the source code to be move to QA for further testing.QA updates SQA Manager to “Closed” status
*Technical Writer*	Concurrent to testing activities are the review and testing of training documentation. Error or improvements identified during the post-development testing phases are cycled to the Technical Writer for inclusion. This is more fully addressed in the Training and Documentation Procedure (SOP 1101).

5. Forms

Form Description

Technical Design Template

See Appendix A

New Fee Release Information Template

See Appendix B

Feed Modification Form Templates

See Appendix C