Spiral process

DEFINITION – The spiral model, also known as the spiral lifecycle model, is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive, and complicated projects.

The steps in the spiral model can be generalized as follows:

1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. 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.
4. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.
5. At the customer’s option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer’s judgment, result in a less-than-satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
8. The final system is constructed, based on the refined prototype.
9. 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.

Applications

For a typical shrink-wrap application, the spiral model might mean that you have a rough-cut of user elements (without the polished / pretty graphics) as an operable application, add features in phases, and, at some point, add the final graphics.

The spiral model is used most often in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program.

Advantages1

• Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses, because important issues are discovered earlier.
• It is more able to cope with the (nearly inevitable) changes that software development generally entails.
• Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.

Advantages2 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]

Top-down and bottom-up design

Top-down and bottom-up are strategies of information processing and knowledge ordering, mostly involving software, and by extension other humanistic and scientific system theories (see systemics).

In a top-down approach an overview of the system is first formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. A top-down model is often specified with the assistance of “black boxes” that make it easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms or be detailed enough to realistically validate the model.

In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed. This strategy often resembles a “seed” model, whereby the beginnings are small, but eventually grow in complexity and completeness. However, “organic strategies”, may result in a tangle of elements and subsystems, developed in isolation, and subject to local optimization as opposed to meeting a global purpose.

Programming

Top-down programming is a programming style, the mainstay of traditional procedural languages, in which design begins by specifying complex pieces and then dividing them into successively smaller pieces. Eventually, the components are specific enough to be coded and the program is written. This is the exact opposite of the bottom-up programming approach which is common in object-oriented languages such as C++ or Java.

The technique for writing a program using top-down methods is to write a main procedure that names all the major functions it will need. Later, the programming team looks at the requirements of each of those functions and the process is repeated. These compartmentalized sub-routines eventually will perform actions so simple they can be easily and concisely coded. When all the various sub-routines have been coded the program is done.

By defining how the application comes together at a high level, lower level work can be self-contained. By defining how the lower level objects are expected to integrate into a higher level object, interfaces become clearly defined.

Advantages of top-down programming

• Separating the low level work from the higher level objects leads to a modular design.
• Modular design means development can be self contained.
• Having “skeleton” code illustrates clearly how low level modules integrate.
• Code is easier to follow, since it is written methodically and with purpose.

 Disadvantages of top-down programming

• No functionality will exist until development of low level objects is complete.

System Development Life Cycle 

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 SDLC methodologies have been developed to guide the processes involved including the waterfall model (the original SDLC method), rapid application development (RAD), joint application development (JAD), the fountain model and the spiral model. Mostly, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely particular plan was followed.

The image below is the classic Waterfall model methodology, which is the first SDLC method and it describes the various phases involved in development.

Briefly on different Phases:

Feasibility

The feasibility study is used to determine if the project should get the go-ahead. If the project is to proceed, the feasibility study will produce a project plan and budget estimates for the future stages of development.

Requirement Analysis and Design

Analysis gathers the requirements for the system. This stage includes a detailed study of the business needs of the organization. Options for changing the business process may be considered. Design focuses on high level design like, what programs are needed and how are they going to interact, low-level design (how the individual programs are going to work), interface design (what are the interfaces going to look like) and data design (what data will be required). During these phases, the software’s overall structure is defined. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.

Implementation

In this phase the designs are translated into code. Computer programs are written using a conventional programming language or an application generator. Programming tools like Compilers, Interpreters, Debuggers are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.

Testing

In this phase the system is tested. Normally programs are written as a series of individual modules, these subject to separate and detailed test. The system is then tested as a whole. The separate modules are brought together and tested as a complete system. The system is tested to ensure that interfaces between modules work (integration testing), the system works on the intended platform and with the expected volume of data (volume testing) and that the system does what the user requires (acceptance/beta testing).

Maintenance

Inevitably the system will need maintenance. Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period.

source:http://www.startvbdotnet.com/sdlc/sdlc.aspx

