Chapter 2:System Development

Methodologies & Automated Systems

1

Learning Objectives

Understand the evolution of system development methodologies

Understand the use of CASE Tools in System Development

2

System Development Methodologies

Methodology: a formalized approach to implementing the SDLC

A set of sequential stages

CategoriesProcess orientedData centeredObject-orientedStructuredRapid action developmentAgile development

3

Classes of Methodologies

Structured DevelopmentWaterfall DevelopmentParallel Development

Rapid Application DevelopmentPhasedPrototyping

Agile DevelopmenteXtreme Programming (XP)

4

Example:Making a Simple Lunch

5

Structured Development:

Waterfall DevelopmentThe original structured design methodology (that

is still used today)

The analysts and users proceed in sequence from one phase to the next

The key deliverables for each phase are typically very long (often hundreds of pages in length) and are presented to the project sponsor for approval as the project moves from phase to phase.

6

Once the sponsor approves the work that was conducted for a phase, the phase ends and the next one begins.

This methodology is referred to as waterfall development because it moves forward from phase to phase in the same manner as a waterfall.

While it is possible to go backward in the SDLC (e.g., from design back to analysis), it is extremely difficult.

7

8

Pros & ConsPros Cons

Identifies system requirements long before programming begins

The design mustbe completely specified before programming begins

Minimizes changes to therequirements as the project proceeds

A long time elapses betweenthe completion of the system proposal in the analysis phase and the delivery of the system (usually many months or years)

9

Structured Development: Parallel

DevelopmentThe parallel development methodology attempts to

address the problem of long delays between the analysis phase and the delivery of the system.

Instead of doing design and implementation in sequence, it performs a general design for the whole system and then divides the project into a series of distinct subprojects that can be designed and implemented in parallel.

Once all subprojects are complete, there is a final integration of the separate pieces, and the system is delivered

10

11

Pros & ConsPros Cons

It can reduce the schedule time to deliver a system

Too many documents

Less chance of changes in the business environment causing rework

adds a new problem

12

Rapid Application Development

A second category of methodologies includes rapid application development (RAD)–based methodologies that emerged in the 1990s.

RAD-based methodologies attempt to address both weaknesses of structured design methodologies by adjusting the SDLC phases to get some part of the system developed quickly and into the hands of the users.

Users can better understand the system and suggest revisions that bring the system closer to what is needed.

13

Most RAD-based methodologies recommend that analysts use special techniques and computer tools to speed up the analysis, design, and implementation phases, CASE tools Joint Application Design (JAD) sessions Fourth generation/visual programming languages that

simplify and speed-up programming (e.g., Visual Basic), code generators that automatically produce programs from design specifications.

It is the combination of the changed SDLC phases and the use of these tools and techniques that improve the speed and quality of systems development.

14

RAD: Phased Development

A phased development–based methodology breaks the overall system into a series of versions that are developed sequentially.

The analysis phase identifies the overall system concept, and the project team, users, and system sponsor then categorize the requirements into a series of versions.

The most important and fundamental requirements are bundled into the first version of the system.

The analysis phase then leads into design and implementation, but only with the set of requirements identified for version 1.

15

Once version 1 is implemented, work begins on version 2. Additional analysis is performed based on the previously identified requirements and combined with new ideas and issues that arose from the users’ experience with version 1.

Version 2 then is designed and implemented, and work immediately begins on the next version. This process continues until the system is complete or is no longer in use.

16

17

Pros & ConsPros Cons

Users Get a SystemTo Use Quickly

Users Work with aSystem that isIntentionally Incomplete

Users Can IdentifyAdditional NeedsFor Later Versions

18

RAD: PrototypingA prototyping-based methodology performs the

analysis, design, and implementation phases concurrently, and all three phases are performed repeatedly in a cycle until the system is completed.

the basics of analysis and design are performed, and work immediately begins on a system prototype, a “quick-and dirty” program that provides a minimal amount of features.

First prototype is usually the first part of the system that the user will use.

19

1st Prototype- shown to the users and project sponsor who provide comments :-re-analyze, re-design, and re-implement a second

prototype that provides a few more features.

This process continues in a cycle until the analysts, users, and sponsor agree that the prototype provides enough functionality to be installed and used in the organization.

After the prototype (now called the system) is installed, refinement occurs until it is accepted as the new system

20

21

Pros & ConsPros Cons

Users Interact withPrototype Very Quickly Tendency to do

Superficial Analysis (Careful Analysis)

Initial Design Decisions May

Be Poor

Users Can IdentifyNeeded ChangesAnd Refine RealRequirements

