Software Development Life Cycle (SDLC)

I created consolidated slides to illustrate most of the popular software development models. I hope that you will like it.


Black Box Security Analysis and Test Techniques

Black box techniques are the only techniques available for analyzing and testing nondevelopmental binary executable without first decompiling or disassembling them. Black box tests are not limited in utility to COTS and other executable packages: they are equally valuable for testing compiled custom developed and open source code, enabling the tester to observe the software’s actual behaviors during execution and compare them with behaviors that could only be speculated upon based on extrapolation from indicators in the source code. Black box testing also allows for examination of the software’s interactions with external entities (environment, users, attackers)—a type of examination that is impossible in white box analyses and tests. One exception is the detection of malicious code. On the other hand, because black box testing can only observe the software as it runs and “from the outside in,” it also provides an incomplete picture.

For this reason, both white and black box testing should be used together, the former during the coding and unit testing phase to eliminate as many problems as possible from the source code before it is compiled, and the latter later in the integration and assembly and system testing phases to detect the types of byzantine faults and complex vulnerabilities that only emerge as a result of runtime interactions of components with external entities. Specific types of black box tests include:

Binary Security Analysis

This technique examines the binary machine code of an application for vulnerabilities. Binary security analysis tools usually occur in one of two forms. In the first form, the analysis tool monitors the binary as it executes, and may inject malicious input to simulate attack patterns intended to subvert or sabotage the binary’s execution, in order to determine from the software’s response whether the attack pattern was successful. This form of binary analysis is commonly used by web application vulnerability scanners. The second form of binary analysis tool models the binary executable (or some aspect of it) and then scans the model for potential vulnerabilities. For example, the tool may model the data flow of an application to determine whether it validates input before processing it and returning a result. This second form of binary analysis tool is most often used in Java bytecode scanners to generate a structured format of the Java program that is often easier to analyze than the original Java source code.

Software Penetration Testing

Applies a testing technique long used in network security testing to the software components of the system or to the software-intensive system as a whole. Just as network penetration testing requires testers to have extensive network security expertise, software penetration testing requires testers who are experts in the security of software and applications. The focus is on determining whether intra-or inter-component vulnerabilities are exposed to external access, and whether they can be exploited to compromise the software, its data, or its environment and resources. Penetration testing can be more extensive in its coverage and also test for more complex problems, than other, less sophisticated (and less costly) black box security tests, such as fault injection, fuzzing, and vulnerability scanning. The penetration tester acts, in essence, as an “ethical hacker.” As with network penetration testing, the effectiveness of software penetration tests is necessarily constrained by the amount of time, resources, stamina, and imagination available to the testers.

Fault Injection of Binary Executable

This technique was originally developed by the software safety community to reveal safety-threatening faults undetectable through traditional testing techniques. Safety fault injection induces stresses in the software, creates interoperability problems among components, and simulates faults in the execution environment. Security fault injection uses a similar approach to simulate the types of faults and anomalies that would result from attack patterns or execution of malicious logic, and from unintentional faults that make the software vulnerable. Fault injection as an adjunct to penetration testing enables the tester to focus in more detail on the software’s specific behaviors in response to attack patterns. Runtime fault injection involves data perturbation. The tester modifies the data passed by the execution environment to the software, or by one software component to another. Environment faults in particular have proven useful to simulate because they are the most likely to reflect real-world attack scenarios. However, injected faults should not be limited to those that simulate real-world attacks. To get the most complete understanding of all of the software’s possible behaviors and states, the tester should also inject faults that simulate highly unlikely, even “impossible,” conditions. As noted earlier, because of the complexity of the fault injection testing process, it tends to be used only for software that requires very high confidence or assurance.

Fuzz Testing

Like fault injection, fuzz testing involves the input of invalid data via the software’s environment or an external process. In the case of fuzz testing, however, the input data is random (to the extent that computer-generated data can be truly random): it is generated by tools called fuzzers, which usually work by copying and corrupting valid input data. Many fuzzers are written to be used on specific programs or applications and are not easily adaptable. Their specificity to a single target, however, enables them to help reveal security vulnerabilities that more generic tools cannot.

Byte Code, Assembler Code, and Binary Code Scanning

This is comparable to source code scanning but targets the software’s uninterpreted byte code, assembler code, or compiled binary executable before it is installed and executed. There are no security-specific byte code or binary code scanners. However, a handful of such tools do include searches for certain security-relevant errors and defects; see for a fairly comprehensive listing.

Automated Vulnerability Scanning

Automated vulnerability scanning of operating system and application level software involves use of commercial or open source scanning tools that observe executing software systems for behaviors associated with attack patterns that target specific known vulnerabilities. Like virus scanners, vulnerability scanners rely on a repository of “signatures,” in this case indicating recognizable vulnerabilities. Like automated code review tools, although many vulnerability scanners attempt to provide some mechanism for aggregating vulnerabilities, they are still unable to detect complex vulnerabilities or vulnerabilities exposed only as a result of unpredictable (combinations of) attack patterns. In addition to signature-based scanning, most vulnerability scanners attempt to simulate the reconnaissance attack patterns used by attackers to “probe” software for exposed, exploitable vulnerabilities.

