Texas Transportation

Institute

Software Development Life Cycle

Fall 2011

Lightweight SDLC

Prelude

Development team’s purpose and organization’s purpose

Each project typically has a different contract mechanism, and thus different SDLC and IT requirements. Further, work here at the lab is very PI centric, as such each PI has different ways of doing business. The PI’s are very sure of what their needs and are very short on time. That tends to generate differences in each project’s approach.

The following document are our default development guidelines. It is written by and for software practitioners and uses terms particular to the Software Engineering industry.

8/13/008 REV 2008.10 2

Lightweight SDLC

Table of Contents

• Prelude

2• Introduction

4• Product Overview

5• Product Activities & Deliverables

6• Project Overview

7• Project Activities & Deliverables

8• Iteration Activities & Deliverables

9• Feature Overview

10• Feature Activities & Deliverables

11• Release Management

12• SQA

13• Defect Management

14• Maintenance

15• Availability/Capacity/Support

16• Deprecation

17• Retirement – User Side

18• Retirement – SE Group

19• Persisted Information

20• Tools

21• Environments

22• Terms

23• References, External

24• References, Internal

25• Change History

26

8/13/008 REV 2008.10 3

Lightweight SDLC

Introduction

Software development exists as an integral part of the education, service and research mission. Therefore, it is usually a discovery activity, where the “final” level of software functionality is quite subjective and totally unknown at the start of the project.

Activities are defined in terms of:

Product – A named software product

Project – A major expansion of functionality within a Product or a stand alone provision of service (i.e. a database report)

Feature – The implementation of a User “Story” within a Project

8/13/008 REV 2008.10 4

Lightweight SDLC

Product Overview

• Is implemented via Projects and Features• Requires Sr. PI approval and usually has a

separate billing code• Has a named Product Manager and Customer

Team• Should have a dedicated Stakeholder’s Group• Requires its own support mechanisms, file areas,

software repository, defect tracking instance, databases

• Always starts with architectural iterations to deliver the architectural model

• Should have a Product Plan that includes risks, staffing, schedule, Product Vision (vs Project Vision), changes to the SDLC, and references to key resources

8/13/008 REV 2008.10 5

Lightweight SDLC

Product Activities & Deliverables

• Vision & Scope• Mockups & Stories• Iteration Plan• Risk Management• Team Roles & Responsibilities• Stakeholder Interviews (when allowed)• Architectural Design (high level, Visio)• Architectural Exploration (Spikes)• Creation of support and operational infrastructure• One or more Projects are executed for functionality• Create user documentation/FAQ. Update architecture• Establish support team, Web resources• Define data transfer (if any) from prior system• Create training materials, set training schedule

8/13/008 REV 2008.10 6

Lightweight SDLC

Project Overview

• A deliverable* for a Product. Service offerings are handled informally at this time (i.e. database support).

• Has a Vision Document• Has Kick-Off tasks that include

review/updating of the Project Plan, and an Iteration Plan.

• Should have a Stakeholder review/briefing• Should not adversely impact Operations• May require database conversion

8/13/008 REV 2008.10 7

Lightweight SDLC

Project Activities & Deliverables

• Vision & Scope• User Interviews (when allowed)• Mockups & Stories• Iteration Plan for Features• Iterations (implementing

Features)• Stabilization• Operations/Support updates• Release Management

8/13/008 REV 2008.10 8

Lightweight SDLC

Iteration Activities & Deliverables

• Iteration Kickoff• Enumerate Stories• Estimate Stories• Prioritize Stories• Develop Stories– Detailed Design– Develop using TDD– Code Review– CMS Updates when automation tests

pass– QA tests on the CI Server– Update Story Card

• SQA/Customer Acceptance Tests8/13/008 REV 2008.10 9

Lightweight SDLC

Feature Overview

• Implemented within a Project’s Iterations or as a Change Order to an established Product

• Does not impact the architecture nor any of the Operational aspects of a Product

• Requires Beta Testing• Normally rolled out with other

Features as part of a Project Release

8/13/008 REV 2008.10 10

Lightweight SDLC

Feature - Activities & Deliverables

• Estimate Card• Design• Write Unit Tests• Write passing code• Code Review• Check into Configuration

Management• Write Automated Acceptance Tests• Update Card/Change Order• Notify SQA to test (RSS or Build

Notice)

8/13/008 REV 2008.10 11

Lightweight SDLC

Release Management

• 3 digit numbering system: Major:Minor:Build if any change by at least a value of 1, there is a Release

• Major usually corresponds to a Product, and Minor usually corresponds to a Project

• Roll-back is built into the deployment process• Notification is posted on the corresponding Product

page, as well as a Change Log (generated from the Cards/defect tracking) generated as a PDF and linked to the version number of the product

