Six Software Development Frameworks

Introduction and Background

In software development, there are a variety of software development frameworks available for Innovative Systems’ consideration.  These frameworks abide by a specific life cycle to make sure of the software development’s success.

 

Waterfall Model

The waterfall model is one type of software development framework.  This was the first model introduced and pursued generally in “software engineering” since 1970 states Parekh (2005).  In the waterfall model, the entire software development process is split into distinct phases.  These phases are: requirements specification, design, implementation, integration, testing, installation and maintenance.  The development advances in sequence through these phases.  Just like in a waterfall, the movement “flows” downward from one phase to another (TechRepublic, 2006).  According to Steele and Swiler (2002), the output of a certain phase serves as the input for the next phase.  In this particular framework, you are only supposed to transfer to a phase when the prior phase is accomplished.  Between these phases, there is no overlap or bouncing back and forth notes Select Business Solutions (2010).

The waterfall model can be classified as a systems development life cycle.  It involves a phased sequence of activities.  According to Bista (2010), there are distinct goals in every phase of development.  This model starts with the requirements analysis of the system.  Then, this leads to the system’s release and later maintenance.

 

 

Dynamic system development method (DSDM)

Dynamic system development method (DSDM) is another software development framework which develops software systems dynamically through the use of prototypes.  The framework is basically a variant of the rapid application development method (RAD) process.  According to Freetutes.com (2010), its aim is to produce systems according to time and budget while accommodating for revisions in the requirements during system development.  This is practical for systems that call for to be developed in the shortest amount of time and where the goals cannot be stalled at the beginning of the application development.  The following phases are part of DSDM:  feasibility study, business study, functional model iteration, design and build iteration and implementation.

 

DSDM could be categorized as a mold of the systems development life cycle because it is an in-depth plan of how to build, develop, implement and close the project.  The whole plan outlines how the system is born, raised and later retired from its purpose.

 

The waterfall model is a non-iterative approach while DSDM is an incremental and iterative approach.  One element of the waterfall model is that the phases cannot start unless the previous phase is completed.  This software development model has to follow the phases in sequence (Select Business Solutions, 2010).  On the other hand, DSDM is the opposite in regards to this.  DSDM allows the project to go back to preceding phases in order improve it and the final product.  When the requirements are continually changing in a project, the DSDM is quick to respond whereas the waterfall model is not appropriate (Freetutes.com, 2010).  Both of these frameworks, waterfall model and DSDM, are classified as a systems development life cycle.

 

Agile Software Development

With Agile Software Development, end user involvement is very critical to the project’s success. In many cases due to the way that Agile development works, this is not possible. However in these cases, you will want to appoint senior-level end users which will represent the majority of the end users that you are trying to satisfy. This way, the smaller projects are prioritized according to what the end users need the most. In order to provide the quick results that are requested of a development team in an agile environment, the team needs to have decision making abilities. In order to accomplish this, you will again want to insure that they have direct contact with the senior-level end users on a day-to- day basis. Where most project management/software development methods try and stake down all requirements upfront with a timeline, the Agile approaches this much differently. The agile method of development works on the idea that the end users do not know what they want until they begin to see, and use, the end product. Based on this philosophy, the developers try and get a base model out to the end users and then the end user evolves the project as they see the need. This provides an end user with a product that they will use, not a product that has extreme functionality but will never be used (Waters, 2007).

 

With Agile, we want to capture the system requirements at a high level only. This philosophy follows where we last left off in that with Agile, we want to get the minimum requirements the end users want and need. Then, provide them with that one part completed very well. From there, we will focus on the next part or activity. Of course in order to have a good and stable end product, we still need to have an idea of the end target for the project and take every end user request as a direction to lead us towards the end goal. The overall concept of develop small, incremental releases and iterate is one of the main focuses that we are trying to accomplish by using the agile methodology. By doing this, we are reducing risk, increasing value, being more flexible, and providing better cost management. If the project runs out of money and management kills the project, the end users are not left with nothing. In fact, they may be left with a very good product that they may use and the project may be able to be returned to once funds again become available. In other words, with Agile we will want to insure that we complete each feature before we move on to the next enhancement. As such, testing will be completed throughout the full life of the project versus at the tail end of the project once all aspects of the project are complete. Again, communication and collaboration between all stakeholders is essential for this philosophy to work and work well (Waters, 2007).

 

When comparing Agile to the Waterfall approach, you will find that both use Use Cases and UML diagrams for analysis and design. DSDM is often considered the original agile development method. SCRUM is another agile development method that focuses on managing tasks/activities within a team versus individual developers. XP can also be considered an agile method of development. However, it focuses heavily on the software developments process and is shooting for a high quality en product (Waters, 2007).

 

