Systems Development Lifecycle (SDLC)
Government and Large Organization SDLC Facilitation Guidance
Systems Development Lifecycle Defined
The Systems Development Lifecycle (SDLC) is a process engineered to ensure the effective creation and development of software. Government agencies utilize SDLC as a framework for development and document the approach. Most SDLC documentation cover a range of topics general to development but also specific guidance relevant to the agency or government institution.
When performing SDLC design for the federal government, TEDI guides the agency through several weeks of governance discussion and planning. Due to the complexity and evolution of software, application development and the tools to implement the policies need to be capable of evolving alongside development methods.
TEDI recommends leveraging the use of a governance body for policy decisions. The majority of OCIO directorates within a federal agency often possess such a body of directors or leadership. These governance bodies are often referred to as a Change Control Board (CCB), Governance Committee, Strategy Team (etc.), but their purpose maintains consistent. We would leverage or create this governance body to present and deliberate on policies relating to the SDLC and other enterprise systems.
SDLC vs ALM
SDLC is a term used for supporting the process of planning, creating, testing, and deploying solutions for information systems. Operations and Maintenance (O&M) is not part of a standard SDLC. Therefore, SDLC focuses purely on the physical development and deployment of software. Application Lifecycle Management (ALM) refers to the effort, work, and cost associated to the lifespan of an application or tool. Like SDLC, ALM includes the development operations for creating software. However, ALM spans beyond to the O&M and closeout of the application. ALM includes the entire lifecycle of the tool versus just its development and creation.
The importance of understanding SDLC vs ALM is how the application or utility will be used over the course of its lifespan. Costs, updates, and other post development tasks (Operations & Maintenance) are analyzed and considered during ALM. Some federal agencies want to include O&M in either a separate document or somehow associated with the SDLC. In other words, when we are asked to include O&M into the SDLC it is now expanding the SDLC to the entire lifecycle of application.
Governance Team (aka Policy Board, Change Control Board)
The team associated with creating federal OCIO policies should include senior federal employees. Depending on the size and structure of the OCIO office, this can include all or some of the heads of divisions within the OCIO. Collaboration amongst components of divisions is necessary because policies generated can directly impact systems for any or all of these divisions. Therefore, some form of representation for any of these OCIO components should be available to represent the interests of their team. For example, if backup policies are established by the committee for SDLC related content (e.g. TFS), this can impact how normal backup procedures are performed. Therefore, an individual who can weight in for the team handling these kinds of policies should attend. Hence why our general recommendation are senior federal employees.
In order to create and execute policy based IT practices, leadership will need to have a fluid mechanical process to make decisions which should consist of federal leadership. In addition, formulating a committee for an isolated project like the SDLC is not a scalable use of the team. Often, existing committees will take on these responsibilities or in some cases the committee becomes a foreboding tool for policy implementation. TEDI recommends leveraging the use of an existing governance body for policy decisions. Additional responsibilities include, but not limited to, SharePoint Governance, Systems Governance, global backup policies, audit requirements, legal adherence to requirements (e.g. Sarbanes Oxley) and others.
TEDI walks through a series of PowerPoint presentations to guide the committee to render decisions on items specific to that agency. Due to scheduling constraints of many of these individuals, we can identify which players of this committee need not attend or are required to attend depending on the topic. Although we encourage participation throughout the process, the process of policy formulation can require time intensity of specific key stakeholders and we attempt to mitigate unnecessary use of federal employee time.
The Tactical Team represents engineers and SME’s within the OCIO that can lend fundamental IT knowledge and implementation support. Like the governing body identified above, this should include a healthy cross section of capable IT personnel within the OCIO. In addition, these members act as communication liaisons to their teams in the event new policies are being created or changed. They communicate with their colleagues on upcoming changes and implementation needs. Effective communication also allows for member fluidity. In other words, if the Networking Team has 10 members on the team with only 2 normally attend Governance Meetings, the others do not need regular attendance when properly updated. All Tactical Team members should be given meeting minutes to disseminate. All of this provides the ability to interchange Tactical Team members if a particular member is busy or leaves the organization.
Tactical Team members represent a stakeholder team or division by SME’s who can support technical requests or identify how implementation of a particular policy can be performed. There are 2 primary duties of Tactical Team members. This includes attending the Governance Meetings and providing valuable IT knowledge and implementation guidance for estimations of Level of Effort, impact analysis, and how to guidance. The other responsibility is implementation. So Tactical Team members identify to the committee what is required to implement a desired policy and will be expected to perform those changes.
IT operations support by Tactical Team members include any technical requirement to be performed in support of the Governance Team. For example, IT auditing, system backups, networking configurations, TFS configuration, and other tactical operations. This represents the implementation wing of the OCIO. This also allows for direct communication from members who implement technical support with those rendering decisions on what support to perform. This direct line of communication has various side effects that improve organizational performance including more effective ownership, adherence to deadlines, and communication of impediments.
US Government agencies generally utilize SDLC frameworks to ensure adherence with specific provisions, milestones, and policies instituted by the Federal Government (e.g. 508 Compliance). Therefore, facilitation is a well-planned approach to coordinate and ensure all relevant topics specific to that agency are addressed. In addition, member selection of the committee is performed to ensure that the key players and stakeholders are included in the process.
Templates of these PowerPoint Presentations can be downloaded at the bottom of this site. These are the baseline presentations used to identify policy needs around development and development support for the organization. It will guide the committee through topics ranging from IT Security to tool implementation.
The image below identifies a high level rollout of an SDLC implementation within 3 phases. This includes each of steps and descriptions below.
- Governance Team Creation
- Tactical Team Creation
- Analysis of Requirements, Policy Guidance (e.g. PowerPoint), & Solution Design
- SDLC Presentations
- Solution Creation and Prototype
- Final Solution Changes and Edits to Policies if Needed
- Communications and Policy Execution
- Stakeholder Training
A panel of individuals is selected that meet minimum criteria. Generally, this includes senior federal personnel (e.g. GS-14, GS-15, SES). These individuals can but are not required to be senior leadership of their division within OCIO. However, they will need to make policy decisions that impact the OCIO and organization, hence the need for seniority. At TEDI, we often see division directors, Deputy CIO, and CIO as members of the committee but in most cases we leverage an existing governing body.
Simultaneous to the creation of the Governance Team, members of the Tactical Team are identified along with their alternates. These individuals include IT support personnel (e.g. Developers, Networking Engineers, Project Managers etc). These individuals must be able to provide feedback on Level of Effort and Issues associated with proposed policies. In addition, these individuals will likely be implementing new technology or configurations in support of these policies. The Tactical Team will also be first to audit for adherence to new policies.
TEDI takes organizational requests and organizational requirements into account and will update/alter material. This includes customizing presentations for the specific needs of the organization. For example, if 508 Compliance is a priority of the agency, then TEDI ensures that we address this concern to agency specific needs via our PowerPoint Presentations. In addition, we also prepare tool solution recommendations to the committee. Most often, TEDI customizes both the TFS Process Template and integrated SharePoint Portal to facilitate SDLC requirements. In addition, TEDI has also implemented Project Server in supporting this effort. Other technologies can include GitHub, Jira, Microsoft Systems Center, and a collection of Microsoft and Development tools that federal agencies tend to use. Our solution can be a composite of technologies depending on the needs of the organization.
Once TEDI has customized the Policy Presentations we take Governance Team and Tactical Team through several weeks of review and deliberation. We cover policies by topics including Supporting Technologies (e.g. TFS), Development Methods & Practice, IT Security, and Operations Support to name a few. These are created through working with key stakeholders on current development activities. The Presentations are meant to flush out and capture business demands, constraints, impediments, and policy/legal requirements beyond what is currently underway.
TEDI will work with the Tactical Team in creating and executing solutions or customizations to technical platforms in order to facilitate the SDLC. TEDI works with various Out of the Box (OOTB) and custom solutions to facilitate the end result. For example, Microsoft has a suite of tools associated with delivering effective SDLC practices. This depends on the depth of investment by the agency for such tools. Often we encounter agencies investing in both Microsoft and COTs applications. Our depth of knowledge here is deep so that we can implement solutions with tools and applications within SharePoint, Team Foundation Server, Project Server, K2 BlackPearl, Metalogix, and a fleet of other software/tools.
Prototypes are tantamount for delivering expectations. We recommend that all solutions are initial integrated with select teams for testing. This allows us to work out any changes, additions, and other technical needs to facilitate an organization’s SDLC. Normally our prototype and User Acceptance Testing (UAT) is performed for several weeks to several months before widespread release. This is all determined based on the individual needs of the agency.
After a detailed review of our prototypes, the Governance Team and Tactical Team can effectively determine any final changes to both the solution or policies. We have seen that implementation and feedback from federal staff have altered the opinions of leadership and likewise changed policies post implementation. The same is true for the solution. We often encounter requests for alterations or additions to the tools during prototyping. This is normal and flexibility to address these needs and requests must be attributed within planning to ensure a final and scalable solution is delivered.
Communication to the OCIO and organization are necessary to not only properly communicate the launch of the SDLC but also provide guidance on policies that impact members of the organization. A basic communication plan is generally designed with a series of OCIO emails, important links, how to documentation, and dates on stakeholder training. In addition, communication on dates of policy activation should also be disseminated. Auditing and auditing methods are included in communications to ensure individuals are aware of what occurs when an audit identifies their team or practice as noncompliant. Specifics on how this is performed is also trained to OCIO members via Stakeholder Training.
Stakeholder Training are a series of trainings performed for categories of stakeholders. In most OCIO and technical organizations we can divide this amongst varying groups including Developers, Project Managers, Testers, Senior Leadership. Operations, and IT Security. These groups are flexible and are adjusted per each organization. Training is also specific to each agency due to the needs, custom solutions, and custom policies implemented. Priorities range amongst organizations and although much of our pre-designed training is used, many hours are invested into this particular deliverable. Stakeholder training is crucial for many purposes including User Adoption. Hence the need for customized training. In addition, each stakeholder group receive their own customized training guide.
Some of these trainings are available for download.
Beyond the OCIO SDLC document, additional materials are also provided. This can range between agencies, but all receive Stakeholder Training guides, technical configuration guides, and solution design documents. In addition, TEDI adheres to using an Agile approach toward development/configuration and will implement certain baseline documentation requirements per the Project Management Institute (PMI). These PMBOK based documents including Functional Requirements Document (FRD), Requirements Traceability, Solution Design Document (SDD) and others.
Application of the SDLC with Microsoft Tools (e.g. TFS, SharePoint)
Many Government organizations leverage the use of Microsoft tools and technologies. With Enterprise License agreements, most of these organizations can benefit from the array of technologies available to them including Team Foundation Server (TFS), Visual Studio, SharePoint, SQL, Project Server, Microsoft Systems Center, and more. Depending on each agency’s specific license agreements, we encourage the use of TFS and SharePoint for facilitating SDLC. If the organization wishes to capture level of effort, costs, and bottlenecks across OCIO beyond capabilities within TFS and SharePoint, we encourage Project Server.
The list of tools below identifies the most helpful array of Microsoft or Microsoft supporting technology when facilitating an SDLC process. This table will outline what part of the SDLC process each of these tools address.
- TFS for Development
- TFS for Help Desk
- Microsoft Test Manager (MTM)
- Project Server
- Reports via PowerView, SSRS, and TFS
- Microsoft Systems Center and TFS Lab Management
- K2 BlackPearl
Whether Agile, Waterfall, or O&M, TFS provides capabilities for planning, tracking, testing, deploying, and storing source code. The tool can store any file extension which provides its ability for use in developing any kind of tool or testing any kind of application in the market place.
TEDI has customized TFS to provide defect management and help desk supporting (also leverages SharePoint). Sometimes a separate or combined engagement, implementation of an organization wide Help Desk is possible via our customized process templates with TFS. When managing defects in development, organizations often employ this system.
For application testing and User Acceptance Testing (UAT), MTM is ideally suited for tracking test cases, test suites, and the overall effectiveness of a tool or application. MTM comes with Visual Studio and Team Foundation Server as part of the MSDN Ultimate Suite. MTM is also available in other licenses as well.
SharePoint is used for many purposes and often times for custom use by the organization. However, in terms of SDLC, SharePoint is used to capture and facilitate the SDLC process. With the advent of workflows and document retention, required documentation for development projects are stored in SharePoint Document Libraries. Therefore, the document collaboration components of the SDLC are performed within SharePoint. In addition, all reporting is displayed via SharePoint. With the use of PowerView, SSRS, and other reporting tools, TEDI generally creates customized reports for the individual needs of the organization and SDLC. These are published live within SharePoint.
The advent of project server comes with the desire to streamline project management practices, resource management (e.g. developer availability for projects), and portfolio management (e.g. health measurements across all projects). Many organizations wishing to mature their approach toward Project Management and software development advance their process through facilitation of this tool. Although this does require a lot of end user support, when implemented properly leadership can provide scalable Project Management approaches with workflows in Project Server. In addition, they gain the ability to see who is working on what projects and how much of their time is being allocated to particular initiatives with automated reports. The method of capturing metrics allows for portfolio management, or the ability to see how projects are meeting their milestones and project deliverables. In addition, an OCIO office can track negative Key Performance Indicators (KPIs) such as resource over allocation (e.g. developer over 40 hours), missing milestones, or other project red flags so management can intervene before a project becomes grossly off target.
Microsoft supplies an array of Out of the Box (OOTB) reports through each of the tools including TFS, SharePoint, and Project Server. By including each of these tools, OCIO is receiving in access of 12-20 reports per tool and therefore increasing transparency as each are properly implemented. Because so many metrics are being captured, creating custom reports becomes easier to facilitate and often becomes an initiative of many of the federal organizations we encounter. To ensure compliance for policies, legal requirements, and budget, these reports often become critical in tracking and communicating the health of OCIO operations.
When introducing external development or integration of external tools into a secure internal environment, steps must be taken to ensure these outside tools meet project and organizational requirements. For example, standardized security testing for any application may become common place for new tools or project specific testing is performed for ensuring functional requirements are satisfied. These testing procedures can and should be performed in an isolated environment with the same configurations as production to ensure a real environment segregated from damaging government machines.
Microsoft’s approach toward an Integration Environment is recommended to be managed by Microsoft Systems Center and TFS Lab Management. Managing an isolated environment for testing provides a medium for secure testing of applications. Not only can an Operations Team support their VM hosting requirements through Microsoft Systems Center but those in charge of the TFS can maintain their specific Integration Environment. This provides a proper segregation of duties and a blend of rights available to both sets of administrators (e.g. Operations and Development Teams) to succeed in their mission.
PowerShell is often facilitated for various needs including automated configurations and reporting. When installing and configuring tools, PowerShell provides a reference on how the configuration was performed. If machines require reinstallation, we can rerun these PowerShell scripts to ensure consistency in configuration. In addition, PowerShell can be used for automated reporting. With the use of PowerShell scripts, we automate the export of metrics (e.g. csv) from systems and machines with Windows Scheduler. Either SharePoint or SSRS can then receive the raw data for creating reports. We automate this process by ensuring SharePoint or SSRS looks for the new metrics every time PowerShell runs the export of metrics.
When implementing SDLC, much of the backend support relies on SharePoint Workflows to facilitate processes in SharePoint, TFS, and Project Server. SharePoint Workflows often perform much, if not all, of the automation behind project management requirements. K2 BlackPearl is a tool that provides the easy creation and management of these workflows that can drive user adoption. Workflows provide easy ways for processes to be recorded, facilitated, communication, and reported on. When we identify an ongoing need for these workflows, we recommend K2 BlackPearl as a means to facilitate these demands. http://www.k2.com/products-blackpearl-appit