• When a database change is to take place, Users are notified via email and/or screen display

• See Deprecate

8/13/008 REV 2008.10 12

Lightweight SDLC

SQA

• Builds are tested by the SQA Team• The SQA Team works with the

Customer Team to define and execute acceptance tests

• The SQA Team works with the Developers to identify, implement, maintain, and execute automated tests

• The SQA team assists the Developers with documentation, style, and unit tests

8/13/008 REV 2008.10 13

Lightweight SDLC

Defect Management

• Exists as part of SQA, User Acceptance Testing and Support activities

• Uses defect tracking software.• Follows defect reporting process

8/13/008 REV 2008.10 14

Lightweight SDLC

Maintenance/Operations

• Hardware Maintenance– UPS Checks (Quarterly)– Operating Parameters

• Application Maintenance– Usage Statistics (Monthly)– Change Orders (See Features)

• Database Maintenance– Consistency Checks– Backup– Index Tuning– Reporting (Daily/Weekly)

• OS Maintenance– Updates/Patches– Cleaning out temp and backup directories– Monitor

8/13/008 REV 2008.10 15

Lightweight SDLC

Availability/Capacity/ Support

• Information Assurance (IA)– Confidentiality – Information isn’t shared.– Integrity – Information is checked for consistency.– Authentication – People are who they say they

are.– Availability – See Disaster Recovery

• Disaster Recovery– Bi-annual restoration checks– Recovery drills (bi-annual)– Backups– Redundant Hosting and Equipment

• Support– Manuals– FAQ’s– Contact via Phone or Email– Training for Support– Integration of Support into SQA function

8/13/008 REV 2008.10 16

Lightweight SDLC

Deprecationfor Live Projects as of 2011

• Select a URL for the deprecated application that is derived form the operational URL

• Send emails to all users, post forthcoming retirement and transfer information on the Product page

• Update application status line as to the product being retired, date, FAQ update, and provide a point of contact

8/13/008 REV 2008.10 17

Lightweight SDLC

Retirement – User Sidefor Live Projects as of 2011

• Send emails to all users, post forthcoming retirement and transfer information

• Update website as to the product being retired and provide a point of contact

8/13/008 REV 2008.10 18

Lightweight SDLC

Retirement – Developmentfor Live Projects as of 2011

• Do a global recompile• Backup databases, project source and source tree

(optional for history)• Make copy of development tooling master disks and

record s/n of all products• Create re-build document providing directory

organization for building application• Update deployment documentation• Create PDF with documentation of the above tools,

databases, operating systems, tools, build and source tree

• Create ZIP file of the above on a burn point on near online media.

• Burn 3 DVD’s, one for media Safe, one for Development Manager (goes offsite), and one for Development team (onsite), label and date

• Test restore of DVD and ability to recompile, execute QA Note when successful

8/13/008 REV 2008.10 19

Lightweight SDLC

Persisted Information

• Requests for Change/Change Orders • Builds (notice of new features/defects)• Releases (notice of new project

releases)• QA Notes (internal acceptance)• Architectural Diagrams (Design)• Whiteboard Pictures (Design)• Spec Sheets (Design)• Paper Mockups (Design)• Test Plan & Test Scripts• Project Management Artifacts when

required by the contract

8/13/008 REV 2008.10 20

Lightweight SDLC

Possible Tools

• Mantis, Track, Jira (Defect Tracking)• Nunit (Unit Testing)• Framework (Acceptance Tests)• FXCop (Static Code Analysis)• Build Server (CI)• Git, BZR, VSS< SVN (Configuration Management)• Exchange/Public Folders (Logs)• Templates (MS Word)• Selenium• File Structure• Visio• Microsoft SharePoint Server

8/13/008 REV 2008.10 21

Lightweight SDLC

Environments

• Your server, VM and workstation list here

8/13/008 REV 2008.10 22

Lightweight SDLC

Terms

• Acceptance Tests• Beta Testers• Customer Team• Dev – Software Development Team• Product Manager• QI – Quality & Infrastructure Team• SCM – Software Configuration Mgmt• SQA – Software Quality Assurance• Stakeholders• TDD - Test Driven Development

8/13/008 REV 2008.10 23

Lightweight SDLC

References - External

• IEEE Software Engineering Body of Knowledge (SWEBOK)– Testing Section/Terms

• Information Technology Infrastructure Library (ITIL v2)

• User Stories Applied: For Agile Software Development

8/13/008 REV 2008.10 24

Lightweight SDLC

References – Internal*

• Your templates here and their path…

8/13/008 REV 2008.10 25

Lightweight SDLC

Change History

• Sanitized version 2011 from production version dated 2008

• Originally created by Don R. Gilman from materials he owned.

8/13/008 REV 2008.10 26