Slepi

SDLC (System Development Life Cycle), just as the name implies, is defined as the process (as a whole) of developing system or software to meet certain requirements. It covers many activities; starts from understanding why the system should be built, studying the project feasibility, analyzing problems, choosing the system design and architecture, implementing and testing it, up to delivering the system as product to the user. SDLC is a process of gradual refinement, meaning that it is done through several development phases. Each phase continues and refines what’s done in the previous phase. Commonly known development phases in SDLC are:

• Planning. It is the process of understanding why the system should be built and defining its requirements. It also includes feasibility study from several different perspectives, technical, economic, and organization feasibility aspects.
• Analysis. This phase includes activities such as problems identifying and analysis, and even predicting potential problems that may arise in the future regarding the system. The deliverables / products of this phase will drive how the system will be built and guide the developers’ works.
• Design. System analysis leads to design decision, which exactly determines how the system operates in terms of process, data, hardware, network infrastructures, user interface, and other important factors in the system environment.
• Implementation. This is probably the most resource-, cost-, and time-consuming phase of all. This is when the system is actually built, tested, and finally installed. It also includes activities such as user training and system maintenance. Some experts like to separate them into different phases Deployment and Maintenance. However the four phases are the most commonly known and accepted steps.

SDLC tries to achieve high quality system that meets or exceeds the requirements. Many methodologies have been developed and introduced in order to implement SDLC; some of them also try to improve other (previously) known methodology. Although each method follows certain different techniques and steps, they are all must go into the same development phases described above. There are many system development methods known today, but most of them basically are extended from three main methodologies which are Structured Design, RAD (Rapid Application Development), and Object-oriented Analysis and Design.

Structured Design

This method follows a step-by-step approach which moves logically from one phase to the next. The works done in each phase need to be approved by the project sponsor (this is usually the customer or the business analyst in an organization) before it can proceed to the next development phase. The Waterfall development methodology can be classified as this kind of methodology. This rigor and inflexible manner make this methodology vulnerable to any business changes that happen while the development is still on the way, as it is extremely difficult to go backwards. This may require repeating the whole development process from the start and throw away all that’s been done, and in the worst case it could cause the change of project contract or agreement with the customer.

There are two approaches in developing system using this methodology, process-centered and data-centered approaches. Process-centered approach attempts to get the works done mainly from the perspective of the processes that exist in the operation of the system, which will likely result in system that constructed by process-oriented components. On the other hand, the data-centered approach concentrates on the data used by and involved in the system.

Structured design methodology has some advantages in that the rigor manner of this method forces the developers (analyst and his/her team) to well identify and understand system requirements long time before the implementation phase begins. At least it should have been approved by the sponsor before the developers start coding any programs.

The lack of ability to go backwards of the development phases makes this methodology unaccommodateable to business process changes as the project proceeds. Projects done using this methodology take a long time until users receive some deliverables because usually the system being built can not be presented until it is completely done at the end of the implementation phase.

Figure 1. Structured Design Methodology

RAD (Rapid Application Development)

RAD methodology enters to overcome the weaknesses of Structured Design method. RAD-based development tries to adjust the SDLC phases to have some part of the system (most likely the core function of the system) developed quickly to be delivered to the users. Certain types of RAD method also try to be adaptive to possible changes in the business process by concurrently perform all development phases at (roughly) the same time, like those manifested in the Prototyping RAD and Agile Development Methodology.

RAD methodology introduced the use of advance development tools like code generators and the visual fourth-generation (4G) programming languages such as Microsoft Visual Basic and Borland Delphi. The use of these tools speed up the development process and in some degree produces higher quality of codes. However as the system can be delivered quickly, users tend to change their expectations of what the system can do, thus the requirements tend to change and expand.

There are three categories of RAD:

1. Phased Development
   This method breaks the requirements into a series of versions, based on which several versions of system will be built sequentially, being the most fundamental and important functions bundled in the first version. Sequentially here means that the next version development will begin only after the preceding version has been approved and implemented. Each version has its own Analysis-Design-Implementation phases (in a smaller scale compared to the overall system). All of these versions will later be tailored to form a complete system that meets the requirements.This method delivers useful system very quickly to users, though it doesn’t cover all functions just yet. And as the system will be built based on many sequential versions, it is very critical to identify important and fundamental functions to be included in the first version, an in-depth initial analysis of the system is needed.

   

   Figure 2. Phased Development Methodology

