Cybersecurity through the Software Development Life cycle

Software Development Life Cycle Assessment

As a part of BCP, this document discusses the Software Development Life Cycle (SDLC), as one of the major impacts that support viable and resilient cybersecurity posture, especially for organizations who are involved in the development and deployment software that is developed in-house for use throughout their information systems network. Since a robust BCP plan is essential to sustain the viability and operational effectiveness of the network, the software must be developed securely to eliminate or significantly reduce its exposure as an attack vector.

Business Continuity Planning (BCP)

Software Development Life Cycle (SDLC)

At the onset of a project, the SDLC is initiated to document the initial design concept. Through its linear process, the project is refined, developed, tested, deployed for the users to use, and is ultimately retired once the project has met reasonable end-of-life. The SDLC is often referred to as Waterfall Model since the SDLC emphasizes a logical progression of steps similar to the direction water flows from one phase too, which suggests that each phase cannot be revisited after completion (Sarycheva, 2019). The SDLC, as well as other design models, have a primary goal to create results that meet user expectations (Cohen & Haan, 2010). The SDLC contains several variants, discussed in the section below, since the SDLC, while supportive of a viable process for software development, is rather rigid and not adaptable to several development situations (Ghahrai, 2018). While there are variants of the SDLC model, the most common model contains seven discrete phases including (1) Planning, (2) System Analysis, (3) System Design, (4) Development, (5) Testing, (6) Implementation, and (7) Maintenance. However, while the 7-phase SDLC has been described, other researchers indicate that the SDLC can be described in a 5-phase model, by collapsing a few steps together. Each phase of the 7-phase SDLC model is described below:

Planning (Phase One): Phase one, the planning phase, is the most crucial phase of the SDLC since the breadth and scope of the project is delineated. During phase one, the scope of the project and funding is specified. A key element is that the executive sponsor provides support for the project. A needs analysis, requirements specification, and a project plan is created. Costs, time, tasks, and resources are specified. Phase one will set the scope, duration, and funding for the development project, planning, and preparation in this phase are essential.

System Analysis (Phase Two): During phase two, the requirements are analyzed and fleshed out, providing more specificity. The user’s requirements are analyzed and are used to create Functional Requirement Documents (FRD). The functional requirements drive the specific design for programs and modules used in the design and development phases and assist in the initial creation of test cases used in the testing phase. The systems analysis phase also results in screen prototypes, preliminary data and process flow documents, and other supporting diagrams that will help drive the system design process.

System Design (Phase Three): Phase Three systems design results in high-level design specifications including system design documentation that contains diagrams including (a) context diagram(s), (b) data flow diagrams, © flow charts, (d) data modeling (for databases), and other diagrammatic tools that will support the overall design of the system. Further, use cases are derived that will support the subsequent development and testing phases. Also, based on use cases, prototypes are developed and approved by users.

Development (Phase Four): The development phase begins when the delineated functional requirements are transitioned into a programming language. Before taking the functional specifications into code, the systems analyst segments the functions into modules that are commonly distributed to the development team for coding. Also, during the development phase, test cases are built that will later be used in the testing phase to confirm that the system works as expected. Due to the nature of coding, module testing, the construction of test cases, and compliance with development standards, the development phase is typically one of the longest phases in the SDLC model.

Testing (Phase Five): While unit testing is commonly done during the development phase, the testing phase of the SDLC involves several testing types. This includes string testing, where a series of programs/modules are tested for interaction, system testing, where the entire system is tested for functionality, and user testing, where users confirm that the project meets their desired expectation. In each test type, test cases that were previously developed in the development phase are used to validate and verify that the code works as expected. Any changes are noted and can be (a) either fixed immediately or (b) are noted as subsequent changes that will be done once the system is implemented.

Implementation (Phase Six): The implementation phase where modules and programs are deployed from a testing environment into a production environment. During implementation, final verification and validation of the new code and system is done to confirm that the system still executes as expected. Before the roll-out from a test environment to the production environment, a roll-back strategy is designed. The roll-back occurs if the new system is implemented into the production environment and the new system does not perform as expected. Rolling back the environment to a previous state is necessary when a new system does not perform as expected to keep the overall information and networking system in a consistent state.

