Software Development Life Cycle

The 7 stages of the Software Development Life Cycle (SDLC) typically include:

Analysis > Planning > Design > Development > Testing > Implementation > Maintenance

Each phase involves specific activities and deliverables to ensure a systematic approach to software development or system implementation. The SDLC life cycle is a structured framework that outlines the software development process from conception to deployment.  SDLC mitigates project risks by systematically planning, designing, and testing software before deployment. By identifying potential issues early and incorporating feedback throughout development, the SDLC enhances predictability and reduces the likelihood of costly errors during implementation and ongoing maintenance. 

Stage 1: Requirements & Analysis - Business analysts gather requirements from their customers, target market, and industry experts to create a Business Specification/Requirements document.

Stage 2: Project Planning - Based on the Business Specification document, senior development team members bring together the input of stakeholders and experts to plan out a software development project.

Stage 3: Design - This stage focuses on designing the product. It involves product architects and developers who will form and present a design of the product.

Stage 4: Development - Production commences and the product is built. The programming code is built per the DDS (Stage 3), so the product can be created with the utmost efficiency.

Stage 5: Testing - Where the development team conducts software testing to find errors and deficiencies. (UAT - User Acceptance Testing)

Stage 6: Implementation - Once the software application has undergone testing and QA (quality assurance), it is delivered to the customer.

Stage 7: Maintenance - Because a software product’s usage varies from customer to customer (each person has different needs), there may be unique issues that come up and need to be addressed. These customer issues are solved in this maintenance stage. 

During any system implementation or portfolio accounting system conversion, there will be multiple ‘environments’ that different users utilize. While the SDLC is an entire process, the ‘environments’ created help users and programmers to facilitate an orderly transition to the new Future State system. ‘Copies’ of the newly created system would exists in these different environments from which to utilize data for various testing situations.

DEV - Development environment

Historical data would be loaded from the Legacy to Future State system (through a fixed point in time) in this environment. The data is then validated to ensure all data points were loaded AND the data was loaded to the right ‘locations’ in the system. Additionally, initial skeletal structure (settings, hierarchies, etc) of the system are developed, with a minimal functionality. This historical data gives the Firm a basis from which to start creating & testing (customized) or using (canned) reports that are to be available in the Future State system.

Historical Data should NEVER be loaded just to ‘get the data in there’. Historical data loads should be reflective of how your Future State data will be eventually uploaded into the system on an ongoing basis. Depending on whether the data is updated through a feed or by some type of flat file upload, a Future State data upload process should be developed simultaneously so that an efficient process can be created. This will allow for a consistent process, between Historical and Go Live data, utilizing the same data upload specifications and processes across all departments and workstreams.

These types of data loads are typically done by your Firms IT department, or department that responsible for the overall data integrity of the Firm. Data is Data! Data loads should never be separated out by department, functionality, workstream, etc. and should be performaned by a separate, disassociated party.

BRD - business requirement Documentation

During Stages 2 and 3, output reports and other functionalities to be present in the Future State system should be documented in this stage. These Business Reporting Requirement documents would exist for each functionality/report/output that is to exist in the Future State system. These BRDs would contain detailed specs of each requirement/output, along with visualizations/pictures/ to prove out the output is expected to look.

A BRD process to follow could be:

1. Reports to be created are determined by the Client.

2. Specific requirements documents are created by the Client, outlining both descriptive and visualizations of the report(s) that will be created in the Future State system.

3. Requirement documents are sent to the Vendor for digestion/analysis.

   1. Feedback is received from the Vendor and items are fleshed out accordingly based on the documentation provided.

4. Vendor comes back with both a) time frame for completion and b) cost associated with the request(s).

   1. Client / Vendor come to an agreement and client approves the work. Vendor begins the creation of the request(s).

5. Report(s) created are in UAT for client testing (after testing has preliminarily been done by the Vendor).

6. Client tests the report(s), and feedback provided en mass (not piecemeal) to the Vendor for clarification/fixing.

7. Once all items are corrected, Client approves the report(s) and then moved into PROD for eventual use.

Note: Any/all documentation regarding this process is stored/saved for future learning, identification, report capabilities, changes, etc.

UAT - user acceptance testing environment

The UAT environment will contain ALL of the data & settings created in the DEV environment, but will exist as a copy of DEV, for UAT testing purposes. As reports and functionality are ‘rolled out’, these reports/functions are put into the UAT environment. This separation gives the users time to test these reports and functions using their own historical data. This is not Parallel testing just yet, but testing to ensure that the Legacy outputs match the Future State outputs, using their own client data.

