Date post: | 27-Dec-2015 |
Category: |
Documents |
Upload: | clemence-preston |
View: | 214 times |
Download: | 0 times |
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