Agile approaches have been broadly characterized as incremental, straight forward, cooperative and adaptive [2]. A review and analysis of agile software methodologies by VTT Technical Research Center of Finland examined several different agile methodologies through five different lenses [1]. It is interesting to note that security was not a separate lens or considered as an aspect of one of the examined lenses.
6.2
The first version of DSDM was published in the mid nineties. DSDM has been describ
According to Stapleton, DSDM is based on the following nine principles:
4. ness purpose is the essential criterion for acceptance of deliverables
ring development are reversible 7. Requirements are base lined at a high level
ed throughout the lifecycle
and cooperative approach between all stakeholders is
None of the nine principles discussed above explicitly state the need to address security from the perspective of SCWAD. Stapleton goes on to define the five stages
2. Business study 3.
4.
5. Implementation [177].
“speeding up the development process through shortening the communication
However, there is nothing to indicate that the communications are about security rela M supports active involvement of the end-user throughout the dev ain, this is great. However, users are not explicitly being ask the security of the system, the effectiveness, or to test the
implem lution?
.1 Dynamic Systems Development Method (DSDM)
ed as a frame work of controls for Rapid Application Development (RAD).
1. Active user involvement
2. DSDM teams must be empowered to make decisions 3. The focus is on frequent delivery of products
Fitness for busi
5. Iterative and incremental development is necessary to converge on an accurate business solution
Systems design and build iteration
Even though the five original stages support individual ideas that are prominent in the SCWAD, they are not discussed from a security perspective. DSDM supports improved communication in organizations. In this case, DSDM describes it as
lines between all parties involved” [177].
ted matters. DSD elopment process. Ag
n ed to provide input o
ented security so
A DSDM.org white paper [63] does describe the implementation of the DSDM process in an organization slightly differently. They describe it as follows:
2. Feasibility Study
ject risk and details the working environment. The ‘Post Project’ phase reviews the project,
ons learned phase.
This phase looks at everything from the solution’s business fit, to measurable to management expectations.
ctions to first release, productionising, maintenance and death. The Extreme programming Web site
l release stage. The iteration stage is refined to include iteration planning, development and the latest version stages
Several individual XP tasks were analysed via SCWAD criteria. It should be noted 1. Pre-Project
3. Business Study
4. Identify Suitable Projects 5. Deliver DSDM Project
6. Post Project DSDM Promotion 7. Critical Success Factors [63].
The difference between the implementation approach and the actual methodology is really the level of execution. The implementation points discussed above are from a higher level of functioning than the actual methodology. The phases that exist, in some form, in the previous discussion of DSDM, include phases two, three and five.
The new phases include phases one, four, six and seven. It should be noted at this point that a later release of the DSDM methodology does add in the pre-project and post project phases [178]. The general idea behind the points mentioned above could be argued to take place in any development process. According to the white paper, the ‘Pre-Project’ phase identifies a specific problem that DSDM can address. The
‘Identify Suitable Projects’ phase selects a project, highlights the main pro
examines any applicable matrix, promotes the project’s successes, communicates this information out to the public, and starts looking for another project. The ‘Critical Success Factors’ phase is what is commonly referred to as a less
benefits of the solutions, to team satisfaction,
DSDM is very pro-business; however, it does not explicitly recognize security integration with the business needs in either approach discussed above. Thus, DSDM shows no explicit support for SCWAD criteria listed in Table 12.
6.2.2 eXtreme Programming (XP)
The XP life-cycle has six phases as described in Beck’s first book [17]. The individual cycles include: exploration, planning intera
presents a slightly different picture of the extreme programming project which is displayed in Figure 2 - eXtreme Programming Project. They have a release planning stage, an iteration stage, an acceptance stage and a smal
which are shown in Figure 3 - Iteration Refinement.
that at no point does Beck make direct reference to a security solution while discussing the individual tasks. In fact, Beck states that
“A system isn’t certifiably secure unless it has been built with a set of security principles in mind and has been audited by a security expert”[18].
Beck goes on to state that XP is compatible with security but that the security practices would have to be incorporated into the team’s daily activities. The inherent security compatibility of XP could be suggested to support the first criteria ‘Active organizational support for security in the Web development process’ through the implementation of pair programming. Two people coding amounts to on-the-spot code reviews. However, security was not explicitly stated. Another XP activity that
om a security perspective. One could argue that if you trust the software and security was a requirement of the system, then trust from a security perspective has been established on a ity to be truly integrated into a development life cycle, security needs to be explicitly stated. The results of the analysis indicate that XP does not show explicit support for the criteria listed in Table 12.
Figure 2 - eXtreme Programming Project
shows inherent support for one of the criteria is testing. The fifth criteria states that there are ‘Prompt, rigorous testing and evaluation’; testing is a major activity in XP.
XP promotes short development cycles along with early, frequent and automated testing of code.
It should be noted that Beck does mention trust but from a social perspective. He explains that the customers need to trust the software; developers need to trust progress reports and developers need to trust each other. He does not explicitly call out trust fr
n implicit level. However, for secur
Figure 3 - Iteration Refinement
6.2.3 Agile Development Summary
Again, there are many other agile development processes in existence that share common attributes such as short development cycles, parallel development, heavy
o four categories which consisted of functionalist, interpretive, radical humanist and radical structuralist.
sed of the business, social and computer environments and that licting interest. Discordance among these promise and negotiation.
nerational approaches focus on specific activities such as check list, standards, and structured step wise
me on the social and the
soc es’s soft
app rmation System (VIS) approach in
this