The Software Development Life Cycle

Before delving into the descriptions for each of the methodologies, it is important to understand the context of the problem that these process definitions are intended to solve. The software development life cycle (SDLC) is a standard definition of the phases involved in any software development project. Each methodology uses its own vocabulary to describe the following phases, but they are all consistent in purpose:

  • Concept Phase: The concept phase is used to initially evaluate the size and scope of a potential software development task or project. This phase usually entails the definition of the problem the software product is to solve and the criteria for how to determine the success of the delivery.

  • Specification Phase: This phase is used to spell out the detailed requirements for any new software development. This phase is used by the technology teams to intimately understand the nuances of the business processes and problems they intend to solve with the new product.

  • Design Phase: The design phase is focused on mainly by the technology team to evaluate and plan the construction phase of the project. This phase is of particular interest to the enterprise architect who wants to make sure that technical design decisions for a project are in line with the direction of the entire enterprise architecture.

  • Construction Phase: The construction phase of a project is where all the magic in code development occurs, from the definition of development environments to coding procedures to the compilation and construction of all the subcomponents for a project.

  • Quality Assurance Phase: This phase is identified to manage the quality of the project prior to the launch of the product. Quality assurance encompasses multiple perspectives, from end-user usability, to requirements satisfaction, and overall system performance.

  • Deployment Phase: The deployment phase of a project encompasses the launch and maintenance of a system. The majority of an application's life cycle is spent in deployment.

Anyone who has been responsible for the delivery of a software development project knows the two main criteria used to define successful delivery of a software project. The first is cost. The cost associated with a project is the allocated budget that is expected to be used during the phases of development. The second is the schedule. The schedule determines the calendar dates that are defined to track the progress of a project. Across the industry, projects have the bad reputation of usually running over budget and schedule.

Why is the practice of software development so complex? Why are there so many failed projects? In general, the factors that drive the success of a software development project are defined into three major categories of influence:

  • Business Drivers: The business drivers are the conditions for which a software development project is intended. Business drivers are many and varied, but they are all generally aligned with either cost cutting and the bottom line or revenue generating and top-line solutions. Business drivers can be fickle where the conditions of business problems can change faster than technology can keep up.

  • People: People will always be a complicating factor in software development. Different organizations have various roles with different personalities and varying levels of experience. The players involved in a project's delivery are a major factor in the complexity of a software project.

  • Technology: Technology is a radically evolving facet of software development. Tools, APIs, standards, and products are all constantly evolving. In general, software product companies plan to release new versions of their software on a semiannual, if not quarterly, basis.

Methodologies are used to manage the complex influence of these factors in the development of a software product. First, in terms of business drivers, each methodology defines detailed means to understand the scope and horizon of effectiveness for business drivers. Second, in terms of people, each methodology defines in detail the exact roles and responsibilities for each of the players involved in the delivery of a project. Finally, in terms of technology, each methodology describes short-term iterative approaches to technology design and construction.

Variations on the SDLC

Recently, new variations of software delivery problems have gone beyond the three standard influences that affect the delivery of a software project. To understand the scope of these variations, it is important to understand how each of the methodologies described can encompass complexities caused by the following:

  • SDLC for Offshore Development: In any enterprise's application development context, the use of offshore development has become more and more prevalent. The question is how does any methodology also encompass and mitigate against the complexity of the players in a project in different cultural, language, and physical contexts?

  • SDLC for Maintenance: IT organizations are structured in various ways to handle the development and maintenance of applications in an enterprise. Many times, the people responsible for the maintenance of an application are not the people who actually develop the application. Each methodology can be judged on its flexibility to both describe the process for delivery technology and the process for maintaining it over time.

  • SDLC for Package Implementations: Even though a company can standardize on methodologies to use in its software development life cycles, the integration of third-party products sometimes requires the incorporation of that product's particular implementation procedures.

The following sections describe various approaches to managing software development projects. Each of the methodologies takes a different approach to managing risk, tracking progress, and delivering for success, but they are all similar in that they look for to define the rules for successful software delivery.



Practical Guide to Enterprise Architecture, A
A Practical Guide to Enterprise Architecture
ISBN: 0131412752
EAN: 2147483647
Year: 2005
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net