Maintenance (Phase Seven): The final phase of the SDLC model consists of maintenance. Aside from the lengthy duration of the development cycle, maintenance is generally the longest. Maintenance occurs when the new system is running in the production environment and users are requesting changes to adhere to new business requirements. Also, aside from maintaining code to support new/updated business requirements, the maintenance phase incorporates a retirement sub-phase whereby a system that is in production that is being replaced by a newer system is rolled out of production (or retired) in a measured way.

Variants of the Software Development Lifecycle

There are several variants of the Software Development Life Cycle. The SDLC has been noted as a rigid model and, due to the variety of ways that organizations operate, variants to the SDLC have emerged (Sami, 2012). Several variants are noted below:

Incremental SDLC Model: The Incremental SDLC Model allows for incremental software development by dividing a large information systems project into several smaller chunks. Each of the smaller chunks will be designed with their own SDLC. This model divides the project into smaller subsets, prioritizes the requirements, and implements each subset until all functionality has been implemented (Ghahrai, 2018). There are fundamental strengths in using the Incremental Model. Key portions of the system or high-risk functions can be developed and implemented first. This approach limits the costs and risks. However, the entire SDLC must first be designed before segmenting the project into its constituent parts, so there are no-cost savings in the design aspect, in contrast to the traditional SDLC. However, to its benefit, the Incremental SDLC allows for basic functional requirements to be released to the market early (Kissel, Stine, Scholl, Rossman, Fahlsing, & Gulick, 2008).

Rapid Application Model (RAD): The Rapid Application Model (or spiral model) is a common development model and is part of an agile development approach. As an alternative to the traditional SDLC, its emphasis is on rapid prototyping and iterative delivery of software (Powell-Morse, 2016). As a cyclical model, constituent parts of the overall system can be developed with fewer people and delivered quickly. Also, there is a necessary involvement of users in the development, deployment, and approval for deployed software. Significant benefits of using RAD include cost savings and user involvement. A drawback is that some systems cannot be segmented into small discrete chunks and, thereby, development cannot be achieved by using RAD. Further, Powell-Mores (2016) not that the RAD model cannot be effectively used with older systems and that RAD gives the sense that the system development will never end for a given application.

Structured Evolutionary Prototyping Model: The Structured Evolutionary Prototyping Model uses a porotype (model) that is used to support user requirements before any lengthy design time spent by the development team. Instead, the prototype is used as a model that is built on over time (evolutionary) and confirms the requirements defined by the user and development time. As a benefit to the customer, the prototype allows the customer to visualize the actual system and to iteratively make recommendations for modifications. The prototyping process allows for better understanding and communication between the development team and the customer about system requirements (Harris, 2018).

Spiral SDLC Model: The Spiral SDLC Model combines the features of the Structured Evolutional Prototyping Model and the SDLC model. The Spiral model places an emphasis on risk analysis and management. The Spiral model requires subject matter expertise and uses incremental releases through each iteration (Gurendo, 2015). The Spiral Model provides a benefit to the development team and customer as it provides an early warning of insurmountable project risk (Gurendo, 2015). However, the model can be complex and necessitates expertise. Due to this, time spent evaluating risks within the model may be too time-intensive for small projects (Kissel, 2008). A modification to the RAD model is the Agile Development model, whereby the initial specifications are divided into smaller projects and each of the smaller projects is launched as an individual RAD project.

V-Shaped SDLC Model: The V-Shaped SDLC Model is also known as the Verification and Validation (V & V) Model. Verification and validation are focused on the linkage between each corresponding development stage and its associated testing stage. Each development/testing iteration can only move forward to a successive phase once the prior stage has been (Rajkumar, 2016). The V-Shaped SDLC Model emphasizes planning for verification and validation early on since each deliverable is fully tested. However, the V & V model does not readily handle dynamic requirement change (Rajkumar, 2016).

Software Development Approaches

Prototype Model: As a variant of the SDLC, the prototype model is used to develop project requirements, especially when users are unclear about expectations. Models are successively built to enhance specifications for the overall software development project (GeeksforGeeks, 2018).

