Software Development Life Cycle (SDLC) Phase 2.0 Introduction Continuing to Build KAG’s NextGen IT 2017

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

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

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.

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 . . . Taking a step back, a software development lifecycle describes the process for planning, creating, testing, and deploying an information system. The system or application may be for hardware, software or a combination of both. 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!

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.

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. Continuous Improvement

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? Types of Estimates: ROM – Rough Order of Magnitude: Also aka TOP DOWN Estimate, Ballpark Estimate. Estimate done during Concept Phase. Provides decision-makers with the information necessary to whether it makes sense to move forward with the project based on the estimated level of effort in terms of completion and/or cost. Range: -50% to +100% Budgetary: Estimate done during Requirements Phase. Gives a more accurate estimate compared to ROM and has Tasks broken down from the SDLC phase. Range: -10% to +25% Definitive Estimate: Estimate done during Design Phase. Broken down even further compared to Budgetary, keeps track of recurring items and detailed plan of the project. Use Project Planning in Workfront. Range: -5% to +10% How do these help us write better software? Better appreciation of how much the team can accomplish in a set amount of time Most realistic amount of effort with uncertain inputs Budget Analysis/Approval – Go or no go? Self Evaluation and Improvement What if I’m really bad at estimating or have never done it? There are few things to consider: It’s impossible to give 100% precise estimate, it is Part of the Planning process It’s okay to be wrong, you will be better with making estimates. – Ex [click]Make assumptions explicit on the Estimate [click] If available, use previous similar projects as a base – [click]Can lead to trap with unfamiliar technologies No overconfidence, okay? Ever! Complexity and Size of the Project Task Quality – Experience/Less Resource? When troubled, ask yourself if the task is broken down properly. Where can I find the template and examples? Provide Locations Do a Demo.

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.

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.

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. https://sps.thekag.com/it/isolutions/_layouts/15/start.aspx#/StandardsWiki 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.

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.

Requirements 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.

Integration Test Plans Where to find the template? When do I create the Integration Testing Plan? What is my role in its creation/consumption? Who reviews the integration testing plan? What is Integration Testing An integration test plan is a collection of integration tests that focus on functionality and testing the individual software modules interaction with the database to encompass the entire solution. The Integration test plan allows the technical team to think through the logical sequence of integration activities, so that their individual detailed development plans are well synchronized and integration happens in a reasonable manner. Simulated usage of shared data areas and inter-process communication is tested and individual subsystems are exercised through their input interface via the use of either Backbone Integration or Client/Server Integration testing. Making note that any conditions not stated in specified integration tests, outside of the confirmation of the execution of design items, will generally not be tested.