1

Week 5 & 6 -Major Components of Systems Development

IT2005 System Analysis

& Design

2

Major components of system development

1. Methodology2. Modeling Methods or Techniques3. Tools

3

Methodology

• A very formal and accurate system development process that defines a set of – Activities – Methods – Best practices – Deliverables – Automated tools

Methodology

Methods Or Techniques

Tools

4

Methodology..

Provides the framework1. Has a predefined set of steps2. Ensures that systems are built in the most effective

wayEg: SSADM (structured methodologies)STRADIS (Structured Analysis, Design and

Implementation of Information Systems) YSM (Yourdon Systems Method)

5

Methodology

Modeling Methods Or Techniques

Eg: Class diagram, usecase diagram

ToolsEg: Rational rose

6

Modeling method• A set of techniques used to implement a Methodology.• Data Flow Diagrams

– A process model – Depict the flow of data through a system and the work performed

by the system • Entity Relationship Diagrams

– A data model – Depict data in terms of entities and relationships described by the

data – Consists of several notations

• Structure Charts etc.

7

ToolsTools are Software systems and they assist analysts

and designers to build information systems. General Aim :– Decrease the human effort required to develop

the software – Increase the quality of software – Tools will support methodologies but will not

replace system analysts.e.g. Easy Case, Rational Rose

8

Underlying Principles for SystemDevelopment methodology

P1: Get the system users involvedP2: Use a problem-solving approachP3: Establish phases and activities.P4 : Document through out DevelopmentP5: Establish standardsP6 :Manage the process and ProjectsP7:Justify systems as Capital Investments.P8:Don’t be afraid to cancel or revise scope.P9:Divide and conquerP10: Design systems for growth and change.

9

What is a Software Process?

• A set of ordered tasks involving activities , constraints and resources that produce a software system.

10

Software process models• Waterfall model• Prototyping models• Evolutionary models• The spiral model• Formal development• Incremental development• Rapid Application Development• Unified Process• Agile Process• Extreme Programming (XP)

11

The Waterfall model• Separate and distinct phases of specification

and development

• A linear sequential model

requirements analysis & spec

softwaredesign

coding

testing

Maintenance

12

Software Life Cycle Models

• Waterfall lifecycle

13

Waterfall Strengths

Easy to understand, easy to useProvides structure to inexperienced staffMilestones are well understoodSets requirements stabilityGood for management control (plan, staff,

track)Works well when quality is more important

than cost or schedule

14

Problems with Waterfall Development Approach

15

Problems with Waterfall Development Approach……

There are several problems with this approach. 1. It has a rigid design 2. Inflexible 3. It has a top-down procedure 4. One phase must be completed before the next phase

starts 5. No phase can be repeated 6. Time consuming

There are several criticisms of the Waterfall development approach

16

Modified Waterfall Development Approach

• Uses the same phases as the pure waterfall development approach.

• Allow some of the stages to overlap, such as the requirements stage and the design stage.

• Another common modification is to incorporate prototyping into the requirements phases.

• Overlapping stages make it possible to integrate feedback from the design phase into the requirements.

• Progress is more difficult to track.

When to use the Waterfall Model

The linear cycles are usually best suited to problems which are well understood and highly structured. Attractive for large problems. Projects which have clear and stable requirements.

PrototypingIt is very difficult for end-users to anticipate how they will use new software systems to support their work. If the system is large and complex, it is probably impossible to make this assessment before the system is built and put into use.

A prototype ( a small version of the system) can be used to clear the vague requirements. A prototype should be evaluated with the user participation.

There are two types of Prototyping techniques

* Throw-away Prototyping

* Evolutionary Prototyping

Throw-away and Evolutionary Prototyping

Outline

Requirements

Throw-away

prototyping

Evolutionary

prototyping

Executable prototype +

System specification

Delivered system

Throw-away Prototypingspecify system

establish outline

specification

components

evaluate prototype

develop prototype

validate system

design and implement

system

Delivered

software

system

Throw-away Prototyping

The objective is to understand the system requirements clearly. Starts with poorly understood requirements. Once the requirements are cleared, the system will be developed from the beginning.

This model is suitable if the requirements are vague but stable.

Some problems with Throw-away Prototyping1. Important features may have been left out of the prototype to

simplify rapid implementation. In fact, it may not be possible to prototype some of the most important parts of the system such as safety-critical functions.

2. An implementation has no legal standing as a contract between customer and contractor.

3. Non-functional requirements such as those concerning reliability, robustness and safety cannot be adequately tested in a prototype implementation.

Evolutionary Prototyping

Develop abstractspecification

Build prototypesystem

Evaluate prototypesystem

SystemAdequate?

Deliversystem

NO

YES

24

Structured Evolutionary Prototyping Strengths

1. Customers can “see” the system requirements as they are being gathered

2. Developers learn from customers 3. A more accurate end product4. Unexpected requirements accommodated5. Allows for flexible design and development6. Interaction with the prototype stimulates awareness of

additional needed functionality

25

Prototyping Weaknesses• Prototyping can lead to false expectations. • Prototyping can lead to poorly designed systems. • Overall maintainability may be overlooked• The customer may want the prototype delivered.• Process may continue forever (scope creep)

• Continual change tends to corrupt the structure of the prototype system. Maintenance is therefore likely to be difficult and costly.

Evolutionary Prototyping (continued)Disadvantages

* Prototype usually evolve so quickly that it is not cost- effective to

produce greater deal of documentation

* Continual change tends to corrupt the structure of the prototype

system. Maintenance is therefore likely to be difficult and costly.

* It is not clear how the range of skills which is normal in software

engineering teams can be used effectively for this mode of

development.

* Languages which are good for prototyping not always best for final

product.

The RAD Model

Business

modeling

Data

