Process Deployment Planning: Understand Existing Development Processes

The first step in process deployment planning is to understand the organization’s development processes. For some organizations this is a relatively easy task. Someone in the organization maintains responsibility for understanding and/or documenting one or more standardized software development life cycles (SDLCs). You simply ask them the questions in the Development Process Questionnaire below. Note any questions they don't know the answers to and see if they can refer you to somebody who can answer them. In the event that you cannot answer a question in a reasonable amount of time, make an assumption based on experience and document that assumption.

For organizations without standardization - or for those where standard adoption is low - define if anyone in the organization has at least a high level understanding of the different development processes. Some possible areas to look into include the Project Management Office (PMO), Office of the Chief Information Officer (CIO), Office of the Chief Technology Officer (CTO), VP of Application Development, Application Lifecycle Management (ALM) tool administrators, and internal controls/information technology auditors. For large organizations, it is often the case that no single person or group interacts with all development teams. In this case, you may need a different person or group for each individual division/line of business; for example, interviewing the CIO of each division. In some cases you may have to go one step further down on the organizational tree (i.e. groups within a line of business or division). If no such person or group exists, then you may need to randomly sample development teams themselves to answer these questions.

While gathering information, you will likely find that many of the development teams have slight variations of the same development process. We call these development process patterns. Processes that follow the same pattern tend to have similar release cycles, roles (though role names may vary slightly), and process steps. It is important to define a process deployment pattern, but not necessarily each individual process. As a result, you should aim to fill-out the Development Process Questionnaire at least once for each pattern.

If you discover that there are more than four major development process patterns, then you should consider taking an iterative approach: focus primarily on the teams who will likely be early adopters of SD Elements. You can build more process integration plans later.


Development Process Questionnaire

For each unique development process pattern you identify, find at least one representative process and answer as many of the following questions as possible. Try to understand what actually happens in practice vs. what is supposed to happen or what the documentation says.

  • Does the team mostly adhere to one or more industry-standard development processes? Examples include: Scrum, Kanban, Rapid Application Development (RAD), Extreme Programming (XP), Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), [Rational] Unified Process ([R]UP). Terms like “waterfall”, “iterative” , “lean” and “agile” do not actually specify a particular process, but rather describe a generalized type of process. “CMMI” describes a model for assessing maturity, but is not itself a development process. These terms are still useful to note down if you cannot find a specific development process name.
  • How frequently does the development team release software?
  • Which roles are involved in the development process? Common examples include: project manager, scrum master, product owner, business/application owner, business analyst, requirements analyst, architect, lead developer, developer/engineer, quality assurance analyst/tester, security architect and enterprise architect.
  • How is new development work initiated? For example, is there a formal project initiation phase? Is the process managed by the development team themselves or a different group such as the Project Management Office (PMO)? Which role(s) are responsible for this?
  • Which role(s) define functional requirements/user stories, and how are they stored? For example, a business owner decides what needs to go into the next release of a product in the form of formal specifications document.
  • Is there a process for defining non-functional requirements today? If so, how does it differ from functional requirements? Who is responsible for defining them?
  • Is there a different process for change management versus a new release of software? Many organizations with more formal development processes distinguish between making a single, small impact change to software versus a formal release with several different changes. Agile/iterative processes which release software frequently may not have such a distinction apart from high priority defect hot fixes.
  • Who is responsible for deciding priorities for a given project/iteration/release?
  • Who is responsible for managing task completion? For example, a project manager or scrum master. If no such person exists, be sure to note this fact down.
  • How are Application Lifecycle Management (ALM) tools used in the process?
  • Are there one or more phases/steps between defining functional requirements and coding? For example, architects review the requirements and create a formal design.
    • If such phases/steps exist, what are the outputs? For example, a design diagram or design documentation.
    • Is information security already involved in one or more of these phases/steps? If so, how?
  • How do development teams take requirements, user stories or design specifications and begin coding work? For example, the product owner prioritizes user stories in the backlog and the development team selects stories to work on during the development process.
  • Do developers follow Test-Driven Development (TDD) or Behavior-Driven Development (BDD)?
  • Do developers write unit tests?
  • Do developers perform manual code reviews?
  • Do developers use continuous integration technologies like Jenkins?
  • Who, if anyone, is responsible for specifically testing non-functional requirements /user stories?
  • Do development teams include dedicated quality assurance testers? Do they write automated test cases, do they perform manual tests, or both?
  • Do the quality assurance testers:
    • Primarily perform specific functional testing (e.g. “Step 1. Click on this box”, “Step 2. Navigate to this screen”, etc.)?
    • Attempt to find any way to “break” a requirement (e.g. apply creativity to see how non-standard input might fail a ticket)?
    • Perform highly technical tasks (e.g. inspect HTTP traffic, etc.)?