22

RAD: Throwaway Prototyping

Similar to prototyping-based methodologies in that they include the development of prototypes.

However throwaway prototypes are done at a different point in the SDLC.

These prototypes are used for a very different purpose than ones previously discussed, and they have a very different appearance.

The throwaway prototyping-based methodologies have a relatively thorough analysis phase that is used to gather information and to develop ideas for the system concept.

23

24

Each of these issues is examined by analyzing, designing, and building a design prototype.

A design prototype is not a working system. It is a product that represents a part of the system that needs additional refinement, and it only contains enough detail to enable users to understand the issues under consideration.

A system that is developed using this type of methodology probably relies on several design prototypes during the analysis and design phases.

25

Each of the prototypes is used to minimize the risk associated with the system by confirming that important issues are understood before the real system is built.

Once the issues are resolved, the project moves into design and implementation.

At this point, the design prototypes are thrown away, which is an important difference between these methodologies and prototyping methodologies, in which the prototypes evolve into the final system.

26

Pros & ConsPros Cons

Risks are Minimized May Take LongerThan Prototyping

Important Issues areUnderstood Before the

Real System is Built

27

Agile DevelopmentThese programming-centric methodologies have

few rules and practices, all of which are fairly easy to follow.

They focus on streamlining the SDLC by eliminating much of the modeling and documentation overhead, and the time spent on those tasks

Projects emphasize simple, iterative application development.

Example: extreme programming (XP)

28

Agile Development: Extreme Programming

Is founded on four core values: communication, simplicity, feedback, and courage.

These four values provide a foundation on which XP developers use to create any system.

First, the developers must provide rapid feedback to the end users on a continuous basis.

Second, XP requires developers to follow the KISS principle.

.

29

Third, developers must make incremental changes to grow the system and they must not only accept change, they must embrace change.

Fourth, developers must have a quality first mentality. XP also supports team members in developing their own skills

30

XP Key PrinciplesThree of the key principles that XP uses to create

successful systems are Continuous testing, simple coding performed by pairs of developers, and close interactions with end users to build systems

very quickly.

An XP project begins with user stories that describe what the system needs to do.

Then, programmers code in small, simple modules and test to meet those needs.

31

Users are required to be available to clear up questions and issues as they arise.

XP projects deliver results sooner than even the RAD approaches, and they rarely get bogged down in gathering requirements for the system.

32

Pros & ConsPros Cons

Fast Delivery of Results Requires Discipline

Works Well in ProjectsWith Undefined or

Changing Requirements

Works Best in Small Projects

Requires MuchUser Input

33

Selecting the Appropriate Development Methodology

1. Clarity of User Requirements

2. Familiarity of Technology

3. System Complexity

4. System Reliability

5. Short Time Schedules

6. Schedule Visibility

34

Which Methodology to Use?

35

Automated Tools for System Development

Computer-aided software engineering (CASE) is a category of software that automates all or part of the development process.

Some CASE software packages are primarily used during the analysis phase to create integrated diagrams of the system and to store information regarding the system components (often called upper CASE).

Whereas others are design-phase tools that create the diagrams and then generate code for database tables and system functionality (often called lower CASE).

36

Objectives of CASEImprove quality of systems developed

Increase speed of development and design

Ease and improve testing process through automated checking

Improve integration of development activities via common methodologies

Improve quality and completeness of documentation

Help standardize the development process

Improve project management

Simply program maintenance

Promote reusability

Improve software portability

37

Benefits of CASEThe benefits to using CASE are numerous.

Tasks are much faster to complete and alterDevelopment information is centralized Information is illustrated through diagrams,

which typically are easier to understand. CASE can reduce maintenance costsImprove software quality, and enforce

discipline, and some project teams even use CASE to assess the magnitude of changes to the project.

38

The central component of any CASE tool is the CASE repository, otherwise known as the information repository or data dictionary.

The CASE repository stores the diagrams and other project information, such as screen and report designs, and it keeps track of how the diagrams fit together.

For example, most CASE tools will warn you if you place a field on a screen design that doesn’t exist in your data model.

As the project evolves, project team members perform their tasks using CASE.

39

SummaryThere are several methodologies that can be use

to develop system:-WaterfallParallelPhased DevelopmentPrototypingXP

Criteria for selecting the appropriate methodologies:-Clarity of user requirementsFamiliarity with technology

40

System complexitySystem reliabilityShort Time schedulesSchedule Visibility

Automated Tools System DevelopmentCASE ToolsObjectives of CASE ToolsBenefits of CASE

41