Agile Software Development: Agile software development is a development process whereby solutions are derived through the collaborative effort of cross-functional teams that self-organize to address end-user needs for software (Wikipedia, 2020).

Rapid Application Development (RAD): Rapid application development is a particular form of agile software development that incorporates user feedback into the development process to achieve conformity with user expectations and requirements (Singh, 2019).

Dynamic Systems Development: Dynamic Systems Development (DSDM) is a technique that couples with the agile framework based on the Prato philosophy of 80% of the application are delivered in 20% of the time. The focus on DSDM is on leveraging iterative coding to address the 80% (or bulk) of the requirements in a rapid manner (GeeksforGeeks2, 2019).

Spiral Model: The spiral model is an iterative model where each iteration of the ‘spiral’ successively addresses the risks and requirements of the given project. The exact number of iterations or spirals is not known and will vary with each project (Kumar, 2018).

Extreme Programming: Extreme programming is similar to agile programming, where the focus is to improve the quality of software, primarily, with an ability to adapt to the changing requirements of the client (Powe1l-Morse, 2017).

Feature-Driven Development: Feature-Driven Development is a focus of agile development whereby a client-valued function is defined within the context of use cases, which serve as a primary source for planning (Ambler, 2018).

Joint Application Development (JAD): Joint Application Development (JAD) is a method that involves the end-users in the design and development of software through the use of multiple JAD sessions, or collaborative workshops, where the development team and user community discuss user expectations and requirements (Rouse, 2007).

Lean Development: Lean development, or lean software development, follow a repeatable process that relies on quality standards and team collaboration to address the specifications for software development (Planview, 2020).

Rational Unified Processes: RUP is an IBM software development process that divides the development process into four discrete phases, which include (a) business modeling, (b) analysis and design, © implementation/testing, and (d) deployment (TechTerms, n.d.).

Scrum Development: Scrum development relies on a framework of team collaboration to solve complex software products that incorporate events, artifacts, and rules that bind software specifications (SCRUM, n.d.).

Each of the above software development techniques noted in the table below that includes a) the Software Development Methodology, b) Pros and Cons, and c) Software Assurance Concerns.

Waterfall Model

  • Pros: Clear understanding of scheduling.
  • Built-in steps to resolve development issues.
  • Cons: Difficult to define objectives.
  • Extended time to complete deliverables. (Globalluxsoft, 2017)
  • Due to the amount of time involved with this methodology it may not be viable to select this SDLC.

Prototype Model

  • Pros: Good return for time and costs.
  • Increased employee empowerment.
  • Cons: Excessive development time.
  • Misunderstanding and confusion. (te<huz, 2018)
  • This is more time-intensive and could cause the project to exceed the time allowed for the development of the solution also added complexity could confuse.

Agile Software Development

  • Pros: Ease of responses to change.
  • Increased flexibility throughout the development cycle
  • Cons: Misunderstanding of methodology.
  • Difficulty predicting outcomes.
  • Since there are many opportunities for change this could lead to misunderstandings and communication issues.