Vulnerability scanners can be either network-based or host-based. Network-based scanners target the software from a remote platform across the network, while host-based scanners must be installed on the same host as the target. Host-based scanners generally perform more sophisticated analyses, such as verification of secure configurations, while network-based scanners more accurately simulate attacks that originate outside of the targeted system (i.e., the majority of attacks in most environments). Vulnerability scanning is fully automated, and the tools typically have the high false positive rates that typify most pattern-matching tools, as well as the high false-negative rates that plague other signature-based tools. It is up to the tester to both configure and calibrate the scanner to minimize both false positives and false negatives to the greatest possible extent, and to meaningfully interpret the results to identify real vulnerabilities and weaknesses. As with virus scanners and intrusion detection systems, the signature repositories of vulnerability scanners need to be updated frequently. For testers who wish to write their own exploits, the open source Metasploit Project publishes black hat information and tools for use by penetration testers, intrusion detection system signature developers, and researchers. The disclaimer on the Metasploit website is careful to state:

“This site was created to fill the gaps in the information publicly available on various exploitation techniques and to create a useful resource for exploit developers. The tools and information on this site are provided for legal security research and testing purposes only.”

Choosing the right Software development life cycle model


Selecting a Software Development Life Cycle (SDLC) methodology is a challenging task for many organizations. What tends to make it challenging is the fact that few organizations know what criteria to use in selecting a methodology to add value to the organization. Fewer still understand that a methodology might apply to more than one Lifecycle Model. Before considering a framework for selecting a given SDLC methodology, we need to define the different types and illustrate the advantages and disadvantages of those models (please see Software Development Life Cycle Models and Methodologies).

How to select the right SDLC

Selecting the right SDLC is a process in itself that organization can implement internally or consult for. There are some steps to get the right selection:

STEP 1: Learn the about SDLC Models

SDLCs are the same in their usage, advantages, and disadvantages. In order to select the right SDLC, one must have experience and be familiar with the SDLCs that will be chosen.

STEP 2: Assess the needs of Stakeholders

We must study the business domain, user requirements, business priorities, and technology constraints to be able to choose the right SDLC against their selection criteria.

STEP 3: Define the criteria

Some of the selection criteria or questions that you may use to select an SDLC are:

  • Is the SDLC appropriate for the size of our team and their skills?
  • Is the SDLC appropriate with the selected technology we use for implementing the solution?
  • Is the SDLC appropriate with client and stakeholders need and priorities
  • Is the SDLC appropriate for the geographical situation (co-located or geographically dispersed)?
  • Is the SDLC appropriate for the size and complexity of our software?
  • Is the SDLC appropriate for the type of projects we do?
  • Is the SDLC appropriate for our engineering capability?

What are the criteria?

Here is my recommended criteria, what will be yours?

Factors Waterfall V-Shaped Evolutionary Prototyping Spiral Iterative and Incremental Agile Methodologies
Unclear User Requirement Poor Poor Good Excellent Good Excellent
Unfamiliar Technology Poor Poor Excellent Excellent Good Poor
Complex System Good Good Excellent Excellent Good Poor
Reliable system Good Good Poor Excellent Good Good
Short Time Schedule Poor Poor Good Poor Excellent Excellent
Strong Project Management Excellent Excellent Excellent Excellent Excellent Excellent
Cost limitation Poor Poor Poor Poor Excellent Excellent
Visibility of Stakeholders Good Good Excellent Excellent Good Excellent
Skills limitation Good Good Poor Poor Good Poor
Documentations Excellent Excellent Good Good Excellent Poor
Component reusability Excellent Excellent Poor Poor Excellent Poor


Selecting a Software Development Life Cycle (SDLC) Methodology.(2012, 3 18). Retrieved from

Software Development Life Cycle Models. (2012, 3). Retrieved from

Software Development Life Cycle Models and Methodologies



The software industry includes many different processes, for example, analysis, development, maintenance and publication of software. This industry also includes software services, such as training, documentation, and consulting.

Our focus here about software development life cycle (SDLC). So, due to that different types of projects have different requirements. Therefore, it may be required to choose the SDLC phases according to the specific needs of the project. These different requirements and needs give us various software development approaches to choose from during software implementation.

Types of Software developing life cycles (SDLC)

Waterfall Model


The waterfall Model is a linear sequential flow. In which progress is seen as flowing steadily downwards (like a waterfall) through the phases of software implementation. This means that any phase in the development process begins only if the previous phase is complete. The waterfall approach does not define the process to go back to the previous phase to handle changes in requirement. The waterfall approach is the earliest approach that was used for software development.

WaterfallThe usage

Projects which not focus on changing the requirements, for example, projects initiated from request for proposals (RFPs)

Advantages and Disadvantages

