System Development Models and System Analysis and Design part1

3.1 Terminologies

3.11 Various Terminologies used in System Development Models and System Analysis and Design are defined in below section.

3.12 System: A system is an orderly grouping of interdependent components linked together according to a plan to achieve a specific objective.

3.13 Characteristics of a system: Organization, interaction, interdependence, integration and a central objective.

3.14 Elements of a system: Input, processor(s), control, output, feedback, environment, boundaries and interface.

3.15 Types of system:

3.15 a. Physical or abstract system

Physical Systems are tangible entities that may be static or dynamic in operation. Abstract Systems are conceptual or non-physical entities.

3.15 b. Open or closed system.

An open system has many interfaces with its environment. It permits interaction across its boundary. It receives inputs from and delivers outputs to the outside.

A closed system is isolated from environmental influences.

3.16 Systems Development: The activities that go into producing an information systems solution to an organizational problem or opportunity. Systems development is a structured kind of problem solving with distinct activities. These activities consist of recognition of need, feasibility study, analysis, design, implementation, post-implementation, and maintenance.

3.17 Systems Analysis: The analysis of a problem that the organization will try to solve with an information system. It consists of defining the problem, identifying its causes, specifying the solution, and identifying the information requirements that must be met by a system solution. 3.18 System Design: Details how a system will meet the information requirements as determined by the systems analysts.

3.19 Logical Design: Lays out the components of the information system and their relationship to each other, as they would appear to users.

3.20 Physical Design: The process of translating the abstract logical model into the specific technical design for the new system.

3. 2 Concept of System Development Life Cycle (SDLC)

3.21 Systems Development

• The activities that go into producing an information systems solution to an organizational problem or opportunity.

• Systems development is a structured kind of problem solving with distinct activities. These activities consist of recognition of need, feasibility study, analysis, design, implementation, post-implementation, and maintenance.

3.22 Systems Analysis

The analysis of a problem that the organization will try to solve with an information system may be termed as Systems Analysis. It consists of defining the problem, identifying its causes, specifying the solution, and identifying the information requirements that must be met by a system solution.

3.23 The Systems Development Life Cycle (SDLC)

SDLC is a logical sequence of activities used to identify new systems needs and to develop new systems to support those needs. SDLC is a model for reducing risk through planning, execution, control, and documentation of key activities.

3.3 Various stages involved in SDLC

Description of SDLC stages

3.3 Software Process Models

Development strategies to solve software problems are referred to as process models or software process model. A process model for software is chosen based on the nature of the project to be used, the controls and deliverables that are required.

3.31 Linear Model or Waterfall Model:

A classic SDLC first identified in 1970 as a formal alternative to the code-and-fix software development method prevalent at that time.

Strengths:

. Tackles complexity in an orderly way, working well for projects that are well understood but still complex.

. It is easy to understand, with a simple goal-to complete required activities.

. It provides a template into which methods for analysis, design, code, test, and support can be placed.

. It works well when quality requirements dominate cost and schedule requirements.

. It allows for tight control by project manager.

. Its milestones are well understood.

. It is easy to track the progress of the project using a time line or Gantt chart – the completion of each phase is used as a milestone.

Weaknesses:

. It has an inherently linear sequential nature – any attempt to go back two or more phases to correct a problem or deficiency results in major increases in cost and schedule.

. It does not handle the reality of iterations among phases so common in software development.

. It can present a false impression status and progress – “35% done”

. Integration happens in one big bang at the end.

. There is insufficient opportunity for a customer to preview the system until very late in the life cycle. Users are involved while gathering requirements in the beginning and at the end, during acceptance testing.

. Users cannot see quality until the end

. It is not possible for the user to get used to the system gradually. All training must occur at the end of the life cycle.

. Each phase is a prerequisite for succeeding activities

. All requirements must be known at the beginning of the life cycle. The model is not equipped to handle dynamic changes in requirements over the life cycle, as deliverables are “frozen”

. It is document-driven, and the amount of documentation can be excessive.

. The entire software project is being worked at one time. There is no way to partition the system for delivery of pieces of the system at one time.

When to use?

. The requirements and the implementation of those requirements are very well understood

. Stable product definition and well understood technical methodologies

. A project to build another of the same type or product (existing designs)

. New versions

. Porting an existing product to a new plateform Essence:

.It progresses through the orderly sequence steps.

. It assumes that each subsequent phase will begin when activities in the current phase have been completed.

. Each phase has defined entry and exit criteria: inputs and outputs.

. Transition from one phase to the next is accomplished by passing a formal review.

. At critical points on the waterfall model, base lines are established, the last of which is the product base line. The final base line is accompanied by an acceptance review.

. Porting an existing product to a new platform

3.32 The Prototype Model

The Prototype Model

Prototyping is more explicitly iterative and it actively promotes system design changes.Process of building an experimental system quickly and inexpensively for demonstration and evaluation so that end users can better determine information requirements. Prototyping replaces unplanned rework with planned iteration, with each version more accurately reflecting user requirements. Less formal, requirements are determined dynamically as the prototype is constructed.

A customer defines a set of general objectives for software but does not identify detailed input, processing, or output requirements or the developer may be unsure of the efficiency of an algorithm, the adoptability of such system, or the form that human/machine interaction should take. This serves as a mechanism for identifying (defining) software requirements. The prototype can serve as “the first system”. Users get a feel for the actual system and developers get to build something immediately.

Steps Involved in Prototype Model

1. Identify the user’s basic requirements

2. Develop a working prototype

3. Use the prototype

4. Revise and enhance the prototype