The Agile Software Development methodology is a member of the System Development Life Cycle as there is a definitive process of planning, analyzing, designing and implementing each phase of the program as it is developed. Again, the major difference with this framework and other SDLC methods is that this process reiterates many times before the project is ruled complete versus only once. Although Agile is considered a member of the System Development Life Cycle family of frameworks, this should be very clear at this point that many of the concepts could be used with the project life cycle as well. For instance if providing an end user with video conferencing solution, the project manger may want to focus on the 80/20 rule that often focuses on with the Agile method. With the 80/20 rule, we take the philosophy that 80% of the results come from 20% of the efforts. So, we want to focus on the 20% of the efforts that are going to matter. We may want to only implement the pieces of the video conferencing system that are going to matter most to the end users and then grow the project from there as the company adopts the new technology.

 

Rational Unified Process (RUP)

As different projects have different process needs, the factors that determine these needs usually put the processes into either a formal or an agile process. A Rational Unified Process (RUP) is a Software engineering Process that provides a disciplined approach t software development. Even though this process does rely on some measure of a formal process it does work better with an agile process. This particular process does have the capability to automate certain large portions of the process. RUP acts as a guide when utilizing the unified modeling language (UML). UML does enable the clear communication of architectures requirements, and designs. And as such it can act as a systems life cycle or as a product life cycle in that it can easily handle larger projects which would be either a system (Mainframe), or as a product, (Office 2010). As stated in the first sentence about there being different needs for the various projects, RUP can be easily configured to match many different projects. While each software lifecycles can be broken into different cycles that work of new generations of the product. And each cycle being broken into an iteration (or phase), being; Inception (initiation), Elaboration (planning), Construction (execution), and Transition, (Closing).

 

The open unified process (OpenUP) uses many of the essential characteristics of RUP, but does not provide guidance on many of the topics that many large projects may work with, that RUP does work with. Topics such as: compliance or contractual situations, large teams, mission critical applications, etcetera. OpenUP is a minimally sufficient process where only the fundamental content is included, (Balduino, 2007). Even though OpenUP is an agile process, it is considered lightweight by comparison to RUP, it does apply iterative and incremental approaches within a structured lifecycle that uses cases, scenarios, risk management and architecture type approach that drives development, (Balduino, 2007).

The four core principles of OpenUP are:

  1. Collaborating in order to align the interests and sharing understanding.
  2. Balance an y competing priorities in order to increase the stakeholders value.
  3. Focusing on the architecture early in order to minimize any risks and to organize development.
  4. Evolve in order to promote activities that obtain feedback from the stakeholders in order to improve the development and to give the stakeholders value.

 

The activities would be more in line with a product lifecycle in that it does what it can to promote the project/product by promoting a positive environment.

 

 

Extreme programming

Extreme programming is a type of agile process that is based on values of simplicity, communication, feedback and courage. It was first introduced in the 1990’s at DeimlerChrysler by Mr. Kent Breck in an attempt to find a better way to develop software, (Copeland, 2001). Originally designed to be flexible enough to freely communicate with the customer and to have the coding of the software change (if needed), to fit with the possibility of the changing requirements. One downside to this is the potential for project creep, which can be disastrous to the budget and schedules. Two forms of planning would be a release planning whereas the customer would state what their requirements are and the developers would estimate what the difficulty would be. Another form would be iteration planning where the developers would be given updated direction every two weeks or so with a tested usable segment ready at the end of that time so that it may test by the customer. Extreme programming has been developed as a lightweight development process, where coding has a continuous integration that takes place from every few hours to approximately a day and then tested, if the test fails, only the unworkable portion is removed and fixed (or discarded, then redone). The way that this process is setup, it has the appearance o being more “flowing” than other methods, for more of a continuous development.

 

Rapid Application Design (RAD)