Rapid Application Development

  • Pros: Minimizes the development time.
  • Champions user feedback.
  • Cons: Typically requires highly proficient developers.
  • Increased dependency on development skills. (te
  • To keep pace with this SDLC highly skilled talent is a need that adds to the overall complexity of the development process.

Dynamic Systems Development

  • Pros: Resilient to changes throughout development.
  • Able to adhere to budgetary requirements.
  • Cons: Requires highly proficient developers.
  • Nontraditional, more difficult to communicate and understand.
  • This requires higher-skilled developers which would be more difficult to troubleshoot and resolve issues as they arise.

Spiral Model

  • Pros: High level of flexibility, ease of making changes.
  • Good fit for addressing challenging projects.
  • Cons: Not a good fit for small or simple projects
  • The final product is difficult to determine early in development. (te
  • This is not a good solution for smaller projects and it is challenging to assure the outcome of the development process during the phases of development.

Extreme Programming

  • Pros: Solutions are developed quickly, fast turnaround.
  • Lower cost since faster development allows for fewer changes throughout the process.
  • Cons: The faster pace is due to less documentation done.
  • Higher pressure at a faster pace methodology. (te<huz, 2018)
  • Due to the faster pace of this SDLC, there is less time for documentation and an increased likelihood of mistakes being made.

Feature-Driven Development

  • Pros: Good for large scale projects.
  • Resulting features are better than in the beginning.
  • Cons: Not a good fit for smaller projects or teams.
  • Documentation is scarce if any. (Globalluxsoft, 2017)
  • This is not ideal for smaller projects and would result in less documentation being available with the final deliverable.

Joint Application Development

  • Pros: Requirements are well defined and clearly understood.
  • Maintains continuous and proper communication between clients and developers.
  • Cons: Time intensive to develop a full solution.
  • Considerable investment in planning and requirements can increase total costs. (te
  • Since this is time-intensive the duration of the project could exceed the due date of the deliverable and the longer this takes the higher costs would be incurred.

Lean Development

  • Pros: Low cost, economical choice.
  • The team is motivated to have high standards and make every feature perfect.
  • Cons: Documentation needs to be precise and analysts need to have full understanding to be effective.
  • Requires highly skilled developers with immense knowledge in the field. (Globalluxsoft, 2017)
  • If documentation is not 100% accurate and well put together this could cause catastrophic errors that could comprise the development project.

Rational Unified Process

  • Pros: Ample amount of resources and literature is dispensed by its creators.
  • Emphasizes maintaining precise documentation.
  • Cons: Complex methodology which requires expert developers.
  • Components can rarely be reused hence the time spent is for a single purpose. (te<huz, 2018)
  • Highly skilled developers are required and much of the progress is only valid for specific sections and cannot be utilized in other areas.

Scrum Development

  • Pros: High adaptivity to requirements amidst the project management cycle.
  • The product owner is constantly in communication with the development team.
  • Cons: Requires senior developers to control SDLC.
  • Initial timeframes are adjusted too often difficult to stay on schedule. (Globalluxsoft, 2017)
  • This is difficult to deliver a product on a firm date and time also it hinges on having highly skilled developers.

Table 1: Software Methodology Comparison

Software Development Security Testing

  1. An understanding by the developer of the value of data used in the software and how the developed code protects the data,
  2. The sum of all paths that data and commands can ingress and egress from the software,
  3. An inspection to ensure that code that protects these noted data and command paths; including the resource that the program connects to
  4. An examination into the facilities that provide authentication and authorization to the execution of the code on the system,
  5. Validation and verification of the data stream to examine for suitable encoding, decoding and encryption/decryption of the data
  6. The use of encryption, checksums, data integrity, and access auditing is used (Force & Initiative, 2013).

To effect a software security testing, a baseline must first be established so that any future changes can be measured and confirmed to the baseline. To this end, the development of an attack surface map must be created. The attack surface map denotes several potential attack vectors including points of entry to the software, such as in the use of HTTP headers, or user display forms, or the use of run-time arguments must be defined, as they present attack vectors that an attacker can leverage. Further, aside from the ingress/egress of data and the many methods that a program can use for input, processing, and output, it serves the developer to ask “How will the attacker view the code?”, which may provide additional insight to the developer in code reviewfor security. Also, the use of vulnerability scanning tools, such as Abby Scan, AppScan, and many others that are noted on the OWASP website (OWASP, n.d.) can support the developer in mitigating security issues in developed code. Once an attack surface map is developed, a priority ranking of high-risk areas are to be identified and addressed. Developing secure code is a process and necessitates the use of a configuration management process, the establishment of a baseline for program security, and the use of an attack surface map to prioritize risk that must be addressed.

Capability Maturity Model

  1. Level 1 — Initial: Processes used for development are disorganized and may even be chaotic. Project success is dependent on individual efforts. Project success is considered to be non-repeatable since processes are not sufficiently defined and documented.
  2. Level 2 — Repeatable: Basic project management techniques are established, and successes could be repeated, because the requisite processes would have been made established, defined, and documented.
  3. Level 3 — Defined: The organization has developed a software process, including more defined documentation, standardization, and integration that can support repeatability.
  4. Level 4 — Managed: An organization monitors and controls processes by collecting data and performing analysis. Metricssupport repeatability.
  5. Level 5 — Optimized: An organization’s processes are constantly improved by monitoring feedback of current processes. Additional innovative processes are introduced to support the organization’s repeatability (Rouse, 2007).



Cohen, S. & Haan, U. (2010). A software system development life cycle model for improved stakeholders’ communication and collaboration. Retrieved January 30, 2020, from International Journal of Computers Communications & Control, 5(1), 20–41.

Crnkovic, I. & Larsson, S. (2006). Component-based development process and component lifecycle In Software Engineering Advances. Retrieved January 30, 2020, from International Conference on (pp. 44–44). IEEE.

Force, J. T., & Initiative, T. (2013). Security and privacy controls for federal information systems and organizations. NIST Special Publication, 800(53), 8–13.

GeeksforGeeks. (2018, April 5). Software Engineering: Prototyping Model. Retrieved February 9, 2020, from

GeeksforGeeks2. (2019, June 18). Dynamic Systems Development Method (DSDM). Retrieved February 9, 2020, from

Ghahrai, A. (2018). The Incremental SDLC Model. Retrieved January 30, 2020, from

Globalluxsoft, (2017). 5 Popular Software Development Models with their Pros and Cons. Retrieved February 7, 2020, from development-models-with-their-pros-and-cons-12a486b569dc

Gurendo, D. (2015). Software Development Life Cycle, Spiral Model. Retrieved January 30, 2020 from

Harris, K. (2018). Difference with Evolutionary Prototyping. Retrieved January 30, 2020 from

Kissel, R. L., Stine, K. M., Scholl, M. A., Rossman, H., Fahlsing, J., & Gulick, J. (2008). Security considerations in the system development life cycle (No. Special Publication (NIST SP)-800–64 Rev 2).

Kumar, S. (2018, May 28). Software Engineering: Spiral Model. Retrieved February 9, 2020, from

OWASP. (n.d.). Vulnerability Scanning Tools. Retrieved January 28, 2020, from

Planview. (2020, February 8). 7 Guiding Principles of Lean Development. Retrieved February 9, 2020, from

Powell-Morse, A. (2016). Rapid Application Development (RAD): What is it and how do you use it? Retrieved January 30, 2020 from

Powell-Morse, A. (2017, November 2). Extreme Programming: What Is It And How Do You Use It? Retrieved February 9, 2020, from

Rouse, M. (2007, March 1). What is JAD (Joint Application Development) ? — Definition from Retrieved February 9, 2020, from

Rouse, M. (2007, April 6). What is Capability Maturity Model (CMM)? — Definition from Retrieved January 28, 2020, from

Sami, M. (2012). Software Development Life Cycle Models and Methodologies. Retrieved January 31, 2020 from

Sarycheva, Y. (2019). Waterfall Model in SDLC. Retrieved January 30, 2020 from

SCRUM. (n.d.). What is Scrum? Retrieved February 9, 2020, from

Singh. (2019, December 6). What Is Rapid Application Development (RAD)? Retrieved February 9, 2020, from

TechTerms. (n.d.). RUP (Rational Unified Process). Retrieved February 9, 2020, from

te<huz, (2018).=”” 12=”” 2020,=”” 7,=””

Wikipedia. (2020, February 7). Agile software development. Retrieved February 9, 2020, from


About the Author

Dr. Ron McFarland, CISSP, PMP is a Cyber Security Analyst at CMTC. He received his doctorate from Nova Southeastern University’s School of Engineering and Computer Science and a post-doc graduate certificate in Cyber Security Technologies and a MSc in Cybersecurity Technology from the University of Maryland (Global Campus). He also holds multiple security certificationsincluding the prestigious Certified Information Systems Security Professional (CISSP) certification and several Cisco certifications. He is a guest blogger at the Wrinkled Brain Network ( ), a blog dedicated to Cyber Security and Computer Forensics. Dr. McFarland can be reached at his University of Maryland email is:

Dr. Ron McFarland, CISSP, PMP guest blogger at Highervista, LLC (email:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store