Systems Development Model

PROCESS MODELS

The System Development Life Cycle (SDLC) process applies to information system development projects ensuring that all functional and user requirements and agency strategic goals and objectives are met. The SDLC provides a structured and standardized process for all phases of any system development effort. These phases track the development of a system through several development stages from feasibility analysis, system planning and concept development; to acquisition and requirements definition; design; development; integration and testing; deployment and acceptance; though deployment and production; and finally to system retirement.

The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

Various Systems Development Life Cycle methodologies have been developed to guide the processes involved, and these are the Software Process Models.

According to Kerem Kosaner (2008), Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could is done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.

A software process model is a development strategy that incorporates the development process, methods and tools used to design software. It is chosen based on the nature of the software and the methods and tools used in development. It often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

These software models are classified as the traditional process models and the process models in recent times. There are many to mention software process models. So let me identify and discuss at least three of the systems development model.

The waterfall modelThe waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.

Waterfall model phases

Requirements analysis and definition

What is a requirement?

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. This is inevitable as requirements may serve a dual function and it may be the basis for a bid for a contract - therefore must be open to interpretation. Also may be the basis for the contract itself - therefore must be defined in detail. Both these statements may be called as a requirement.

Requirements definition: A statement in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers

Requirements specification: A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor

Software specification: A detailed software description which can serve as a basis for a design or implementation. Written for developers

In this phase, establishing what the customer requires from a software system must the main concern. It is necessary to remember first the requirements needed in a systems development life cycle. The problem is specified along with the desired service objectives (goals) and the constraints are being identified.

System and software design

In System Analysis and Design phase, the whole software development process, the overall software structure and its outlay are defined. In case of the client/server processing technology, the number of tiers required for the package architecture, the database design, the data structure design etc are all defined in this phase. After designing part a software development model is created. Analysis and Design are very important in the whole development cycle process. Any fault in the design phase could be very expensive to solve in the software development process. In this phase, the logical system of the product is developed. Software Requirement Analysis is also known as feasibility study. In this requirement analysis phase, the development team visits the customer and studies their system requirement. They examine the need for possible software automation in the given software system. After feasibility study, the development team provides a document that holds the different specific recommendations for the candidate system. It also consists of personnel assignments, costs of the system, project schedule and target dates.

The requirements analysis and information gathering process is intensified and focused specially on software. To understand what type of the programs to be built, the system analyst must study the information domain for the software as well as understand required function, behaviour, performance and interfacing. The main purpose of requirement analysis phase is to find the need and to define the problem that needs to be solved.

In the system and software design phase, the system specifications are translated into a software representation. The software engineer at this stage is concerned with Data structure, Software architecture, Algorithmic detail and Interface representations.

The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream. It is the level of deriving a solution which satisfies software requirements.

Implementation and unit testing

In the implementation and testing phase stage the designs are translated into the software domain into a detailed documentation from the design phase can significantly reduce the coding effort. Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification. After code generation phase the software program testing begins. Different testing methods are available to detect the bugs that were committed during the previous phases. A number of testing tools and methods are already available for testing purpose.

Integration and system testing

