In spite of the term Software Development Lifecycle (SDLC), there aren’t concrete steps to follow when coding. Each case is somewhat different, even if there is one universal truth: Certain standards apply across the board. Data integrity is one such standard.
The Ultimate Software Development Lifecycle Goal
It may not be the ultimate goal, as that would be releasing a functional piece of software. However, as a key consideration of any successful Software Development Lifecycle (SDLC), data integrity is a requirement that must not be ignored. That goes for GlobalVision's proofreading software, which follows an SDLC approach, too.
The term “data” is relatively straightforward: information collected and potentially used by the application. “Integrity” is, of course, the end result achieved through the process of keeping that data uncorrupted and unchanged. It goes hand in hand with the concept of data security, which is sought after through the act of taking the necessary measures to protect it.
For example, individual lifecycles have proper security precautions built into them and controls added at each step. One precaution would be the act of defining early on the sensitivity of the data a given system will require. As James E. Purcell writes in his paper, “Defining and Understanding Security in the Software Development Life Cycle”, this enables the security needs of the firm to be considered come the time for decisions to be made later on in the process.
Failure to do so leads to potentially unforeseen consequences and add-ons and patches after the fact. Almost by definition, those should be the last resorts.
The Software Development Process
Taking the development process one meticulous step at a time is a way to avoid them. As alluded to earlier, there is a variety that can be followed, but, generally speaking, as a list, it looks like the one below:
Analyze and Plan, which should include preliminary risk assessment.
Relevant regulations that will come into play should be looked at and a plan of action as to how to address them should be devised. This should be reflected in the resulting software-requirement-specification document that comes out of these two phases.
Design, where whatever needs to be in the software gets included in the design specification document. Depending on the system being designed and compliance considerations, it may end up including failsafes with regard to the database, so it is easily backed up and restored. Furthermore, as a security precaution to protect against data being stolen or corrupted, encryption, if applicable, is identified as a necessity at this stage.
Build the Software, presumably using secure code to eliminate any potential vulnerabilities that may surface.
Test, with regard to all aspects of the software in a thorough, structured fashion. Testing is as universal as it gets and becomes a focal point of a product’s development regardless of the industry. When it comes to software though, aspects like code quality and security testing are just two of many that should be considered here, ideally by a dedicated quality-assurance team.
Unit testing, where the smallest testable parts of an application are verified for bugs and vulnerabilities independently, is also a popular pre-emptive strike against breaches but can be automated. Meanwhile, black-box testing, which places the application under the microscope of a tester who does not look at its internal workings (as if it were in a black box), seeks to test a variety of things, including external database access and the software for data-structure errors.
Deploy or Release, finally. That’s assuming all tests have passed and any security shortcomings that had been documented during the testing phase have been resolved. As part of the final quality checks of the software, further security testing may actually be done.
Maintain and Evaluate, which translates to updating the software via security upgrades and improvements whenever necessary. It turns out, sometimes there are good reasons behind those Apple iPhone updates.
Dispose, as, even in obsolescence, software must be handled with discretion. If the software is in the midst of being replaced, caution must be exercised to ensure any sensitive data is archived securely or disposed of in its entirety.
After all, any SDLC seeks to create software that is useful to the organization. Logically, software that can be superseded by a newer version has outlived that usefulness. By the same token, an application without the appropriate level of security is relatively useless, to begin with.
The Importance of Data Integrity
As a result data integrity becomes increasingly paramount, depending on the industry in which the software will be used. Expensive changes may be called for at a later date by auditors, but that’s only if the organization in question is relatively lucky.
In a worst-case scenario, hackers could find a way in, compromising not just the integrity of the data but the brand equity of the company too. That could cut any software development cycle drastically short. It doesn’t have to be that way, as the above steps show.