Some people believe that UAT is a stage entirely in and of itself of which ALL testing for all Business Requirements are tested, en mass. However, UAT outputs are typically delivered in ‘phases’ or ‘pieces’ where different reports and functionalities are created and released for intitial testing by the programmers. Your Firm needs to decide on the best approach, however, implementation stages based on functionalities, with various iterations of release is typically the best route to go. Otherwise, you are testing EVERYTHING all at once, which is unrealistic and burdensome.

Specific users are assigned to specific parts of the UAT process and are responsible for the testing of that report/functionality, and documented as such. Your Firm should design an efficient process on how to communicate effectively with the Vendor based on specific priorities at your Firm. Having a Project Manager who is capable is a vital part of this stage of the process.

prod - production environment

Once UAT testing is done on a specific report/functionality, your Firm may choose to allow some functionality of the Future State system to specific/certain users in what is called a Production Environment. This environment is where tested and ready for use reports/functionalities can be used by a specific user. In this environment, the data is not ‘sactioned’ to be used for actual reporting (to a client or outside of the Firm), but is where all of the functionalities/reports go once they are tested and ready for use. This PROD environment is the precursor to the Live environment.

PROD may exist with specific users at a Firm, or be available Firm-wide. Typically, a representative from each Department utilizing the application’s data is chosen to be the Lead, so an efficient and cohesive communication pattern can exist.

Parallel

Once again, your Firm may choose to wait for all of your reports/functions to be done with UAT to begin Parallel OR your Firm may decide to rollout specific functionalities in stages/pieces (this typically depends on the length of time your project, etc). Parallel is a type of testing whereby dual processing occurs between both your Legacy and Future State systems. (A Stale Data update would need to occur prior to this phase of testing - See next section below)

Parallel testing ensures that the Future State processes coincide with existing Legacy outputs. Your Firm will typically run through a few cycles (months, weeks or quarters) of Parallel testing depending on the complexity of your project. Each function that is performed in the Legacy system is also performed in the Future State system to ensure proper and accurate outputs. Future State system output is NOT used for external reporting during this phase, for Legacy outputs are still considered the gold-standard.

This Parallel phase is the most important, and unfortunately, the most time consuming, since double work must be performed by each user.

Go Live!

Once your Parallel testing is completed, and your Firm is ready to make the switch, the Go Live date is when the Legacy System stops being used and the Future State system data is utilized for official reporting. The ‘switch has been flipped’ and your implemention is complete, DEV & UAT will cease to exist, whereby the PROD environment is utilized going forward.

Note: No implementation is EVER complete after Go Live. Considerations must be made as to what level of acceptable unctionality is ready (MVP - minimum viable product), and then changes/modifications, etc. will be made in the Live Production environment on a go forward basis. UAT still can be utilized, if necessary, and is an individual decision based on the needs of the Project.

Stale Data - What to do?

During any system implementation, the data in DEV (along with UAT) will undoubtedly become stale. As with most projects of a given size, data is loaded through a certain point (ie June 30th) and then tested from there. But as the project moves along, it is possible that an appendage of data might need to be added to the DEV environment to keep that data current (ie through September 30th). Additional data would be loaded into DEV, and then be COPIED over to UAT. Just the data though, for this will allow users to test the reports/functions in UAT on more timely historical data. These ‘updates’ are infrequent, and only done if/when the historical data becomes stale or too outdated from which to adequately test.

dev environment data errors - what to do?

It is possible that the data loaded into your DEV environment could have errors in it. A user will typically find errors in/during the UAT testing of reports/functionalities. This will eventually happen and if/when it does, the data must be corrected in DEV, and ONLY DEV. The data is corrected in DEV and, for the time being, the UAT data will continue to be incorrect. The Firm would not go about updating/correcting both the UAT and DEV environments each time a data error is found. Errors would be tracked, and new historical data would be corrected in DEV in periodic/planned updates. Once updated in DEV, the DEV environment would be copied over into UAT for continued testing.

Note: This periodic update typically coincides with the Stale Data update process, however, DEV to UAT copies can be done at other intervals. Proper coordination and planning is necessary to ensure proper data consistency across environments.

Scheduling Training on a Future State system is a difficult endeavor to coordinate. If you train your users on the Future State system too early, by the time testing rolls around, your users may have forgotten everything. Subsequently, if you schedule training too late, then adequate UAT testing may not be achieved because the users won’t be able to validate anything, because the knowledge of the system isn’t there.

Additionally, it is always best to train your users on your Firm’s own data, rather than a fictitious data set that is used for Training purposes. Training on your Firm’s data is always most practical, yet not always an available option.

Training schedules should always be in your list of priorities, and it is up to each individual implementation timeline and schedule to determine the most effective time for Future State system training to occur. It is best to research all of your Training options and have them on hand, for when the eventual time draws near, Vendors might only allow training classes as specified time intervals. Therefore your Firm might a) just have missed the last class or b) the next class is 2-3 months away!