modeling

Process

modeling

Application

generation

Testing &

turnover

Business

modeling

Data

modeling

Process

modeling

Application

generation

Testing &

turnover

Business

modeling

Data

modeling

Process

modeling

Application

generation

Testing &

turnover

Team 1Team 2

Team 3

60 –90 days

Processes in the RAD model

Business modelling - The information flow in a business system considering its functionality.

Data Modelling - The information flow defined as part of the business modelling phase is refined into a set of data objects that are needed to support the business

Process Modelling - The data objects defined in the data modelling phase are transformed to achieve the information flow necessary to implement business functions.

Application generation - RAD assumes the use of 4GL or visual tools to generate the system using reusable components.

Testing and turnover

New components must be tested and all interfaces must be fully exercised

Cont. RAD lifecycle

29

RequirementDefinition/ Refinement

Contract

Feedback

Design

Prototype Development

Cutomer Prototype Review

Deployment

The RAD model

• Rapid Application Development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle.

• If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a ‘fully functional system’ within very short time periods (eg. 60 to 90 days)

Some problems with the RAD model

1. RAD requires sufficient human resources to create right number of RAD teams

2. RAD requires developers and customers who are committed to the rapid-fire activities necessary to get a system completed in a much abbreviated time frame.

3. If a system cannot be properly modularized, building the components necessary for RAD will be problematic.

4. RAD is not applicable when technical risks are high.

Incremental Model

conception

architecture

deliver 1st Increment

analysis design code test

deliver 2nd Increment

analysis design code test

deliver 3rd Increment

analysis design code test

structure

feedback

feedback

Incremental Development

• The Incremental development model involves developing the system in an incremental fashion.

• The most important part of the system is fist delivered and the other parts of the system are then delivered according to their importance.

• Incremental development is more manageable than evolutionary prototyping as the normal software process standards are followed.

• Plans and documentation must be produced

34

Iterative Development Approach

35

Iterative Development Approach

• Iterative development approach completes the entire IS in successive iterations.

• Each iteration does some – analysis – design – construction

• Allows versions of usable information to be delivered in regular and shorter time frames.

• The iteration process helps to develop a part of the new system and place it into operation as quickly as possible.

36

Spiral model• The spiral model (Boehm, 1988) aims at risk reduction by any

means in any phase.• quadrant 1

– determine objectives of that phase– alternatives and constraints.

• quadrant 2– analyzed form the viewpoint of risk– solutions to minimize these risks are investigated, often using

prototyping. • quadrant 3

– where the traditional waterfall model phases are put into practice.• Quadrant4

– the results of the risk-reduction strategies

37

Spiral model

38

Spiral Quadrant

Determine objectives, alternatives and constraints

• Objectives: functionality, performance, hardware/software interface, critical success factors, etc.

• Alternatives: build, reuse, buy, sub-contract, etc.

• Constraints: cost, schedule, interface, etc.

39

Spiral QuadrantEvaluate alternatives, identify and resolve risks

• Study alternatives relative to objectives and constraints

• Identify risks (lack of experience, new technology, tight schedules, poor process, etc.

• Resolve risks (evaluate if money could be lost by continuing system development)

40

Spiral QuadrantDevelop next-level product

• Typical activates:– Create a design– Review design– Develop code– Inspect code– Test product

41

Spiral QuadrantPlan next phase

• Typical activities– Develop project plan– Develop configuration management plan– Develop a test plan– Develop an installation plan

42

Spiral Model Strengths• Provides early indication of insurmountable

risks, without much cost• Users see the system early because of rapid

prototyping tools• Critical high-risk functions are developed first• The design does not have to be perfect • Users can be closely tied to all lifecycle steps• Early and frequent feedback from users

43

Spiral Model Weaknesses

• Time spent for evaluating risks too large for small or low-risk projects

• The model is complex • Risk assessment expertise is required• May be hard to define objective, verifiable

milestones that indicate readiness to proceed through the next iteration

44

When to use Spiral Model• When creation of a prototype is appropriate• When costs and risk evaluation is important• For medium to high-risk projects• Long-term project commitment unwise because of potential

changes to economic priorities• Users are unsure of their needs• Requirements are complex• New product line • Significant changes are expected (research and exploration)•

V-Shaped SDLC Model

45

Testing of the product is planned in parallel with a corresponding phase of development

46

47

V-Shaped Strengths

• Emphasize planning for verification and validation of the product in early stages of product development

• Each deliverable must be testable• Project management can track progress by

milestones• Easy to use

48

V-Shaped Weaknesses

• Does not easily handle concurrent events• Does not handle iterations or phases• Does not easily handle dynamic changes in

requirements• Does not contain risk analysis activities

49

Waterfall vs AgileTimeboxing

RAD: Definition?

50

• Many Definitions : same philosophy• Definition 1:– A software development process that allows

usable systems to be built within a short period (as little as 2-3 months), often with compromises.

– It is a generic term with the meaning “speedy development” or “Shorter schedule”

RAD

51

• Rapid Application Development (RAD) refers to a type of software development which uses “optimal” planning in favor of rapid prototyping.

• The "planning" of software developed using RAD is interleaved with writing the software itself.

• The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

RAD lifecycle

52

• RAD compresses the step-by-step development process into an iterative process.– User requirements are refined.– A system is designed.– A prototype is developed.– The prototype is reviewed by end-user.– User provide feedback.– The process is repeated.

Review Questions

1. The following are initial requirements specified by some customers. Identify the most suitable process models for these software projects.

(a) “ I need to develop a simple library system for my school. I know the requirements very well”

(b) “I need to develop a management information system for my organization,. I may use it for all the branches in several location in Sri Lanka. I might use it on the Internet”.

(c ) “ I need to develop a software system to control a space shuttle”