Application Security Questionnaire


Alongside understanding development processes, you will need to understand the current landscape of application security. You will typically speak to people in the information security team(s) to answer these questions. In some cases, each division/line of business/group will have different answers. You will also want to understand if the application security touchpoints differ for the different development processes noted above. For example, many organizations have different touchpoints for waterfall vs. agile development.


  • How do you define and document software security requirements today? NOTE: It is common to not have an answer to this.
  • Do developers undergo application security training today? If so, is it delivered in-person, or via Computer Based Training (CBT) modules?
  • Do you currently classify applications by risk (e.g. High, Medium, Low)? If so, what are the classifications, who performs the classification and how do they determine the classification level?
  • Do you perform threat modeling today? If so, which role is responsible for performing it, which applications are in-scope, and how frequently does threat modeling occur? Do you use any threat modeling tools?
  • Are there any special provisions for information security at the beginning of development processes today? For example, applications with a certain risk classification are subject to a review by a security architect.
    • If information security is involved today, try to understand what specific areas of information security these activities cover. For example, many organizations perform a risk assessment primarily composed of data classification and infrastructure security with minimal coverage of application security.
  • Do you use any Static Analysis Security Testing (SAST) tools within the development process? For example, HP Fortify, IBM AppScan Source, Whitehat Sentinel Source, or Veracode.
    • Are these tools automatically launched as part of continuous integration, embedded within the Integrated Development Environment (IDE), launched manually, or run by a different group after development has completed?
    • For non-security specific tools, do they have any coverage of common security issues? For example, Microsoft FxCop, Coverity, Klocwork, or FindBugs.
    • Do development teams have the ability and expertise within the organization to easily customize rules for these tools?
    • Which role(s) is responsible for triaging results from static analysis tools and removing false positives?
  • Do you use any Dynamic Analysis Security Testing (DAST) tools with the development process? For example, HP WebInspect, IBM AppScan, Whitehat Sentinel, Acunetix, Cenzic or Qualys Web Application Scanning.
    • Do development teams have the ability and expertise within the organization to easily customize rules for these tools?
    • Which role(s) is responsible for triaging results from static analysis tools and removing false positives?
  • Is an information security team member involved in performing penetration testing or code reviews? If so, how frequently?
  • Are external/third party experts involved in performing penetration testing or code reviews? If so, how frequently?
  • What is the current process for handling vulnerabilities identified during security testing?
    • Are security vulnerabilities formally tracked somewhere? If so, where/how?
    • Does someone make a risk-based decision on whether or not to stop a release when a vulnerability is discovered? If so, which role makes that decision?
  • Are there any other security activities included as part of the development process?

The answers to these questions will allow you to construct detailed process deployment plans.

Key Questions

  • Who, if anyone, maintains responsibility for standardization of the SDLCs?
  • How closely are development teams actually following all the steps of the standard processes? What percentage of teams are not following the standards at all?
  • See questions in the Development Process Questionnaire and Application Security Questionnaire.
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request