SYSTEMS DEVELOPMENT MODELS

ACCION,HONEY LYNNE C.
BSCS-3

Identify and discuss at least 3 systems development models .. discuss each phases ... (at least 3000 words)

[b]SYSTEMS DEVELOPMENT MODEL[/b]

The systems development model or also known as software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilised in generating the global picture representative of the software process. Examples of models include the workflow model, the data-flow model, and the role model.

The [u]workflow model [/u]shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in the model represent human actions.

The [u]dataflow model[/u] represents the process as a set of activities each of which carries out some data transformation. It shows how the input to the process such as specification is transformed to an output such as design. The activities here maybe lower than in a workflow model. They may represent transformations carries out by people or computers.

The [u]role model[/u] represents the roles of people involved in the software process and the activities for which they are responsible.
In this section of the course focuses on the traditional generic software process models to highlight they effectively demonstrate the different approaches to software development. Such models include the:
[list][*]Build And Fix
Waterfall Model
Formal Systems Development Model
Prototyping Model [Additional information on Prototyping]
Rapid Application Development (RAD) Model [/list]

Evolutionary Process Models
[list][*]Incremental Model
Spiral Model
WINWIN Spiral Model[/list]

Note that these are not definitive descriptions of any particular software process but give an overview of different approaches to software development.

[b]Build-And-Fix model[/b]

This model is the worst model for developing a project.


The product is built without proper specifications and design steps. In essence, the product is built and modified as many times as possible until it satisfies the client. The cost of using this approach is greater than if specifications are drawn up and a design is carefully developed. Software engineers are strongly discouraged from using this development approach.
The waterfall model
The waterfall model derives its name due to the cascading effect from one phase to the other. In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase.

Note that this model is sometimes referred to as the linear sequential model or the software life cycle.

The model consist of six distinct stages, namely:

1.In the requirements analysis phase
(a)The problem is specified along with the desired service objectives (goals)
(b)The constraints are identified
2.In the specification phase the system specification is produced from the detailed definitions of (a) and (b) above. This document should clearly define the product function.
Note that in some text, the requirements analysis and specifications phases are combined and represented as a single phase.
3.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’

4. In the implementation and testing phase stage the designs are translated into the software domain
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.
5. 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 client for acceptance testing.]

6.The maintenance phase the 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
· Enhancing the efficiency of the software

Observe that feed back loops allow for corrections to be incorporated into the model. For example a problem/update in the design phase requires a ‘revisit’ to the specifications phase. When changes are made at any phase, the relevant documentation should be updated to reflect that change.

Advantages
Testing is inherent to every phase of the waterfall model
It is an enforced disciplined approach
It is documentation driven, that is, documentation is produced at every stage

Disadvantages
The waterfall model is the oldest and the most widely used paradigm.
However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:
It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.
As The client usually only has a vague idea of exactly what is required from the software product, this WM has difficulty accommodating the natural uncertainty that exists at the beginning of the project.
The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage.

[b]Formal Systems Development Model[/b]

The formal systems development model utilises a development process that is based on formal mathematical transformation of system models to executable programs. Similar to the waterfall model, the formal approach has clearly defined (cascading) phase boundaries. The critical distinctions between the two models are:
1.The software requirements and specification phases are refined into a detailed formal specification, which is expressed mathematically.
2.The design, implementation and unit testing (NB: to be covered later in semester) are replaced by a single formal transformation phase.


Formal Transformation
During the formal transformation process the mathematical representation of the specifications is systematically refined. More specifically, at each transformation stage (Tx, x = 1, 2,…) more detail is added to produce a refined specification (R x, x = 1, 2,…) until the formal specification is converted into the equivalent program.
Each transformation is made should be sufficiently close to avoid excessive verification efforts and reduce the possibility of transformation errors. In the absence of such errors the program would represent the true implementation of the specifications.

The formal systems development model is typically employed when developing systems that require strict safety, reliability and security requirements. However, the expertise required for the mathematical notations used for the formal specifications adds to the system development effort and cost making this model impractical for the development of other systems. Especially as there are no significant quality or cost advantages over other approaches.

[b]Prototyping Model [/b]

Definition: A prototype is a working model that is functionally equivalent to a component of the product.

