1. Software Development Life Cycle (SDLC)
Phase 2.0 Introduction
Continuing to Build KAG’s NextGen IT
December 5, 2016

2. Keeping It Light
Keeping the ceremony light.
Improving line of sight from the business idea though solution delivery.

3. What You’ll See Today . . . Review of SDLC Phase 1
Overview of SDLC Phase 2
Where do I fit in Roles & Responsibilities
Where do I find the details later
How much will WorkFront change what I learn today . . .
Where to find the templates
Try it out – hands-on exercises

4. What’s Your Take Away? Understanding the SDLC process.
Creating SDLC documents as required.
Knowing where to find process details and template reference material.
Knowing who to go to for assistance.

5. What’s In It For You . . Benefits of SDLC
Line of sight from the business idea though solution delivery
Expectation management
Time to market
Improved quality
Documentation
Project scheduling
Risk identification & mitigation
Project success
Improved . . .
The SDLC creates a framework that will help you be more successful at the things you like to do best Developing code, data analysis, reporting writing, setting up environments and operating an IT department.
Defining what needs to be done, documenting what needs to be done, planning what needs to be done, developing the solution, testing the solution and finally successfully delivering the solution.
You make things happen NOT documents!

6. Software Development Life Cycle (SDLC)
Is an asset that helps projects get completed successfully.
Referesher on Phase 1
Review the quick links
The KAG SDLC is a consistent peer-reviewed framework for the development & deployment of software solutions.

7. Roles/Responsibilities
Navigating the SDLC
Continuous
Improvement
Software Development Life Cycle
Process
Roles/Responsibilities
Deliverables
Links to One Note – need to have 2.0 version finalized and available to staff by first training class
WorkFront won’t replace or change the SDLC. The Software Development Life Cycle will continue. Your feedback and experience will help us to continually improve the process over time.
Improvement
Continuous

8. Estimates ROM, Budgetary, Definitive – What's the difference?
How do these help us write better software?
What if I’m really bad at estimating or have never done it?
Where can I find the templates and examples?

9. Consuming the BRD & SRS BRD = Business Requirements Document
SRS = Solution Requirements Specifications
What are these documents?
Why do I care about them?
What is my role in their creation/consumption?
What are these documents?
BRD contains the requirements given the BA from the business. These requirements are mostly non technical and outline what the solution should accomplish.
SRS is the linking of Business requirements to more technical system requirements. Examples of what you might see are system interaction diagrams, break downs of business requirements into multiple system requirements, data specific technical requirements.
The BRD and the SRS both answer the What in our SDLC process.
Why do I care?
These will be the specs used when creating the SDD.
You will be involved in the technical side, making sure to bring any possible issues early in the requirements process so that we adjust accordingly.
What is my role in creation/consumption?
Technical lead during creation. You should have a rough idea about how things will work and be able to provide insight wherever possible.
You will consume these documents for writing the SDD, so make sure that everything you need is included in them.

10. Writing the SDD SDD = Solution Design Document
Who is the audience for this document?
What is its purpose?
Tips for writing the SDD…
What if there are changes during development that deviate from the accepted SDD?
Who is the audience?
Developers, Team Leaders, technical people.
Purpose?
Writing out the design based on the BRD and SRS.
Flesh out design ideas and fill in any holes.
Make sure we have an end to end understanding of how the solution will be built and that all needs are met.
Tips
Have the BRD and SRS in front of you when you start writing.
Be as verbose as you feel is necessary.
Don’t have to have every function and model fully mapped out, an architecture diagram and a short description of each is enough in most cases.
Remember that this is just a template, you can add and change sections as you see fit, keeping in mind this will be reviewed anyway.
What if things change in development?
That’s fine, it happens…make sure you are documenting in your code and that you update the SDD based on your changes at some point.
If a larger issue comes up requiring a whole re-architecture of the solution, bring that up to your team leader so a new design can be discussed.

11. Code Standards Where to find the published standards?
How to update the standards?
How will these be enforced?
Where to find them?
Published as a word document and a webpage on SharePoint.
How to update them?
Propose the new standard to your team leader who will send it to the code standards team to discuss at their next meeting.
Enforcement?
Regular code reviews will promote use of the standards.
Deviations will not be allowed unless special circumstances exist.

12. Code Reviews What is a code review?
What is the purpose of a code review?
Who reviews my code?
Will I be penalized for bad reviews?
How do I track defects found during a review?
What is a code review?
Just like it sounds, a peer reviewing your code.
Pre-review checklists will be available as a self check prior to a review.
A checklist for the reviewer will also be provided as a guide during the review process.
What is the purpose?
To promote use of the code standards and cross training on new code.
Who reviews my code?
A peer close to the code that is being developed. This will likely be another developer who may or may not be directly working on the project.
Will I be penalized?
No, but you will have to track the defects found. This is supposed to be a learning experience, both the Dev and the Reviewer have the opportunity to learn something from this exercise.
How do I track defects?
A defects log will be created from an Excel template found on SharePoint.
Includes the type, description, date found, resolution description, resolution date, time spent, etc…
Again this is not for penalizing, but for tracking our progress for estimates, and quality in the SDLC process.

13. Traceability Matrix That sounds complicated, what is it?
What is my role in its creation/consumption?
What is it?
Simply, it maps BRD to SRS to SDD requirements.
It shows us that all of the requirements from the BRD and SRS are accounted for in the SDD.
What is my role?
The BA actually creates this document, but its up to the Developer to make sure that the SDD has all of the information necessary.
The SDD template asks that requirements be attached to components to make creation of the Traceability Matrix easier.