www.eafx.com - Software Development Life Cycle

Home

Site Map

Architecture

OO Coding Standards - C#, Java...

Construction - Essential Concepts

Software Development Life Cycle

IT Strategy Consulting

Software Development Life Cycle

This document is intended to serve as a source of Standards and Methodology to the Software Developer during the entire Software Development Life Cycle. From a methodology perspective, the intent of adherence to these standards is intended to establish uniformity in codebase, thus enhancing maintainability, readability, learning curve and the ability to support all our software and related infrastructure platforms in a homogeneous manner.

While this document is not designed to be all encompassing, it is recommended to have an organization-wide initiative to both identify and implement changes to this document with time, as Software Development needs dictate. The purpose of this document is to maintain software policy governance at a high level. Manuals and Standards that pertain to the industry standard implementation details of the specific platform and the individual programmer’s knowledge and initiative to adhere to standards and best practices will continue to be the basis of low-level implementation methodology while maintaining compliance with this document.

NOTE: Business Analysts, Systems Analysts, IT Project Managers and Developers are the intended audience for this document. This document may contain technical content that may not enable free reading. However, the conceptual sections of this document are designed to be a good read for anyone directly related to IT Product development and it is recommended that you skim over sections that relate to technical content that seem impertinent.

Phases in the SDLC

Click on any of the stages below to learn more...

Inception User initiated request for change or problem / deficiency statement.
Requirements Definition Defining the requirements – needs (versus wants in many cases).
Cost Benefit Analysis Cost Benefit Analysis is the action of performing a definition of the benefits of investing time, labor and materials to obtain the new feature or enhancement. In many cases, one may outweigh the existence of another.
Scoping - Elaboration Understanding the existing implementation and scoping out the transition / change required to meet that need.
Impact Analysis Understanding the impact of a specific change – enhancement or new feature to the enterprise implementation.
Project Planning Project planning is the art of breaking down the entire project into distinct logical units of work that are tangible in terms of labor and cost and being able to assign resources based on capacity and capability in order to be able to execute these logical units of work with a feasible estimate.
Use Case Definition Defining every atomic process-actor scenario, the permutation and combination sequence of which define the new / modified process.
Functional Requirements Defining how each use case and process will translate into application behavior – usually an algorithmic definition of the process flow.
Conceptual Design A definition of the design changes – with integration into an existing application infrastructure if needed, and high-level class diagrams and sequence diagrams.
Detailed (Functional) Design Definition of each change and elucidation of the flow of code.
Prototyping A Prototype illustrates a working model of the architecture behind an implementation.
Design Review The Design review process will involve a complete review of all artifacts ranging from Requirements documentation to the Design Document to ensure that the methodology and approach to implementing the required solution is correct and necessary.
Threat Modeling - Security Security is the most important aspect of the infrastructure. Every single change needs to be designed against vulnerabilities not only related to performance and business process errors, but also to security. Threat Modeling is the most overlooked, yet most critical part of application design.
Construction Based on the design, implement the changes in code into the code base using the Programming Language or IDE that the development process dictates.
Unit Testing Unit testing is the first logical phase of testing each building block of an application individually.
Source Control Reconciliation New / Modified artifacts should be reconciled with the Source Control database on a periodic basis - Checkpoints.
Test Case Documentation A Test Case is a defined set of steps that an application user or ‘Tester’ will execute to determine whether a requirement has been successfully met or not.
Integration Integration is defined as the act of enabling the execution of the functionality in a module or application in its true execution environment (TEE).
Integration Test Case Documentation Integration Test Case Documentation is defined as the documentation of all applications and modules that integrate with the one that is being changed, and the scenarios in which these applications / modules integrate and criteria to determine if that integration scenario succeeded or failed.
Integration Testing Integration testing is defined as the act of executing a module or application in its true execution environment (TEE) as described in the Integration section.
Regression Testing The testing of software from not only a process and load perspective, but also with the variance of data permutations and combinations to ensure that it will handle all data scenarios that it will encounter during its lifetime, especially when a part of the software has changed.
Test Automation Test Automation is defined as the ability to execute all the unit test cases and integration test cases in an automated manner with the ability to simulate a multi-user environment with appropriate regression to ensure quality.
Source Control – Release Labeling At the point at which the source code has been released to QA, or after QA has successfully extracted a working build on which to perform QA, QA should take a snapshot of the Source code in the form of a labeled release.
Peer Code Review Peer Code review includes a complete review of all the source code that is transitioned as part of the release, all the unit test cases, all the integration test cases and a demo of the integrated build of the application in its true execution environment by a team of peer developers, who preferrably are not involved directly in the development of that release, or at least have the opportunity to review modules that they did not develop.
Build Automation Build Automation is the task of programmatically automating the following steps in SDLC
Packaging Packaging is defined as the activity of organizing or bundling software that has changed in order to prepare it for deployment to a production environment.
Distribution Documentation – Deployment Guide The deployment guide is the documentation handed over to the System Administration, Network Administration and Database Administration team, elucidating the steps that need to be taken in order to release the changes from the Development or QA environment into either the Pre-Production (Staging) or Production environment.
Quality Assurance The QA Team (if there is one), or the development team will be in charge of ensuring that all the artifacts that pertain to this code release are functional and free of defects, with no deficiency in any of the steps covered earlier in this document.
User Acceptance Testing In this step, the Application is provided to the user along with the traceability Matrix and the release notes so that the Business Users and Business Analysts can validate that the solution being implemented meets their needs.
Training Depending on the functionality being released, after UAT, the Business Analysts and Business users performing UAT will also perform the task of training the end users / customers to utilize the functional changes that result in the application process as a result of these changes.
Training Documentation - User Guide User Guides will enable transition of the system knowledge of the change in the business process to the application users.
Performance Monitoring & Testing Performance Monitoring and Testing are the collective activity of constantly watching peformance metrics to detect anomalies, and testing the system by simulating users and user requests to match a production environment load to ensure that production needs can be met.
Turnover Turnover is the process of successfully deploying a new application or application changes to a production environment and managing and completing the process of knowledge transfer of the new / changed environment with the Production Management Team.
Support, Troubleshooting and Monitoring Documentation The Support, Troubleshooting and Monitoring Documentation is a collective effort by the Development Team, System Administrators, Network Administrators, Database Administrators and the Production Support team to document the system environment, the network environment, the business process environment and key metrics of system behavior in order to be able to manage, detect and correct system issues. This document is both a result of the SDLC and the day-to-day application / system infrastructure maintenance process – a living, breathing document that changes from day to day.
Optimization & Maintenance The task of utilizing monitoring, the troubleshooting guide, application logging and business process monitoring to constantly learn and optimize the existing implementation is key to any system and is an activity that occurs for the entire lifetime of the system.

Eafx Domain Portals