There many approaches that the organization may explore when selecting software development frameworks these methods range from spiral models to waterfall models. The development types may include processes such as adaptive software development when a process follows an adaptive approach providing more freedom; or when collaboration is needed may warrant an agile development approach. Utilizing processes such as the RAD lifecycle model uses an approach in which developers are working with an evolving prototype; this lifecycle involves user collaboration which produces systems quickly without sacrificing quality. Rapid Application Development (RAD) methodology allows developers to develop systems strategically in a cost effective manner while preserving quality utilizing proven development techniques. This application process allows the development cycle to be expedited saving valuable resources. Rapid Application Development tools such as; computer aided software engineering (CASE), JRP (joint requirement planning), and JAD (joint application design) to conduct prototyping and code generation (Schwalbe, 2007). The rapid application development process is an example of a predictive lifecycle meaning that the scope of the project can be seen or articulated. This particular lifecycle model is part of a framework known as the system development lifecycle. However, the system development life cycle has elements that are quite similar to project lifecycle development which include; the assigning of project managers to oversee the entire development process and adjusting scope requirements to satisfy time and cost. There are also conditions that may cause project managers to modify traditional project management methods depending on the particular product lifecycle. The RAD lifecycle model is an example of how elements differ from traditional project lifecycles; mainly because a RAD lifecycle may have an existing functioning product that may warrant additional features and upgrades in addition to spending an enormous amount of time on requirement specifications. There are software development frameworks such as Adaptive Software Development model that provides the functionality requirements that is specified by the stakeholders or business group as the needs are discovered in a more liberal approach. The Adaptive Software Development model follows an adaptive approach because requirements cannot be expressed in a clear manner (Schwalbe). In comparisons with other models like the project lifecycle the scope of a project utilizing the Adaptive model differs because its scope can’t be clearly defined initially versus a project lifecycle which the project scope is set initially allowing stakeholders to have clearly defined vision of the type of product or process they will receive. The key aspects of this approach are that projects are component based and mission driven utilizing time based cycles to meet target dates. These types of projects are usually risk versus scope driven as found within a project lifecycle framework.

 

Conclusions

Overall, the success of the project will depend on how directly Innovative Systems abides by a software development framework.  Innovative systems must be aware that certain software development frameworks will work better than the other frameworks in managing a software development project.  If Innovative Systems correctly executes these frameworks, considerable time and cost savings can be expected. There is not any one hit wonder to software development that will work in every instance. Real results come from project managers with a lot of experience and skill, have knowledge of a lot of different techniques and know when each technique is most appropriate in the right environment to achieve the desired results. Typically, the correct solution is a combination of many different techniques.

 

 

 

 

 

References

Bista, B. (2010).  The Waterfall Model: IT Project Management Solutions. Retrieved June 30,

2010, from http://www.buzzle.com/articles/waterfall-model-it-project-management-solutions.html

Freetutes.com. (2010). Dynamic System Development Method (DSDM). Retrieved June 30,

2010, from http://www.freetutes.com/systemanalysis/sa2-dynamic-system-development-method.html

Parekh, N. (2005). The Waterfall Model Explained. Retrieved June 30, 2010, from

http://www.buzzle.com/editorials/1-5-2005-63768.asp

Select Business Solutions. (2010). What is the Waterfall Model? Retrieved June 30, 2010, from

http://www.selectbs.com/adt/analysis-and-design/what-is-the-waterfall-model

Steele, J. & Swiler. N. (2002). The Software Development Life Cycle (SDLC).  Retrieved June

30, 2010, from http://www.elucidata.com/refs/sdlc.pdf

TechRepublic. (2006). Understanding the Pros and Cons of the Waterfall Model of Software

Development. Retrieved June 30, 2010, from http://articles.techrepublic.com.com/5100-

10878_11-6118423.html

Waters, K. (2007). 10 key principles of agile software development. Retrieved July

1, 2010,from http://www.agile-software-development.com/2007/02/10-things-you-need-to-know-about-agile.html

Kerzner, H. (2009), Project Management: A systems approach to planning, scheduling, and

controlling, (Tenth ed.), Hoboken, N. J., John Wiley & Sons, Inc.

Project Management Institute (2008), A Guide to the Project Management Body of Knowledge

(PMBOK Guide), (Fourth ed.), Newtown Square, PA, Project Management Institute

Project Management Institute (2009), Q & A s for the PMBOK Guide Fourth Edition, Newtown

Square, PA, Project Management Institute

Schwalbe, K. (2007), Information Technology Project Management, (Fifth ed.), Boston, MA,

Thomson Course Technology

Gido, J. & Clements, J. (2006), Successful Project Management, (Third ed.) Mason, OH,

IBM (1998), (rev. 2001), Rational Unified Process: Best Practices for Software Development

Teams, retrieved on 06/29/10 from http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

Balduino, R. (2007), Introduction to OpenUP (Open Unified Process), retrieved on 06/29/10

from http://www.eclipse.org/epf/general/OpenUP.pdf

Balduino, R. (2006?), Basic Unified Process: A Process for Small and Agile Projects, retrieved

on 06/28/10 from

http://www.eclipse.org/proposals/beacon/Basic%20Unified%20Process.pdf

Wells, D. (2009), Extreme Programming: A Gentle Introduction, retrieved on 06/29/10 from

http://www.extremeprogramming.org/

Wells, D. (2009), The Rules of Extreme Programming, retrieved on 06/29/10 from

http://www.extremeprogramming.org/rules.html

Copeland, L. (2001), Extreme Programming, retrieved on 06/30/10 from http://www.computerworld.com/s/article/66192/Extreme_Programming?taxonomyId=063

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s