Software Development Life Cycle Procedure (ITR011)
Software Development Life Cycle Procedure (ITR011)
Software Development Life Cycle Procedure (ITR011)
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Software</strong> <strong>Development</strong> <strong>Life</strong> <strong>Cycle</strong> <strong>Procedure</strong> (<strong>ITR011</strong>)<br />
Information Technology Services Department<br />
Issuing date:<br />
Overview<br />
The purpose of this procedure is to establish a standard for software development and life cycle for applications developed<br />
by the Technology Services Department.<br />
Areas of responsibility<br />
This policy applies to Programmer Analysts, the Systems Support Supervisor, and Systems Analysts who develop<br />
applications or interfaces.<br />
<strong>Procedure</strong> details<br />
Initiation Phase<br />
1. Identify Stakeholders and affected departments<br />
2. Identify business need<br />
a. Example: Track Census data in computerized database, provide record search, reporting, web interface<br />
3. Review existing method or solution<br />
a. Can existing method be updated (vendor)<br />
b. Can interface to existing method be developed<br />
c. Does existing method need dismantled<br />
i. Why Legal reasons, security access reasons, etc<br />
d. Identify missing usability options or features<br />
e. Scope of user base<br />
i. District wide (lends towards a web application) or local to one or two users<br />
ii. Portability<br />
Feasibility Phase<br />
1. Can existing methods be updated to overcome real/perceived shortcomings<br />
2. Vendor input<br />
a. Costs to bring existing methods up to date (monetary, training, downtime)<br />
3. Estimated development time if built in-house, based on similar projects<br />
Requirements Analysis Phase<br />
1. Data analysis<br />
a. What kind of data will be tracked<br />
b. Source of data (resident forms, vendor submissions, batched data)<br />
c. Suggested database (Access, MSSQL, Excel)<br />
d. Backup policy<br />
2. User Interface analysis<br />
a. Identify users<br />
b. Method of data input<br />
i. Web / form / spreadsheet<br />
Error! Reference source not found. Page 1 of 3 Revised Date:
<strong>Software</strong> <strong>Development</strong> <strong>Life</strong> <strong>Cycle</strong> <strong>Procedure</strong> (<strong>ITR011</strong>)<br />
Information Technology Services Department<br />
Issuing date:<br />
Design Phase<br />
ii. Internal / External<br />
c. Hardware/<strong>Software</strong> requirements<br />
i. Web browser / barcode scanner / Operating System<br />
d. Identify desired data entry / transaction benchmarks<br />
1. Security / Data Liability<br />
a. Security level required for transactions and data storage (data sensitivity, exposure inside/outside of<br />
network, user authentication method)<br />
b. Liability evaluation (for example, purchases/credit card information submitted though application require<br />
a higher level of transaction security than entering demographic data on a district workstation)<br />
2. Identify Data to be tracked<br />
a. Data fields / data types (integers, decimals, strings)<br />
b. Key fields (will keys be visible to end user, will they ever need updated)<br />
c. Data attributes (data about data)<br />
i. Example: Automobile > Color. Can the automobile have one color, or several<br />
d. Data rules (must the automobile have a color or can color be null)<br />
e. Data Relationships<br />
f. Identify Year-Specific tracking / functions<br />
g. Identify questionable or uncertain data attributes or objects<br />
i. Think ahead to how users will expect to report on or search for these items<br />
3. Data Entry<br />
a. Validation<br />
b. Ease of Use (interfaces)<br />
c. Level of user security required<br />
i. Example: Admin can read/write all fields; Substitute can read main fields<br />
4. Conversion of existing method and data<br />
a. Can existing data be extracted, or will this be archived and accessed in old system permanently<br />
b. Method of importing extracted data into new application<br />
a. Access to old system cutoff for staff / transition concerns<br />
2. User Interface<br />
a. Prototype (visual mockup)<br />
c. Identify Key work areas (search / maintenance / reporting)<br />
i. UI navigation<br />
Error! Reference source not found. Page 2 of 3 Revised Date:
<strong>Software</strong> <strong>Development</strong> <strong>Life</strong> <strong>Cycle</strong> <strong>Procedure</strong> (<strong>ITR011</strong>)<br />
Information Technology Services Department<br />
Issuing date:<br />
<strong>Development</strong> Phase<br />
1. <strong>Development</strong><br />
a. Security groups / authentication / integration addressed<br />
b. Database design<br />
c. User Interface<br />
d. Test progressive features / interfaces with end users<br />
e. Test validation measures<br />
f. Test ease of use against benchmarks<br />
g. Documentation<br />
Implementation Phase<br />
1. Installation on Live system<br />
2. Training<br />
3. Data Migration<br />
4. Go Live<br />
Operations and Maintenance<br />
1. Data / software backups monitored<br />
2. User feedback<br />
3. Annual <strong>Life</strong>cycle Review<br />
a. Meet with Stakeholders<br />
i. Application still used<br />
ii. Suggested improvements<br />
iii. Retirement of system<br />
1. Live record retention (how long)<br />
2. User access (same / admin only)<br />
3. Data Backup retention (how long)<br />
References<br />
N/A<br />
Help page<br />
N/A<br />
Error! Reference source not found. Page 3 of 3 Revised Date:
Change language