Advantages Disadvantages
  • Easy to explain to the users.
  • Structures approach.
  • Stages and activities are well defined.
  • Helps to plan and schedule the project.
  • Verification at each stage ensures early detection of errors / misunderstanding.
  • Each phase has specific deliverables.
  • Assumes that the requirements of a system can be frozen.
  • Very difficult to go back to any stage after it finished.
  • A little flexibility and adjusting scope is difficult and expensive.
  • Costly and required more time, in addition to the detailed plan.

V-Shaped Model


It is an extension of waterfall model, Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The major difference between v-shaped model and waterfall model is the early test planning in the v-shaped model.


The usage

  • Software requirements clearly defined and known
  • Software development technologies and tools is well-known

Advantages and Disadvantages

Advantages Disadvantages
  • Simple and easy to use
  • Each phase has specific deliverables.
  • Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.
  • Works well for where requirements are easily understood.
  • Verification and validation of the product in early stages of product development.
  • Very inflexible, like the waterfall model.
  • Little flexibility and adjusting scope is difficult and expensive.
  • Software is developed during the implementation phase, so no early prototypes of the software are produced.
  • The model doesn’t provide a clear path for problems found during testing phases.
  • Costly and required more time, in addition to detailed plan

Prototyping Model


It refers to the activity of creating prototypes of software applications, for example, incomplete versions of the software program being developed. It is an activity that can occur in software development. It used to visualize some component of the software to limit the gap of misunderstanding the customer requirements by the development team. This also will reduce the iterations may occur in waterfall approach and hard to be implemented due to the inflexibility of the waterfall approach. So, when the final prototype is developed, the requirement is considered to be frozen.

It has some types, such as:

  • Throwaway prototyping: Prototypes that are eventually discarded rather than becoming a part of the finally delivered software

Throwaway prototyping

  • Evolutionary prototyping: prototypes that evolve into the final system through an iterative incorporation of user feedback.


  • Incremental prototyping: The final product is built as separate prototypes. At the end, the separate prototypes are merged in an overall design.


  • Extreme prototyping: used at web applications mainly. Basically, it breaks down web development into three phases, each one based on the preceding one. The first phase is a static prototype that consists mainly of HTML pages. In the second phase, the screens are programmed and fully functional using a simulated services layer. In the third phase, the services are implemented

The usage

  • This process can be used with any software developing life cycle model. While this shall be focused with systems needs more user interactions. So, the system does not have user interactions, such as, a system does some calculations shall not have prototypes.

Advantages and Disadvantages

Advantages Disadvantages
  • Reduced time and costs, but this can be disadvantage if the developer loses time in developing the prototypes.
  • Improved and increased user involvement.
  • Insufficient analysis· User confusion of prototype and finished system.
  • Developer misunderstanding of user objectives.
  • Excessive development time of the prototype.
  • Expense of implementing prototyping

Spiral Method (SDM)


It is combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects. This model uses many of the same phases as the waterfall model, in essentially the same order, separated by planning, risk assessment, and the building of prototypes and simulations.


The usage

It is used in shrink-wrap large applications and systems which built-in small phases or segments.

Advantages and Disadvantages

Advantages Disadvantages
  • Estimates (i.e. budget, schedule, etc.) become more realistic as work progressed, because important issues are discovered earlier.
  • Early involvement of developers.
  • Manages risks and develops the system into phases.
  • High cost and time to reach the final product.
  • Needs special skills to evaluate the risks and assumptions.
  • Highly customized limiting re-usability

Iterative and Incremental Method


It is developed to overcome the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interactions in between. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during the development of earlier parts or versions of the system.

It consists of mini waterfalls


The usage

It is used in shrink-wrap application and large system which built-in small phases or segments. Also can be used in a system has separated components, for example, ERP system. Which we can start with the budget module as a first iteration and then we can start with inventory module and so forth.

Advantages and Disadvantages

Advantages Disadvantages
  • Produces business value early in the development life cycle.
  • Better use of scarce resources through proper increment definition.
  • Can accommodate some change requests between increments.
  • More focused on customer value than the linear approaches.
  • Problems can be detected earlier.
  • Requires heavy documentation.
  • Follows a defined set of processes.
  • Defines increments based on function and feature dependencies.
  • Requires more customer involvement than the linear approaches.
  • Partitioning the functions and features might be problematic.
  • Integration between iteration can be an issue if this is not considered during the development.

Extreme programming (Agile development)


It is based on iterative and incremental development, where requirements and solutions evolve through collaboration between cross-functional teams.


The usage

It can be used with any type of the project, but it needs more involvement from the customer and to be interactive. Also, it can be used when the customer needs to have some functional requirement ready in less than three weeks.

Advantages and Disadvantages

Advantages Disadvantages
  • Decrease the time required to avail some system features.
  • Face to face communication and continuous inputs from customer representative leaves no space for guesswork.
  • The end result is the high-quality software in the least possible time duration and satisfied customer.
  • Scalability.
  • The ability of the customer to express user needs.
  • Documentation is done at later stages.
  • Reduce the usability of components.
  • Needs special skills for the team.


(2012, March). Retrieved from Wikipedia:

(2012, March). Retrieved from Software Developing life cycles:

Software Development Life Cycle Models. (2012, 3). Retrieved from