In many instances the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed. This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. At that stage the developer determines the specifications of the client’s real needs.
The following sections examines two (2) version of the prototyping model:
Version I: Prototyping is used as a requirements technique.
Version II: Prototype is used as the specifications or a major part thereof.
Version I
It uses the prototype as a means of quickly determining the needs of the client; it is discarded once the specifications have been agreed on. The emphasis of the prototype is on representing those aspects of the software that will be visible to the client/user (e.g. input approaches and output formats). Thus it does not matter if the prototype hardly works.
Note that if the first version of the prototype does not meet the client’s needs, then it must be rapidly converted into a second version.
Version II
The prototype is actually used as the specifications for the design phase. This advantage of this approach is speed and accuracy, as not time is spent on drawing up written specifications. The inherent difficulties associated with that phase (i.e. incompleteness, contradictions and ambiguities) are then avoided.
Disadvantages of prototyping
1.Often clients expect that a few minor changes to the prototype will more than suffice their needs. They fail to realise that no consideration was given to the overall quality of the software in the rush to develop the prototype.
2.The developers may lose focus on the real purpose of the prototype and compromise the quality of the product. For example, they may employ some of the inefficient algorithms or inappropriate programming languages used in developing the prototype. This mainly due to laziness and an over reliance on familiarity with seemingly easier methods.
3.A prototype will hardly be acceptable in court in the event that the client does not agree that the developer has discharged his/her obligations. For this reason using the prototype as the software specification is normally reserved for software development within an organisation.

To avoid the above problems the developer and the client should both establish a protocol, which indicates the deliverables to the client as well as an contractual obligations.
In both versions the prototype is discarded early in the life cycle. However, one way of ensuring that the product is properly designed and implemented is to implement the prototype in a different programming language from that of the product.

[b]RAD Model[/b]

“Rapid Application Development (RAD) is an incremental software development process model that emphasises a very short development cycle [typically 60-90 days].” The RAD model is a high-speed adaptation of the waterfall model, where the result of each cycle a fully functional system.



RAD is used primarily for information systems applications, the RAD approach encompasses the following phases:

Business modeling

The information flow among business functions is modeled in a way that answers the following questions:
What information drives the business process?
What information is generated?
Who generates it?
Where does the information go?
Who processes it?

Data modeling