. Requirements gathering: Developer and customer meet and define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory.

. A “quick design” then occurs which focuses on a representation of those aspects visible to

the customer/user (Eg. Input approaches and output formats).

. The quick design lends to the construction of a prototype.

. The prototype is evaluated by the customer/user and used to refine requirements for the software to be developed.

. Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the developer to better understand what needs to be done.

Strengths:

. Most useful when there is some uncertainty about requirements or design solutions. (Difficult to specify in advance or they may change substantially as implementation progresses).

.Especially valuable for the design of the end-user interface of an Information System.

. When the system builders may be unsure of certain technical features of the design solution

. Applications that are oriented to simple data manipulation and records management.

. Systems that are based on batch processing or that rely on heavy calculations and complex procedural logic are unsuitable.

. Suitable for smaller applications

Weaknesses:

.Rapid prototyping can gloss over essential steps in system development

. Prototyping system to be fine tuned

. Hastily constructed systems may be difficult to maintain and support in regular production

. The customer sees what appears to be a working version of the software unaware that the prototype is held together.

. When informed that the product must be rebuilt so that high levels of quality can be maintained, the customer cries foul demands that “a few fixes” be applied to make a prototype a working product and often s/w development management relents.

. The developer often makes implementation compromises in order to get a prototype

working quickly (algorithm, OS, PL).

.The less-than ideal choice becomes an integral part of the system.

. Need to be tested and documented.

When to use?

. On systems that may be modularized and that are scalable.

. On systems with reasonably well-known requirements.

. When the end users can be involved throughout the life cycle.

.When users are willing to become heavily involved in the use of automated tools.

. On systems that can be time boxed to deliver the functionality in increments.

. When reusable parts are available through automated software repositories.

. When the project team is familiar with the problem domain, skilled in the use of the development tools, and highly motivated.

3.33 Spiral Model

Spiral Model

. Introduced by Dr. Barry Boehm, 1988

. Is an evolutionary process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model

. It provides the potential for rapid development for incremental versions of the software

. Software is developed in a series of incremental releases

. During early iterations, the incremental release might be a paper model or prototype

. During later iterations, increasingly more complete versions of the engineered system are produced

. The spiral model encompasses the strengths of the waterfall model while including risk analysis, risk management, and support and management processes.

. It also allows for the development of the product to be performed using a prototype technique or RAD through the use of 4 GLS

A spiral model is divided into a number of framework activities, also called task regions. Typically, there are six task regions.

1. Customer Communication: Tasks required establishing effective communication between developer and customer.

2. Planning: Tasks required defining resources, time lines, and other project related

information.

3. Risk Analysis: Tasks required to assess both technical and management risks.

4. Engineering: Tasks required building one or more representations of the applications.

5. Construction and release: Tasks required constructing, testing, installing, and providing user support (Eg. Documentation and training).

6. Customer Evaluation: Tasks required obtaining customer feedback based on evaluation of

the software representations created during the engineering stage and implemented during the installation stage.

Each of the regions is populated by a set of work tasks, called task set, that are adopted to the characteristics of the project to be undertaken. For each iteration, determine objectives, alternatives, and constraints; identify and resolve risks; evaluate alternatives; develop the deliverables for that iteration and verify that they are correct; plan the next iteration; and commit to an approach for the next iteration as shown in figure 3.3. The idea is to minimize risk through successive refinements of user requirements. Each “mini-project” (travel round the spiral) addresses one or more major risks, beginning with the highest. Risks include poorly understood requirements, poorly understood architecture, potential performance problems, and problems in the underlying technology.

Strengths:

. The spiral model allows users to see the system early, through the use of rapid prototyping in the development life cycle

.It provides early indications of insurmountable risks, without much cost

. It allows users to be closely tied to all planning, risk analysis, development, and evaluation activities

. It splits a potentially large development effort into small chunks in which critical, high-risk

functions are implemented first

. The model allows for flexible design by embracing the strengths of the waterfall model while allowing for iteration throughout the phases of that model

. It does not rely on the impossible task of getting the design perfect

. Management control of quality, correctness, cost, schedule, and staffing is improved through reviews at the conclusion of each iteration

. It enhances predictability through clarification of objectives

.All the money needed for the project need not be allocated up-front

. Takes the advantage of the strengths of the incremental model with incremental releases Weaknesses:

. If the project is low-risk or small, this model can be an expensive one. The time spent

evaluating the risk after each spiral is costly

. The model is complex, and developers, managers, and customers may find it too complicated to use

. The spiral may continue indefinitely, generated by each of the customer’s responses to

the build initiating a new cycle, closure (convergence on a solution) may be difficult to achieve

. Considerable risk assessment expertise is required

. Use of the model may be expensive and even unaffordable – time spent on planning, resetting objectives, doing risk analysis, and prototyping may be excessive

. Developers must be reassigned during non-development-phase activities

. It can be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration

. Industry has not had as much experience with the spiral model as it has with others

When to use?

. For projects that represent a medium to high risk

. When it is unwise to commit to a long-term project due to potential changes in economic priorities, and when these uncertainties may limit the available time frame.

. When the technology is new and tests of basic concepts are required.

. When users are unsure of their needs

. When requirements are complex

. When significant changes are expected as with research or exploration

. For organizations that cannot afford to allocate all the necessary project money up-front, without getting some feed back along the way

. When benefits are uncertain and success is not guaranteed

. With computation-intensive systems, such as DSS

. With business projects as well as aerospace, defence, and engineering projects

. On long projects that may make managers or customers nervous

. To demonstrate quality and attainment of objectives in short period of time