Based on the collective experiences of our staff, the JDM Methodology was put into practice to ensure that every project starts with a well defined course of action.
How does it work?
The JDM Methodology is a step-by-step process, with each step cycling into and building upon the other. Along the way, our clients can expect to work with dedicated team members who are familiar with the project and are available to answer questions and deliver results. These team members include business development managers, project managers, developers, designers, and quality assurance specialists.
Each team member lends his/her skills and strengths to the process flow. It is this approach that enables us to provide our clients with the tools necessary to ensure their success in this ever changing medium.
Our Experience will help you reap Benefits!
Our Methodology is light-weight to avoid cumbersome overheads, and flexible enough to be adapted to a wide range of scenarios. The JDM Development Methodology approach has been honed and refined over a number of years to reach where it is today. We have absorbed the best of SDLC and the real life practical solutions that actually work for our clients and are not just a “book case scenario”.
The Software Development Lifecycle (SDLC) can take many forms. Our pragmatic approach is designed to help us keep our processes lean and efficient. From the traditional 'waterfall' method all the way through to more rapid, iterative and even Agile approaches, we tailor a project plan to suit your needs and allow you to derive the most benefit from the engagement.
We typically begin a project by working closely with your business experts to ensure we clearly understand the business problems and what you are trying to achieve. We also recognize that business priorities and approaches may change over time, requiring a flexible approach to application design and development. Our skilled base of consultants has proven their ability to work in changing and uncertain environments.
Over the next sections you can read through and understand our approach towards application development. For more Information on our Application Development Methodology and Services, please contact us.
SDLC Resources
The software development life cycle (SDLC) is the entire process of formal, logical steps taken to develop a software product. The phases of SDLC can vary somewhat but generally include the following:
- conceptualization;
- requirements and cost/benefits analysis;
- detailed specification of the software requirements;
- software design;
- programming;
- testing;
- user and technical training;
- and finally, maintenance.
There are several methodologies or models that can be used to guide the software development lifecycle. Some of these include:
- the linear or waterfall model (which was the original SDLC method);
- rapid application development (RAD);
- joint application development (JAD);
- the prototyping model;
- the fountain model;
- the spiral model;
- build and fix;
- and synchronize-and-stabilize.
Usually a few models are combined into a hybrid methodology to make the best fit for the project. For a historical perspective as well as a distinction comparison view the section “What’s the difference?”
What’s the difference?
We should keep in mind that a methodology is a body of practices. It isn’t a script you can use in lieu of your critical thinking skills. JDM likes to think of the SDLC as a management roadmap. It is used on software development projects to help answer important questions that continually arise, such as: “How do we make this work?”, “What happens next?”, or even “What are we supposed to do now?” As such, the SDLC is an important management tool to help projects start right, work effectively, and finish satisfactorily.
The following chart outlines a number of SDLC options prevalent in the industry. They are listed in chronological order of when they generally came into practice.
Term |
Year |
Author / Attributor / Owner |
Waterfall |
1970 |
Winston W. Royce |
The Waterfall model has been widely attributed to an IEEE conference paper written by Winston W. Royce in 1970 titled “Managing the Development of Large Software Systems.” He never used the term “waterfall” but the paper did include a graphic image depicting progress through distinct project phases that somewhat resembled a waterfall. It is ironic that Royce himself described this model as one that “invites failure” and the paper also describes the need for iteration. |
Spiral |
1985 |
Barry Boehm |
The Spiral model was originally defined in a 1985 article written by Barry Boehm titled “A Spiral Model of Software Development and Enhancement.” This model uses iterations, lasting from months to years, which provide succeeding layers of functionality. Boehm’s original paper describes this approach as being risk-driven, as opposed to document-driven or code-driven. |
RUP |
1998 |
IBM/Rational |
RUP is an acronym that stands for the Rational Unified Process originally developed by Rational Software, now a part of IBM. RUP describes itself as a process framework and is designed to be adapted to the needs of individual projects. RUP had its origins in the Rational Approach and the Rational Objectory Process with major contributions by Barry Boehm, Ken Hartman, and Ivar Jacobson. By the time the term RUP was first used, the framework was on version 5.0 and the chief architect was Philippe Krutchen.
The RUP framework divides a project into the four phases of Inception, Elaboration, Construction, and Transition with spiraled iterations inside of the last three phases.
Web resource: www.Rational.com |
The remaining methodologies fall into the Agile category. |
Scrum |
1986
1993
1995 |
Takeuchi & Nonaka
Sutherland, Scumniotales, McKenna
Ken Schwaber |
Scrum was originally described by Takeuchi & Nonaka in a 1986 article in the Harvard Business Review titled The New Product Development Game. Scrum is named after the rugby term, which is a way to restart a game after the ball goes out of play or after an accidental infringement.
In 1993 Jeff Sutherland, John Scumniotales, and Jeff McKenna further defined the scrum approach while at Easel Corporation. In 1995 Ken Schwaber formalized the scrum definition. In 2004 he authored the book Agile Project Management With Scrum.
Among other things, scrum emphasizes close interaction with the customer, daily team status discussion, and working from a dynamic backlog of work to be completed.
Web resource: www.scrumAlliance.org |
Extreme Programming (XP) |
1996 |
Kent Beck |
Extreme Programming or XP was developed by Kent Beck, Ward Cunningham, and Ron Jeffries while at Chrysler Corporation in 1996. In 1999 Kent Beck wrote a book on the subject titled Extreme Programming Explained.
XP was the first Agile methodology that became widely popular.
XP strives for adaptability amidst changing requirements. A primary goal is to lower the cost of change. This is accomplished by following a specific set of 12 practices designed to encourage certain values. Among the most discussed practices are pair programming, test driven development, and continuous integration.
Web resource: www.extremeProgramming.org |
Feature Driven Development (FDD) |
1997 |
Jeff De Luca |
Feature Driven Development (FDD) was developed by Jeff De Luca in 1997 while working in Singapore. As its name implies, FDD uses a feature list as a means of organizing work into iterative design and build activities.
FDD emphasizes object modeling, inspections, and project organization around discrete features.
Web resource: www.featureDrivenDevelopment.com |
Adaptive Software Development |
2000 |
Jim Highsmith |
Adaptive Software Development is an Agile approach developed by Jim Highsmith. It has its origins in the “rapid application development”: work done by James Martin and others in the 80s and 90s.
Jim Highsmith authored a book in 2000 titled Adaptive Software Development: A Collaborative Approach to Managing Complex Systems.
ASD uses repeating cycles composed of speculate, collaborate, and learn.
Web resource: www.adaptivesd.com |
Crystal Clear |
2004 |
Alistair Cockburn |
Crystal Clear was developed by Alistair Cockburn, who authored a book in 2004 titled Crystal Clear: A Human-Powered Methodology for Small Teams. As the book title implies, it is designed for small teams of up to 8 developers working in close cooperation and ideally co-located.
Crystal Clear strives to be people oriented, with emphasis on frequent code delivery, reflective improvement, and osmotic communication. |
|
|
|
|