2. Prototyping
   This methodology used usually when the business process is likely to be changed as the project proceeds or when the project sponsor has little idea of what system to be built. The Analysis, Design, and Implementation phases performed concurrently and on each cycle resulting in a system prototype that will be reviewed by the project sponsor. The cycle repeated continually based on the sponsor comments until the prototype successfully meets the requirements. The last prototype will then be called the system.Prototyping development needs only initial basic analysis and design, but as the result important system functions may not be recognized until somewhere in the middle of project timeline. Thus there is a possibility to alter the initial design decision and start all over again from the beginning. It can delivers system quickly to users, though it not exactly meets the requirements.

   

   Figure 3. Prototyping Methodology

3. Throw-away Prototyping
   Throw-away Prototyping is similar to the Prototyping method in that it also develops a prototype. But the throw-away prototype is rather presentational only, the prototype actually does nothing. It is intended to help users visualize the system being built. Based on the user’s comments, the next prototype continuously built until it can visualize the real working system. The next step would be implementing the real system. This throw-away prototype is also called dummy (mock-up) prototype.It is best if possible to do a thorough initial analysis before the developers start working on the first dummy prototype, as the dummy needs to contain enough details about the real system. This method doesn’t deliver incomplete systems within the project timeline like prototyping method, but in the end it delivers the complete system very quickly. It generally has shorter project timeline compared to other methods, because building dummies is considered easier and less time-consuming than building working prototypes.

   

   Figure 4. Throw-away Prototyping Methodology

Object-oriented Analysis and Design

The Object-oriented methodology developed based on the lack of synergy between process-centered and data-centered approaches in SDLC. Decomposition of system into a set of process (process centric) or data (data centric) can not be easily obtained, as both aspects are closely related one another. It is difficult to develop system by primarily focusing only to one aspect. As result, the system produced tends to be extendable only in one world. A process centric developed system can not be easily extended when there are changes in type of data in the system. This kind of problems also exists in the data centric developed system.

OO methodology decomposes problems into objects. Objects are considered part of the system that contain both process and data, an object may do some activities/processes (mapped as object methods), an object may also have states (mapped as object attributes). This way, developers will focus on the entity in the system that actually does processes and carries data, rather than focus primarily only to one aspect. OO-based system development extensively uses a tool called UML (Unified Modeling Language), which is a set of standard in diagramming and modeling techniques invented by three OO champions, Grady Booch, Ivar Jacobson, and James Rumbaugh, when they worked together in Rational Software. In 1997 UML proposed to and accepted by the Object Management Group (OMG) as a standard diagramming notation in object-oriented system development.

An OO approaches in system development must be:

• Use-case Drive
  This means that use-case is the primary modeling tool to define system behavior. Use-cases describe how the users of the system interact with the system to perform activity. And as a use-case focuses only to one activity at a time, it is inherently simple.
• Architecture Centric
  The term architecture centric gives a high level view of the system being developed. The software architecture chosen for the system should drive the specification, construction, and documentation of the system itself. The system architecture must support three views of the system:
  • Functional view
    Describes system behavior from the perspective of users of the system. Use-case diagrams used to depict this functional view.
  • Static view
    Describes the structure of the system in terms of classes, methods, attributes, and relationships of objects in the system. This view is depicted using CRC (Class Responsibility Collaboration) cards, as well using class and object diagrams.
  • Dynamic view
    Describes the internal system behavior in terms of object communications and change of states. UML tools used to depict this view are sequence diagrams, collaboration diagrams, and object state-charts.
• Iterative and Incremental
  Iterative and Incremental paradigm means that each iteration of the system development must bring the system closer to the requirements. As SDLC is a gradual process, the UML diagrams used in OO-based development moves from a conceptual and abstract thing in the analysis and design phase to become more and more detail in the implementation phase.