hi guys, i’ve found a website which may help us to better understand each individual process, its a simplified version. u may want to take a look at it if u find the below entries are too ”chim”. u can find the link at ur left hand side under the heading “BLOGROLL“—> computer world.  =D

 anyway, OLE has this:

A personal information management system is a software system that manages appointments, contact lists, and to-do (task) lists. For appointments, the users can make, update, and manage their appointments with other users in the company. For contact lists, the users can add new contacts, modify existing contacts, and manage their contacts address book. For to-do lists, the users can create new to-do items, modify existing items, and manage their list of tasks (i.e. to-do items) that they must do.

Please note the above is a high-level description of what the personal information management system should do, but all the actual details were lost (i.e. Daniel did not hand over anything when he quit!)

Systems Development Life Cycle (SDLC) or sometimes just (SLC) is defined as a software development process, although it is also a distinct process independent of software or other information technology considerations. It is used by a systems analyst to develop an information system, including requirements, validation, training, and user ownership through investigation, analysis, design, implementation, and maintenance. SDLC is also known as information systems development or application development. An SDLC should result in a high quality system that meets or exceeds customer expectations, within time and cost estimates, works effectively and efficiently in the current and planned information technology infrastructure, and is cheap to maintain and cost-effective to enhance. SDLC is a systematic approach to problem solving and is composed of several phases, each comprising multiple steps:

• The software concept – identifies and defines a need for the new system
• A requirements analysis – analyzes the information needs of the end users
• The architectural design – creates a blueprint for the design with the necessary specifications for the hardware, software, people and data resources
• Coding and debugging – creates and programs the final system
• System testing – evaluates the system’s actual functionality in relation to expected or intended functionality.

The last row represents the most commonly used Life Cycle steps

The ‘Systems Life Cycle’ (UK Version)

The SDLC is referred to as the Systems Life Cycle (SLC) in the United Kingdom, whereby the following names are used for each stage:

1. Terms Of Reference — the management will decide what capabilities and objectives they wish the new system to incorporate;
2. Feasibility Study — asks whether the managements’ concept of their desired new system is actually an achievable, realistic goal, in-terms of money, time and end result difference to the original system. Often, it may be decided to simply update an existing system, rather than to completely replace one;
3. Fact Finding and Recording — how is the current system used? Often questionnaires are used here, but also just monitoring (watching) the staff to see how they work is better, as people will often be reluctant to be entirely honest through embarrassment about the parts of the existing system they have trouble with and find difficult if merely asked;
4. Analysis — free from any cost or unrealistic constraints, this stage lets minds run wild as ‘wonder systems’ can be thought-up, though all must incorporate everything asked for by the management in the Terms Of Reference section;
5. Design — designers will produce one or more ‘models’ of what they see a system eventually looking like, with ideas from the analysis section either used or discarded. A document will be produced with a description of the system, but nothing is specific — they might say ‘touchscreen’ or ‘GUI operating system’, but not mention any specific brands;
6. System Specification — having generically decided on which software packages to use and hardware to incorporate, you now have to be very specific, choosing exact models, brands and suppliers for each software application and hardware device;
7. Implementation and Review — set-up and install the new system (including writing any custom (bespoke) code required), train staff to use it and then monitor how it operates for initial problems, and then regularly maintain thereafter. During this stage, any old system that was in-use will usually be discarded once the new one has proved it is reliable and as usable.
8. Use – obviously the system needs to actually be used by somebody, otherwise the above process would be completely useless.
9. Close – the last step in a system’s life cycle is it’s end, which is most often forgotten when you design the system. The system can be closed, it can be migrated to another (more modern platform) or it’s data can be migrated into a replacing system.

Systems Development Life Cycle: Building the System

All methods undertake the seven steps listed under insourcing to different degrees:

Insourcing

Insourcing having IT specialists within an organization to build the organization’s system by