The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics (called attributes) of each object are identified and the relationships between these objects are defined.
Process modeling
The data objects defined in the data-modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object.
Application generation
RAD assumes the use of the RAD fourth generation techniques and tools like VB, VC++, Delphi etc rather than creating software using conventional third generation programming languages. The RAD works to reuse existing program components (when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate construction of the software.

Testing and turnover

Since the RAD process emphasizes reuse, many of the program components have already been tested. This minimizes the testing and development time.
If a business application can be modularized so that each major function can be completed within the development cycle then it is a candidate for the RAD model. In this case, each team can be assigned a model, which is then integrated to form a whole.

Disadvantages
·For Large (but scalable) projects, RAD requires sufficient resources to create the right number of RAD teams.
·RAD projects will fail if there is no commitment by the developers or the clients to ‘rapid-fire’ activities necessary to get a system complete in a much abbreviated time frame.
·If a system cannot be properly modularized, building components for RAD will be problematic

[b]Incremental Model[/b]

This model derives its name from the way in which the software is built. More specifically, the model is designed, implemented and tested as a series of incremental builds until the product is finished. A build consists of pieces of code from various modules that interact together to provide a specific function.
At each stage of the IM a new build is coded and then integrated into the structure, which is tested as a whole. Note that the product is only defined as finished when it satisfies all of its requirements.

This model combines the elements of the waterfall model with the iterative philosophy of prototyping. However, unlike prototyping the IM focuses on the delivery of an operational product at the end of each increment.
An example of this incremental approach is observed in the development of word processing applications where the following services are provided on subsequent builds:
1. Basic file management, editing and document production functions
2. Advanced editing and document production functions
3. Spell and grammar checking
4. Advance page layout
The first increment is usually the core product which addresses the basic requirements of the system. This maybe either be used by the client or subjected to detailed review to develop a plan for the next increment. This plan addresses the modification of the core product to better meet the needs of the customer, and the delivery of additionally functionality. More specifically, at each stage
·The client assigns a value to each build not yet implemented
· The developer estimates cost of developing each build
· The resulting value-to-cost ratio is the criterion used for selecting which build is delivered next
Essentially the build with the highest value-to-cost ratio is the one that provides the client with the most functionality (value) for the least cost. Using this method the client has a usable product at all of the development stages.

[b]The Spiral Model[/b]

The spiral model combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model, therein providing the potential for rapid development of incremental versions of the software. In this model the software is developed in a series of incremental releases with the early stages being either paper models or prototypes. Later iterations become increasingly more complete versions of the product.

Depending on the model it may have 3-6 task regions (/framework activities) our case will consider a ‘6-task region’ model.
These regions are:
1.The customer communication task – to establish effective communication between developer and customer.
2.The planning task – to define resources, time lines and other project related information..
3.The risk analysis task – to assess both technical and management risks.
4.The engineering task – to build one or more representations of the application.
5.The construction and release task – to construct, test, install and provide user support (e.g., documentation and training).
6.The customer evaluation task – to obtain customer feedback based on the evaluation of the software representation created during the engineering stage and implemented during the install stage.
The evolutionary process begins at the centre position and moves in a clockwise direction. Each traversal of the spiral typically results in a deliverable. For example, the first and second spiral traversals may result in the production of a product specification and a prototype, respectively. Subsequent traversals may then produce more sophisticated versions of the software.
An important distinction between the spiral model and other software models is the explicit consideration of risk. There are no fixed phases such as specification or design phases in the model and it encompasses other process models. For example, prototyping may be used in one spiral to resolve requirement uncertainties and hence reduce risks. This may then be followed by a conventional waterfall development.

·Note that each passage through the planning stage results in an adjustment to the project plan (e.g. cost and schedule are adjusted based on the feedback from the customer, project manager may adjust the number of iterations required to complete the software….)
·Each of the regions is populated by a set of work tasks called a task set that are adapted to characteristics of the project to be undertaken. For small projects the number of tasks and their formality is low. Conversely, for large projects the reverse is true.
Advantages of the Spiral Model
The spiral model is a realistic approach to the development of large-scale software products because the software evolves as the process progresses. In addition, the developer and the client better understand and react to risks at each evolutionary level.
The model uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development.
It maintains a systematic stepwise approach, like the classic life cycle model, but incorporates it into an iterative framework that more reflect the real world.
If employed correctly, this model should reduce risks before they become problematic, as consideration of technical risks are considered at all stages.
Disadvantages of the Spiral Model
·Demands considerable risk-assessment expertise
·It has not been employed as much proven models (e.g. the WF model) and hence may prove difficult to ‘sell’ to the client (esp. where a contract is involved) that this model is controllable and efficient. [More study needs to be done in this regard]

[b]The WINWIN Spiral Model[/b]

This is an adaptation of the spiral model which emphasis is explicitly placed on the involvement of the client in a negotiation process at the genesis of the product development. Ideally, the developer would simply ask the customer what is required and the customer would provide sufficient detail to proceed. Unfortunately this rarely happens and significant negotiations between both parties are required to balance functionality, performance, etc… with cost and time-to-market considerations.
The model derives its name from the objective of these negotiations, i.e. “win-win”. The client gets the product that satisfies the majority of his/her needs, and the developer wins by working to realistic and achievable budgets and deadlines. To achieve this objective the model defines a set of negotiation activities at the beginning of each pass around the spiral. Rather that a single customer communication activity the following activities are defined:
Identification of the system stakeholders. That is the people on the organisation that have direct business interest in the product to be built and will be rewarded for a successful outcome or criticised if the effort fails (e.g. user, customer, developer, maintainer, interfacer, etc.).
Determination of the stakeholder’s “win conditions”
Negotiations of the stakeholder’s win conditions to reconcile them into a set of win-win conditions for all concerned (including the software project team).

In addition to the early emphasis placed on the win-win condition, the model also introduces three process milestones (anchor points), which help establish the completion of one cycle around the spiral and provide the decision milestones before the software project proceeds. These are,
1.Life Cycle Objectives (LCO) – Defines a set of objectives for each major software activity (e.g. a set of objectives associated with the definition of top level product requirements)
2. Life Cycle Architecture (LCA) – Establishes the objectives that must be met as the as the software architecture is defined.
3. Initial Operational Capability (IOC) – represents a set of objectives associated with the preparation of the software for installation/distribution, site preparations prior to installations, and assistance required by all parties that will use or support the software.
Advantages:
Faster software production facilitated through collaborative involvement of the relevant stake holders.
Cheaper software via rework and maintenance reductions

References:
http://scitec.uwichill.edu.bb/cmp/online/cs22l/software_process_models.htm
http://scitec.uwichill.edu.bb/cmp/online/cs22l/formalModel.htm
http://scitec.uwichill.edu.bb/cmp/online/cs22l/BuindAndFix.htm
http://scitec.uwichill.edu.bb/cmp/online/cs22l/waterfall_model.htm
http://scitec.uwichill.edu.bb/cmp/online/cs22l/prototype.htm
http://scitec.uwichill.edu.bb/cmp/online/cs22l/rad.htm
http://scitec.uwichill.edu.bb/cmp/online/cs22l/incremental.htm
http://scitec.uwichill.edu.bb/cmp/online/cs22l/spiralmodel.htm
http://scitec.uwichill.edu.bb/cmp/online/cs22l/winwinspiralmodel.htm