Joint Application Development
Joint application development (JAD) is a methodologies that involves the client or end user in the design and development of an application. The client or end user participates in collaborative workshops called JAD sessions.
The JAD model assumes that customer satisfaction at each stage is the most important objective.
JAD is used in projects that have the following characteristics:
- Involve many groups of users whose responsibilities cross traditional department or division boundaries
- Are considered critical to the future success of the organization
- Involve willing users
- Are first-time projects for the organization
- Have a troubled project history or relationship between the systems and user organizations
The structure of the JAD model includes phases such as planning/definition, preparation, design sessions, and finalization.
The JAD approach leads to shorter development lifecycles and greater client satisfaction because it draws users and information systems analysts together to jointly design systems in facilitated group sessions.
The JAD model is not efficient when requirements are to be finalized before moving on. Requirements are frequently changing with each JAD session. Other challenges are preparation costs, expertise requirements, and communication management.
The customer’s early and ongoing involvement can improve software bug/vulnerability discovery, which reduces future project costs of quality assurance and defect management.
Rapid Application Development
The rapid application development (RAD) model is an iterative model that is based on prototyping. The RAD approach to software development de-emphasizes planning for the sake of development and producing working prototypes.
RAD was a response to the perceived deficiencies of waterfall processes. RAD emphasizes working software and user feedback over strict planning and requirements recording. The RAD model is used to deliver projects in shorter timeframes. Success with RAD requires having the users and budget to test prototypes thoroughly.
The RAD model works well for certain types of projects. RAD works well for projects with a focused scope, where the business objectives are well defined and narrow. The RAD model is useful for quickly generating working software and making measurable progress, rapid and constant user feedback, early systems integration, and adaptability.
The RAD model is not good for projects where the business objectives are obscure or broad. RAD also does not work well when there are many stakeholders involved in project decisions.
Agile
Agile is an iterative customer-value-centric approach to project management and software development methodologies. Agile helps teams deliver value to their customers faster and with fewer headaches. Unlike heavyweight, up-front planning approaches where software is released in “big bang” launches, an agile team delivers working software in small and manageable increments.
Agile emphasizes high-quality communication, technical discipline, and iterative development methodologies.. Requirements and solutions evolve together through the collaborative efforts of self-organizing cross-functional teams. This collaboration prioritizes delivering the highest-value and highest-risk features through working software. Agile compresses the waterfall phases into a disciplined workflow process that is repeated in time-boxed, iterative intervals. Working software is repeatedly produced through these iterations until the product is completed or the project stops.
This section will explore various facets of the agile methodologies.
Agile Manifesto and Principles
The Agile Manifesto, also called the Manifesto for Agile Software Development methodologies, is a formal proclamation of values and principles to guide an iterative and people-centric approach to software development. The manifesto prioritizes collaboration, interaction, software functionality, and responding to change, while still recognizing the importance of documentation, contracts, planning, and processes.
The principles behind the Agile Manifesto, commonly referred to as the 12 agile principles, are a set of guiding concepts that support project teams in implementing agile projects. Agile principles allow people to accommodate changing requirements throughout the development process, ensuring frequent delivery of working software. Attention to technical detail and design can enhance the security of the software.
Security practitioners generally want a solid design before building a product begins, thorough documentation, and accurate risk assessment. Some security professionals are skeptical that the agile methodologies has ramifications for software development security, particularly due to automation, emphasis on testing, the focus on good builds, and continuous integration and deployment. However, many dedicated and experienced agile professionals work hard to establish security as a core competency in the organization’s application of the 12 agile principles.
Automation
A good rule of thumb with automation is that if you perform a task more than three times, consider automating it. Many tasks and processes are involved in producing quality functional software. Automation enables consistent and thorough processing. Automation is a cornerstone process enabler. The more tasks and processes are automated, the less their burden is on the developer, the more consistent their execution becomes, and the less likely mistakes will occur. Reducing human error goes a long way to reducing security vulnerabilities. The less human involvement in software development is, the greater the control over the process is.
Automation integrates security into the development process. Security testing and scanning can be automated. Automation makes security testing and scanning a routine process. It enables a routine delivery of actionable results for the developers to respond.
Emphasis on Testing
Agile development recognizes that testing is not a separate phase but an integral part of software development methodologies, along with coding. Testing and coding are done incrementally and interactively, building up each feature until it provides enough value to release to production.
As one of its core values, agile embraces change. However, every code change is a new potential bug or vulnerability. The most effective way to prevent this is by thorough software testing. Agile processes use many types of testing, such as unit, functional, integration, and regression. Security testing and scanning are part of agile testing.
Testing promotes agility and production speed. When automated, testing continually validates the functional and security states of an application as new code is produced.
Automation allows continuous regression testing to determine if the current code has created bugs or vulnerabilities. This helps maintain a predictable quality of the product’s working software and code.
Agile Lava Lamp, aka Focus on Good Builds
Working software is a core agile value. Automated comprehensive testing is a core agile practice. Tests should verify the working software. When developers check code that causes tests to fail or the software build process to break, it is important to fix the problem before proceeding. A conspicuous signal can be set up in the office to show the build’s status. This signal is sometimes referred to as the agile lava lamp.
This focus on maintaining good builds is essential to maintaining the speed of delivery. A good build is one that was produced that has passed all of the quality and security checks and has been verified as good to use. A good build supports the agile directives for frequent delivery of working software, continuous attention to technical excellence, and good design. A good build is produced by testing to validate its security. This process is automated.
When security testing and verification are built into the build process, the agile lava lamp, or its equivalent, becomes a form of automated secure software assurance.
Continuous Integration/Continuous Deployment (CI/CD)
Continuous integration (CI) is the practice of merging all developer working copies to a shared mainline. CI involves integrating early and often to minimize code incompatibilities. CI aims to reduce rework and thus reduce project cost and time.
Agile teams, because they are producing working code each iteration, need to avoid the time and effort involved with diff resolution and debugging sessions that often occur at the end of long integration cycles. And, the more programmers who work on the code, the more problematic this is. Furthermore, agile teams routinely deliver working software with a progressive number of features completed. CI supports these development process requirements.
Continuous deployment (CD) extends continuous integration by deploying the products of CI into a production environment. This methodologies requires a high degree of maturity in automation in quality assurance and security testing. CD significantly removes human controls from deploying production software. Because of this, it may not be compatible with an SDLC that is subject to regulatory restrictions.
Agile Methodologies Practices
These are some of the more popular agile methodology practices:
- Dynamic systems development method (DSDM)
- Scrum
- Extreme programming (XP)
- Test-driven development (TDD)
- Lean software development
- Minimum viable product (MVP)
Dynamic systems development method
DSDM is an organized, commonsense process focused on delivering business solutions quickly and efficiently. It is an iterative, incremental approach that is primarily based on the rapid application development methodologies. DSDM focuses on the delivery of the business solution, rather than just team activity. It takes steps to ensure the feasibility and business sense of a project before it is created.
Scrum
Scrum is a framework through which people can employ various techniques to solve complex problems and continuously and incrementally deliver valuable products. The Scrum framework uses an empirical process to use a team’s and its customers’ experiences as a driver to make decisions for change to or improvement of a product, workflow, team, or the like. Scrum takes an iterative and incremental approach to optimize processes and outcomes and control risk.
The scrum team participates in scrum ceremonies to continually make progress toward its goals. The scrum team consists of three roles: the scrum master, the product owner, and the development team. Scrum teams self-organize and have cross-functional capabilities. Cybersecurity governance and security engineering roles can add their expertise to a scrum team’s cross-functional capabilities.
Scrum is designed to work with smaller teams with no more than 10 members. If the number of members increases, multiple teams can work on the same project. The scrum of scrums is a technique to operate scrum at scale, with multiple teams working on the same product; it allows them to discuss progress on their interdependencies and focus on how to coordinate delivering software, especially on areas of overlap and integration.
The scrum framework has the following events:
- Sprint: The sprint is time-boxed project time. The sprint is when development work is done to create working software. Sprint planning, daily scrum, sprint review, and sprint retrospective are also part of the sprint. A sprint can range from one week to one month. Any changes to the sprint’s goals or conditions are avoided if possible. Sprints contain project risks of development to the time period of the sprint, which should not be more than one month.
- Sprint planning: Sprint planning is when the work is chosen, goals for the sprint are agreed upon by the team, and the team organizes to achieve the goals.
- Daily scrum: The daily scrum is the daily event of the sprint when the team reviews sprint goal progress and impediments and plans development until the next daily scrum.
- Sprint review: The sprint review is conducted at the end of the sprint and reconciles the new work done on the product backlog.
- Sprint retrospective: The sprint retrospective is conducted at the end of the sprint, and it is a time for the sprint team to conduct a critical but friendly self-analysis to find opportunities to improve.
Scrum also includes what it calls artifacts, which are the product backlog, sprint backlog, and the increment. The product backlog is the most comprehensive set of requirements for a product as possible at the time. The product backlog is an ordered list of product features and requirements. Ordering is based on the priority and the project risk that the feature presents. The sprint backlog consists of highest-priority/highest-risk features picked from the product backlog to deliver in the sprint as the increment.
The increment is the working software that is produced based on implementing the sprint backlog.
The definition of “done” is important in scrum because it is necessary for the whole team to have an understanding of the conditions required of a unit of working software to be present for it to be complete. Security engineering features, security controls, security testing and scanning activities, and similar security concerns can be added to the definition of “done” to establish baseline security requirements for working software delivery.
As an empirical framework, scrum accommodates security concerns well. As mentioned previously, the definition of “done” can be enhanced with requirements for security engineering, controls, scanning, and testing.
The scrum team should have a security-trained resource to maintain team awareness of security concerns and topics related to the product and to work with developers to mitigate risks present in the application by use of secure coding techniques and resources.
Sprint planning can include threat modeling and abuse case activities to identify threats and attackers. Security requirements are formed around these threats and attackers and the protection needs of the product. The development methodologies team can organize their efforts to produce secure code around these security requirements. Daily scrums can include monitoring the progress toward implementing secure code as a peer to the feature development. Sprint reviews can include security testing and scanning results review.
Extreme programmIng (xp)
Extreme programming (XP) is an agile software development methodologies framework that aims for high software quality and responsiveness to changing customer requirements. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development. XP was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project.
XP advocates the paired programming experience in which two programmers work together. XP asserts that the code quality improves beyond the additional cost of the paired programmer. XP focuses on frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. XP plays a “planning game” every iteration in which both release planning and iteration planning are conducted. XP relies on continuous integration and test-driven development to routinely produce working software.
XP is really about bringing efficiency in the coding process and providing customers with maximum value. XP can be summed up by its components, listed here:
- Planning games: Quickly determine the scope of the next iteration by taking into consideration business priorities and estimates.
- Small releases: Deliver quickly and early by having short iterations, first creating a minimum marketable feature and releasing new versions based on feedback.
- Metaphors: Guide development methodologies using a simple shared story to eliminate technical talk.
- Simple design: Have a just-enough design policy (i.e., the exact specifications just for that story). Extra complexity is removed once discovered.
- Testing: Develop test cases first, then code to test cases, and then automate test cases.
- Pair programming: Have two developers working on one story, where one drives and the other navigates, with them continuously switching role.
- Refactoring: Restructure complex/poor structured code without affecting behavior. This aims to remove duplication, simplify, or add flexibility.
- Collective code ownership: Anyone works on any code to avoid knowledge silos, which results in high-quality code.
- Continuous integration: Automate builds and tests so the system is checked every time a task is completed.
- 40-hour workweek: Have no overtime to enable long-term productivity and predictable results.
- On-site customer/whole team: Have a product owner/business/real-life user on the team to answer question.
- Coding standards: Strictly adhere to code standards with rules that emphasize communication through code.
XP’s emphasis on pair programming and extensive code review, as well as unit testing of all code, improves security outcomes by improving code quality. Defects are caught and fixed sooner. As a security practitioner, you should further improve security outcomes by partnering with the developers to educate them on common application security issues, sharing Open Web Application Security Project (OWASP) security guidelines for the languages and frameworks they use. An emphasis on code simplicity and clarity improves the understandability, which improves the software’s security.
XP strictly adheres to code standards with rules that emphasize communication through code. Code is more important than design in XP, and that may be a problem.
Good design improves quality and reduces bugs and security vulnerabilities in software applications.
However, in XP projects, the defect documentation is not always good. Lack of defect documentation may lead to the occurrence of similar bugs in the future.
