This article explores the need for Software Development Life-Cycles as Software Engineering Methodologies, the genesis and structure of PDLC, and its impact in the overall business of on-demand software organizations. It attempts to demonstrate that SDLC processes and activities can be arranged in a flexible structure so as to allow constant improvement and re-engineering within a product development organization.

Content Flow:
1. Software and customer Focus
2. Software Development LifeCycles
3. The challenge at iEmployee and birth of PDLC
4. PDLC Broken-down (covered in the following issue)
5.  Conclusion (covered in the following issue)

1. Software and customer Focus
Like any other product, software products are oriented towards the customer.
The 80’s saw Customer Satisfaction as the buzzword in the industrial domain, followed by Customer Delight in the 90’s, and now Customer Ecstasy has taken hold in the new millennium.
As a result, software development in the last decade, along with all other industries, has been shaped by the mantra; Customer is the King. The rise of the Internet and the dot-com boom emphasized Speed-to-Market and Company-Growth as competitive business factors.
With these prevailing trends, rapidly-changing requirements and shorter product life-cycles became the order of the day and were often incompatible with traditional methods of software development.

2. Software Development Life Cycles

To address these needs, various processes were proposed in the form of SDLCs (Software Development Life-Cycles).

To address these needs, various processes were proposed in the form of SDLCs (Software Development Life-Cycles).

While quite a few of these SDLCs were developed from scratch, the majority evolved from their legacy bases to meet the continuously changing business trends.

As Linus Torvalds, the man who invented Linux Kernel, cleverly pointed out: No major software project that has been successful in a general marketplace (as opposed to niches) has ever gone through those nice lifecycles they tell you about in Computer Science classes.

In actuality, many companies invented their own models to suit their respective businesses, and most primarily based their models on Agile Software Development Processes, with an agenda to achieve Customer Ecstasy.

The Agile process framework is based on Iterative Development, but goes in a lighter, more people-centric direction. It uses feedback, rather than planning, as the primary control mechanism, driven by regular testing and the release of evolving software.
Agile processes are more efficient, using less programmer time to produce functional, higher quality software, but have a categorical handicap from a business angle: they do not provide long-term planning capability. For software development in a product-based domain, lack of long-term planning can be disastrous.

With large number of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management is proving difficult.
Advent of on-demand software product solutions reinforces this belief, and consequently methodologies must change with respect to long-term planning.

3. The challenges at iEmployee and the birth of PDLC

While project failure can be caused by a combination of several factors, no single factor can be universally attributed.
A PDLC, therefore, tries to work on those initial stages of inception and elaboration, where ambiguity gets in and introduces causes of project failure.
Since, on-demand software is a new model of software delivery, no single existing process framework has been found effective for implementation.
As a result, on-demand software companies like iEmployee established their own SDLC framework with the paradigm that the Product is the primary customer. This new set of framework has been termed as PDLC (Product Development Lifecycle).

PDLC is a hybrid process framework based on Rational Unified Processes (RUP) and the product paradigm

Apart from RUP, PDLC adopts the benefits of Agile Methods, Test Driven Development Process and Waterfall Process, emphasizing on the needs of the product as opposed to those of individual clients. (See Figure 1: PDLC Origins)
While delivering requirements quickly is a necessity, improper planning and management can be catastrophic to the product and clients.
Having the flexibility to change the application faster in an on-demand software environment as compared to other models, the dynamic business environment forces the sales and support teams to continuously keep pace with competition and the increasing needs of clients, by introducing and accepting continuous modifications to the product.
Moreover, with the organization’s need to keep pace with the competition, the product is under constant enhancement. This brings in a variety and large number of changes in the application.
Consequently, at any point in time, there are multiple projects being conceptualized and running, simultaneously.

Some of these projects can be categorized into project-types such as Custom Changes (small changes for a single client or a single entity using the product), Product Enhancements (large changes for all clients), Interfaces (data exchange with third party applications) and New Modules (new features or a set of new functionality).

Each project-type forces the project management teams to use different approaches to manage Project Definition, Design Needs, Coding Requirements, Team Specialization, Deployment, Performance, Security and Quality Assurance.
More about the PDLC Structure and its impact on software product development activities shall be covered in the next issue.

Akash Dave