In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer [Deliverable – The software product is delivered to the. In integration and system testing, the design must be decoded into a machine-readable form. If the design of software product is done in a detailed manner, code generation can be achieved without much complication. For generation of code, Programming tools like Compilers, Interpreters, and Debuggers are used. For coding purpose different high level programming languages like C, C++, Pascal and Java are used. The right programming language is chosen according to the type of application.

Operation and maintenance

The maintenance phase is usually the longest stage of the software. In this phase the software is updated to meet the changing customer needs, adapted to accommodate changes in the external environment, correct errors and oversights previously undetected in the testing phases and enhancing the efficiency of the software. Software will definitely go through change once when it is delivered to the customer. There are large numbers of reasons for the change. Change could happen due to some unpredicted input values into the system. In addition to this the changes in the system directly have an effect on the software operations. The software should be implemented to accommodate changes that could be happen during the post development period.

The waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them

As many find this approach particularly rigid, modifications have been made over the years and new variants of the model have emerged

The drawback of the waterfall model is the difficulty of accommodating change after the process is underway.

The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model. The waterfall model however is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on to the next phases and learning from them. A typical problem is when requirements change midway through, resulting in a lot of time and effort being invalidated due to the "Big Design Up Front"

IIn summary, the criticisms of a non-iterative development approach (such as the waterfall model) are as follows:

Poor flexibility; the majority of software is written as part of a contract with a client, and clients are notorious for changing their stated requirements. Thus the software project must be adaptable, and spending considerable effort in design and implementation based on the idea that requirements will never change is neither adaptable nor realistic in these cases.

Unless those who specify requirements and those who design the software system in question are highly competent, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase "following" it.

Constant testing from the design, implementation and verification phases is required to validate the phases preceding them. Users of the waterfall model may argue that if designers follow a disciplined process and do not make mistakes that there is no need to constantly validate the preceding phases.

Frequent incremental builds (following the "release early, release often" philosophy) are often needed to build confidence for a software production team and their client.

It is difficult to estimate time and cost for each phase of the development process.

The waterfall model brings no formal means of exercising management control over a project and planning control and risk management are not covered within the model itself.

Only a certain number of team members will be qualified for each phase, which can lead at times to some team members being inactive.

Prototyping Model

An easily modified and extensible model (representation, simulation or demonstration) of planned software system, likely including its interface and input/output functionality

The main focus of this model is to develop a prototype of the software. The client then evaluates the working prototype, and suggests improvements and corrections, which all go into developing the real application.

The prototyping model is used when the client is unsure about the exact specification but has a genuine need. Then the software engineers can develop a rough prototype to gain an approval of the customer. If the prototype developed is a working model, the developers may use code fragments of the prototype when developing the final application.

Of course, the developers must resist the temptation to extend a prototype into a full fledged application. Because if this is done, the quality will suffer in the long run. The prototype is only meant for evaluation purposes. Some code fragments may be used, but using the whole prototype is not generally a good idea.

The goal of prototyping based development is to counter the first two limitations of the waterfall model discussed earlier. The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an "actual feel" of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system.

Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. In such situations letting the client "plan" with the prototype provides invaluable and intangible inputs which helps in determining the requirements for the system. It is also an effective method to demonstrate the feasibility of a certain approach. This might be needed for novel systems where it is not clear that constraints can be met or that algorithms can be developed to implement the requirements.

• gather requirements
• developer & customer define overall objectives, identify areas needing more investigation – risky requiremnets
• quick design focusing on what will be visible to user – input & output formats
• use existing program fragments, program generators to throw together working version prototype evaluated and requirements refined

There are several steps in the Prototyping Model:

The requirements are being gathered for new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system.

A preliminary design is created for the new system.

A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.

The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users.

The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.

The second prototype is evaluated in the same manner as was the first prototype.

The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.

The final system is constructed, based on the final prototype.

The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

The process iterated until customer & developer satisfied

• then throw away prototype and rebuild system to high quality

• alternatively can have evolutionary prototyping – start with well understood requirements.

Advantages of Prototyping

Users are actively involved in the development. It provides a better system to users, as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency.

Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.

• Errors can be detected much earlier as the system is mode side by side.
• Quicker user feedback is available leading to better solutions.

Disadvantages

Leads to implementing and then repairing way of building systems.

Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.

customer may want to hang onto first version, may want a few fixes rather than rebuild. First version will have compromises

developer may make implementation compromises to get prototype working quickly. Later on developer may become comfortable with compromises and forget why they are inappropriate.

customer may want to hang onto first version, may want a few fixes rather than rebuild. First version will have compromises

developer may make implementation compromises to get prototype working quickly. Later on developer may become comfortable with compromises and forget why they are inappropriate.

And last systems development life cycle would be the, The Capability Maturity Model (CMM) is a methodology used to develop and refine an organization's software development process. The model describes a five-level evolutionary path of increasingly organized and systematically more mature processes. CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and development center sponsored by the U.S. Department of Defense (DoD). SEI was founded in 1984 to address software engineering issues and, in a broad sense, to advance software engineering methodologies. More specifically, SEI was established to optimize the process of developing, acquiring, and maintaining heavily software-reliant systems for the DoD. Because the processes involved are equally applicable to the software industry as a whole, SEI advocates industry-wide adoption of the CMM.

The CMM is similar to ISO 9001, one of the ISO 9000 series of standards specified by the International Organization for Standardization (ISO). The ISO 9000 standards specify an effective quality system for manufacturing and service industries; ISO 9001 deals specifically with software development and maintenance. The main difference between the two systems lies in their respective purposes: ISO 9001 specifies a minimal acceptable quality level for software processes, while the CMM establishes a framework for continuous process improvement and is more explicit than the ISO standard in defining the means to be employed to that end.

CMM's Five Maturity Levels of Software Processes

At the initial level, processes are disorganized, even chaotic. Success is likely to depend on individual efforts, and is not considered to be repeatable, because processes would not be sufficiently defined and documented to allow them to be replicated.

At the repeatable level, basic project management techniques are established, and successes could be repeated, because the requisite processes would have been made established, defined, and documented.

At the defined level, an organization has developed its own standard software process through greater attention to documentation, standardization, and integration.

At the managed level, an organization monitors and controls its own processes through data collection and analysis.

At the optimizing level, processes are constantly being improved through monitoring feedback from current processes and introducing innovative processes to better serve the organization's particular needs.

The Software development Life Cycle models could control, monitor large projects, can evaluate costs and completion targets, well defined user input, have ease of maintenance, there are standards in development and design. Nevertheless, it increased development time and cost, the systems used these models must be defined up front, user input is sometimes limited and it is really hard to estimate costs and sometimes project overruns.

At one time the model was beneficial mostly to the world of automating activities that were assigned to clerks and accountants. However, the world of technological evolution is demanding that systems have a greater functionality that would assist help desk technicians/administrators or information technology specialists/analysts.

References:

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

http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci755441,00.html

http://www.e-digg.com/services/software/sdlc-life-cycle.html

Kerem Kosaner (2008), Software Engineering.

http://www.Process Modeling Definition « Software Engineering.htm