• Planning – establishing the plans for creating an information system by
  • Defining the system to be developed – based on the systems prioritized according to the organization’s critical success factor (CSF), a system must be identified and chosen
  • the project scope – a high level of system requirements must be defined and put into a project scope document
  • Developing the project plan – – all details from tasks to be completed, who completed them and when they were completed must be formalized
  • Managing and monitoring the project plan – this allows the organization to stay on track, creating project milestones and feature creeps which allow you to add to the initial plan
• Analysis – the users and IT specialists collaborate to collect, comprehend, and logistically formalize business requirements by
  • Gathering the business requirements’ – IT specialists and knowledge workers collaborate in a joint application design (JAD) and discuss which tasks to undertake to make the system most successful
  • Analyzing the requirements – business requirements are prioritized and put in a requirements definition document where the knowledge worker will approve and place their signatures
• Design – this is where the technical blueprint of the system is created by
  • Designing the technical architecture – choosing amongst the architectural designs of telecommunications, hardware and software that will best suit the organization’s system and future needs
  • Designing the systems model – graphically creating a model from graphical user interface (GUI), GUI screen design, and databases, to placement of objects on screen
  • Write the test conditions – Work with the end users to develop the test scripts according to the system requirements
• Development – executing the design into a physical system by
  • Building the technical architecture – purchasing the material needed to build the system
  • Building the database and programs – the IT specialists write programs which will be used on the system
• Testing – testing the developed system
  • Test the system using the established test scripts – test conditions are conducted by comparing expected outcomes to actual outcomes. If these differ, a bug is generated and a backtrack to the development stage must occur.
• Deployment – the systems are placed and used in the actual workforce and
  • The user guide is created
  • Training is provided to the users of the system – usually through workshops or online
• Maintenance – keeping the system up to date with the changes in the organization and ensuring it meets the goals of the organization by
  • Building a help desk to support the system users – having a team available to aid technical difficulties and answer questions
  • Implementing changes to the system when necessary.

Selfsourcing

Selfsourcing having knowledge workers within an organization build the organization’s system

• Align selfsourcing applications to the goals of the organization – All intentions must be related to the organization’s goals and time management is key.
• Establish what external assistance will be necessary – this may be where an IT specialist in the organization may assist
• Document and formalize the completed system created for future users –
• Provide ongoing support – being able to maintain and make adjustments to the system as the environment changes..

Prototyping

Prototyping creating a model, which displays the necessary characteristics of a proposed system

• Gathering requirements – these requirements will be stated by the knowledge workers as well as become apparent in comparison with the old or existing system
• Create prototype of system – Confirm a technically proficient system by using prototypes and create basic screen and reports
• Review by knowledge workers – create a model of the system that will be analyzed, inspected and evaluated by knowledge workers who will propose recommendations to have the system reach its maximum potential
• Revise the prototype – if necessary
• Market the idea of the new system – use the prototype to sell the new system and convince the organization of the advantages of switching up to the new system

Outsourcing

Outsourcing having a third party (outside the organization) to build the organization’s system so expert minds can create the highest quality system by.

• Outsourcing for development software -
  • Purchasing existing software and paying the publisher to make certain modifications and paying the publisher for the right to make modifications yourself
  • Outsourcing the development of an entirely new unique system for which no software exists
• Selecting a target system – make sure there is no confidential information critical to the organization that others should not see. If the organization is small enough, consider selfsourcing
• Establish logical requirements – IT specialists and knowledge workers collaborate in a joint application design (JAD) and discuss which tasks to undertake to make the system most successful to gather business requirements
• Develop a request for a proposal – a request for proposal (RFP) is created and formalized. It includes everything the home organization is looking for in the system and can be used as the legal binding contract
• Evaluate request for proposed returns and choose a vendor amongst the many who have replied with different prototypes
• Test and Accept a Solution – the chosen system must be tested by the home organization and a sign-off must be conducted
• Monitor and Reevaluate – keep the system up to date with the changing environment and evaluate the chosen vendor’s ability and accommodate to maintain the system

source:http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle