SYSTEM AND DESIGN 4

System Analysis and Design Unit 7

Sikkim Manipal University Page No. 146

Unit 7 System Development Methodologies

Structure: 7.1 Introduction

Objectives

7.2 System Development Methodologies

7.3 Structured Design

Waterfall development

Parallel development

7.4 Rapid Application Development

Phased development

Prototyping

Throwaway prototyping

7.5 Current Methodologies: Agile Development

Extreme programming

Scrum

7.6 Selecting the Appropriate Development Methodology

Clarity of user requirements

Familiarity with technology

System complexity

System reliability

Short time schedules

Schedule visibility

7.7 Summary

7.8 Glossary

7.9 Terminal Questions

7.10 Answers

7.11 References

7.1 Introduction

Till now, you have covered various aspects of System Analysis and Design

such as data, information, various attributes, architecture, development life

cycle and design. In the previous unit, you studied the concept of system

design and came to understood various terms related to system design like

system implementation, system evaluation, and system modification. We

also described to you the process of modularisation in structured design and

illustrated the concept of input design, output design and form design.



In this unit, we will reflect on system development methodologies. We will

focus on recognising development methodologies such as structured design

including waterfall development, parallel development, etc., and rapid

application development including phased development, prototyping, etc.

You will also study the latest or current development methodology, that is,

agile development, which is still in the evolving state. We will also reflect on

selecting appropriate development methodology according to the

requirements.

A system development methodology can be defined as a procedure of

performing all the steps required to analyse, design, implement, and

maintain information systems.

Till now, different types of system development methodologies have been

developed. Every development methodology has its own strong points and

weak points. A single development methodology cannot be used for all the

projects. There are different types of system development methodologies

which are well-matched to specific types of projects. These are applied

according to the different technical, project and team concerns.

Objectives:

After studying this unit, you should be able to:

identify various system development methodologies

illustrate latest development methodologies

describe different categories of rapid application development

recognise how to select appropriate development methodology

7.2 System Development Methodologies

An approach utilised in executing the system development life cycle is

considered as system development methodology. Every methodology is

distinctive due to its variable importance in processes and data. Another

reason for this distinctiveness is the order and focus the methodology puts

on every System Development Life Cycle (SDLC) phase.

Various methodologies are considered as formal standards utilised by

different types of organisations. Other methodologies have been developed

by consulting companies especially for consumers. Still other organisations

have their own in-house methodologies that have been improved over the

years.



All system development methodologies include a demonstration of the

system concept in terms of processes and data. But, they vary in terms of

whether the methodology provides more importance to business processes

or to the data used in the business. Thus, these methodologies can be

divided into three types; process-centred, data-centred and object-oriented.

Process-centred methodologies: These define the activities connected

with the system. These activities are termed as the processes. Process-

centred methodologies make use of process models as the basis of the

system concept. The main focus of analysts is on illustrating the system

concept as a set of processes with information flowing in and out of the

processes.

For example, in figure 7.1, details of pay check flow into the process of

producing pay checks, and result in generation of pay checks as output. See

figure 7.1 for illustration of activities and information utilised in developing

the payroll for an organisation. In the figure, Data storage is shown in the

open-ended rectangles. Curved rectangles symbolise activities carried out

and arrows symbolise inputs and outputs of an activity.

Figure 7.1: A Simple Model of Employee Payroll



Data-centred methodologies: These define the contents of the data

storage boxes and the method of organising the contents. Data-centred

methodologies make use of data models as the basis of the system

concept.

For example, the focus of analysts is mainly on recognising the data that

must be obtainable to generate the payroll and converting that data into

well-defined structures such as employee, employees pay history, employee

pay rates, work log, payroll tax tables, etc.

Object-oriented methodologies: These balance the focus between data

and processes. Object-oriented methodologies make use of the Unified

Modelling Language (UML) to depict the system concept as a compilation of

objects including both data and processes.

Categories of system development methodologies

A significant factor in the categorisation of methodologies is placing the

SDLC phases in order and the amount of time and attempt dedicated to

each phase.

The necessity for formal and well-planned life cycle methodologies was not

well known in the early years. Earlier programmers used to move directly

from a very simple planning stage to the construction step of the

implementation stage. Alternatively, they moved directly from a very vague,

not-well-planned-out system request to the writing code.

This approach is similar to the approach that you may at times utilise while

writing programs for a programming class. It can work for small programs

requiring only one programmer. You may overlook significant elements of

the problem in case of difficult requirements, and you have to initiate the

whole process again, discarding a part of the program (and the time and

attempt spent on it).

This approach also makes teamwork difficult since members have little idea

regarding what requirements to be attained and how to work together to

generate a final product.

So, a new approach was developed towards the systematic categorisation

of system development methodologies. These major categories are:

Structured Design

Rapid Application Development (RAD)

Agile Development.



Each category stands for a collection of methodologies that tries to improve

on earlier practice. You will study these categories of system development

methodologies in the following sections.

Self Assessment Questions

1. ___________________ methodologies define the activities associated

with the system, namely, the processes.

2. Data-centred methodologies use processes as the basis of the system

concept. (True/False)

7.3 Structured Design

Structured design methodology is one of the earliest types of system

development methodologies. Structured Design methodologies came into

existence in the 1980s, substituting the earlier unplanned and

unmanageable procedures. A step-by-step procedure is developed for

moving from one level to the other level.

To illustrate fundamental processes of a system and the data that assists

them, a formal modelling or diagramming method is used by structured

design. Traditional structured design makes use of one set of diagrams to

correspond to the processes (process models) and a separate set of

diagrams to symbolise data (data models). As two sets of models are used,

the systems analyst must make a decision regarding which set to produce

first and apply as the basis of the systemprocess models or data models.

The issue of whether to provide importance to processes before data or

data before processes is a point of discussion among system analysts. This

is because all types of models are significant to the system.

Structured design is further categorised into Waterfall Development and

Parallel Development which you will study in the following sections.

7.3.1 Waterfall development

Waterfall development is considered as the original methodology of

structured design, which is still used today. Waterfall Development

methodology develops the system methodically from one phase to another

in a downward manner, similar to a waterfall.

Ankit PrajapatiHighlight



See figure 7.2 to know how the analysts and users progress from one stage

to the other in the form of a series.

The main deliverables for each stage or phase are usually capacious

(frequently hundreds of pages in length). These are supplied to the project

sponsor for approval as the project moves from one stage to another. Once

the sponsor approves the work that was performed for a phase, the phase

terminates and the next phase starts.

Figure 7.2: Waterfall Development-based Methodology

Even though all the phases tend to go back to the previous phase in the

SDLC (for example, back to analysis from design), it is very difficult to

visualise it as it seems like imagining a fish attempting to swim upstream in

a waterfall.

One of the benefits of waterfall development is that system needs are

recognised much before programming starts. Another benefit is that the

changes to the requirements are diminished as the project continues.

One of the drawbacks of waterfall development is that there is a need of a

fully specified design before programming starts. Another drawback is that

there is a long time gap (generally many months or years) between the

completion of the system proposal in the analysis phase and the delivery of

the system. The deliverables frequently suffer due to a deprived

communication method, thus significant requirements are ignored in the

documentation.










Users are not often prepared for their introduction to the new system, which

appears long after the preliminary idea for the system was introduced. If the

project team ignores significant requirements then costly post-

implementation programming may be required.

For example: Visualise yourself attempting to design a car on paper; how

likely would you memorise to contain interior lights that come on when the

doors open or to state the right number of valves on the engine?

These days the dynamic business world frequently causes quick

environmental variation in businesses. A system that fulfils current

environmental situations throughout the analysis phase may require

considerable rework to go hand in hand with the environment when it is

implemented. This rework needs going back to the preliminary phase and

making the changes required while moving through each of the succeeding

phases in order.

7.3.2 Parallel development

Parallel development methodologies reduce the long time interval between

the analysis stage and the system delivery. You can perform a general

design for the whole system rather than performing the design and

implementation in steps. You can then divide the project into a series of

different subprojects. This way you can perform the design and

implementation of these different subprojects in parallel.

After the completion of all subprojects, there is a concluding integration of

the different portions, and then the system is delivered. Check out figure 7.3

for the same. The main benefit of these methodologies is that the schedule

time necessary to deliver a system is reduced. Therefore, there is less

chance of rework as the possibility of changes in the business environment

is less.












Figure 7.3: A Parallel Development-based Methodology

Due to long deliverables, the procedure still goes through difficulties. It also

includes some new problems which are stated below:

At times the subprojects are dependent on each other to some extent.

Design decisions prepared in one sub-project may influence another.

The end of the project may include important integration challenges.


3. In ____________________ based methodologies, the requirements of

system are recognised much before the beginning of programming.

4. ___________________ methodologies include addressing the long

time interval among the analysis stage and the system delivery.

5. In parallel development, the schedule time required to make a delivery

of a system is increased. (True/False)

7.4 Rapid Application Development

To overcome the weaknesses of structured design methodology, a newer

class of system development methodology came into existence in the

1990s. This class of system development methodology is known as Rapid

Application Development (RAD). RAD-based methodologies work on the

adjustment of system development lifecycle phases. This is done to develop

a portion of the system quickly and deliver it to the users. This enables









users to understand the system in a better way, and then they offer their

reviews which help in developing an exact system as needed by the users.

Various methodologies of rapid application development (RAD) suggest that

analysts make use of particular methods and computer tools to make the

analysis, design, and implementation phases faster. Computer-aided

software engineering tools, code generators, and, joint application design

(JAD) sessions are some of the tools that are used to generate programs

from design specifications.

The grouping of the changed SDLC phases and the utilisation of these tools

and techniques enhances the speed and quality of systems development.

Handling the expectations of a user is one of the difficulties that generally

occur with rapid application development.

As systems are generated more quickly, the users acquire a better insight of

information technology. This increases the expectations of the users, thus

increasing the system requirements throughout the project. This was not a

case with structured design methodologies. In structured design

methodologies, only small change was permitted after the recognition of

system requirements.

Now let us study the different categories of RAD.

7.4.1 Phased development

The phased development-based methodologies are used to divide the

system into a series of versions that are developed in sequence. The

system concept, on the whole, is identified by the analysis phase. The

necessities are then separated into a series of versions by the project team,

users, and system sponsor.

The first version of the system includes the most significant and basic

requirements. After the analysis phase, design and implementation phases

are performed. This must include the set of necessities recognised for

version 1. See figure 7.4 for a detailed phased development methodology.









Figure 7.4: A Phased Development-based Methodology

After the implementation of version 1, work begins on version 2. From the

users experience with version 1, analysis is performed further on the basis

of the previously recognised requirements. This additional analysis is

merged with new ideas and issues identified from the version 1 experience.

This leads to design and implementation of version 2 and work on the next

version starts immediately. This procedure goes on till the completion of the

methodology.

One of the benefits of phased development-based methodologies is rapid

delivery of a useful system to the users. Even though it does not perform all

the functions required by the users at first, it begins to supply business

value. This is not a case with the waterfall or parallel methodologies where

the system is provided to the users, only after the achievement of all the

requirements

As users start using the system sooner, they are prepared beforehand to

identify some significant additional requirements as compared to the

structured design conditions.

The main disadvantage of phased development is that users start using the

systems that are not in the complete form yet. So, it becomes necessary to

recognise the useful traits and include them in the first version when

managing users requirements along the way.







7.4.2 Prototyping

The prototyping-based methodologies carry out the analysis, design, and

implementation phases at the same time, and these are performed

frequently in a series till the completion of the system. Basic analysis and

design phases are carried out in prototyping, and work instantly begins on a

system prototype, which can also be called as a quick-and-dirty program

having negligible features.

The first part of the system, which is used by the user, is generally included

in the first prototype. This is displayed to the users and the project sponsor,

who offer response and comments. This reaction is used to reanalyse,

redesign, and re-implement a second prototype that offers a few more traits.

This process goes on in a series until the analysts, users, and sponsor

agree that the prototype offers sufficient functionality to be installed and

utilised in the organisation. After the installation of prototype, refinement

takes place and then it is accepted as the new system. See figure 7.5 for

this process.

Figure 7.5: A Prototyping-based Methodology

The main benefit of a prototyping is that it offers such a system to the users

which can be used instantly for interaction, though it is not initially ready for

extensive organisational use.

Prototyping assures the users that the project team is continuing work on

the system. The approach aids in refining the actual requirements more










rapidly. Instead of trying to recognise system specification materials, the

users can communicate with the prototype to identify its traits in a better

way.

The main trouble with prototyping is that its fast-paced system challenges

efforts to perform cautious and systematic analysis. Frequently, the

prototype goes through such major changes that many preliminary design

decisions are not considered to be good ones. This can create problems in

the development of complex systems since fundamental concerns and

problems are not known until well into the development process.

For example, imagine building a car. In finding out late in the prototyping

procedure, you have to take out the full engine to change the oil (as the

requirement to change the oil came into observation only after driving the

car for 10,000 miles), the same thing can happen in prototyping of systems.

7.4.3 Throwaway prototyping

Throwaway prototyping methodologies are comparable to the prototyping

methodologies as they comprise the development of prototypes. However,

throwaway prototypes are prepared at various stages in the SDLC. On

comparing with the prototypes discussed previously, throwaway prototypes

are utilised for an extremely diverse reason. Check out figure 7.6 for

throwaway prototypes which have a very dissimilar appearance.

Figure 7.6: A Throwaway Prototyping-based Methodology



A comparatively detailed analysis phase is included in these methodologies.

This analysis phase is used to collect information and to produce ideas for

the system concept. Many of the traits recommended by the users may not

be well recognised, however, and there may be challenging technical

concerns to be solved. Each of these concerns is inspected by analysing,

designing, and building a design prototype.

This is to note that a design prototype, as shown in figure 7.6, is not a

functioning system. It is a product that signifies a part of the system that

requires additional refinement, and it encloses only sufficient detail to allow

users to recognise the issues under consideration.

For example, assume that users are not completely familiar with how an

order entry system should work. The analyst team might make a series of

HTML pages accessible by means of a Web browser to assist users in

visualising such a system. Here, a series of mock-up screens looks like a

system, but they actually do nothing. Or, assume that there is a need to

develop a complicated graphics program in Java by the project team. The

team could write a part of the program with artificial data to make sure that

they could create a full-blown program effectively.

A system generated from throwaway prototyping most likely uses various

design prototypes throughout the analysis and design phases. Each of the

prototypes is utilised to diminish the risk connected with the system. This is

done by verifying that significant issues are recognised before the actual

system is built.

After resolving issues, the project moves into design and implementation.

Here, the design prototypes are cast away, which is imperative vital

dissimilarity between this approach and prototyping, in which the prototypes

develop into the final system.

The advantages of carefully planned phases (analysis and design) together

with the advantages of making use of prototypes for refining main concerns

of developing a system are balanced by the throwaway prototyping

methodology.

It may take time to provide the final system to the users in contrast to

prototyping-based methodologies (as the prototypes do not turn out to be



the final system); however, the approach generally generates more steady

and consistent systems.


6. In phased development, the _____________________ phase identifies

the overall system concept.

7. A design prototype is a product that indicates a part of the system that

needs additional refinement. (True/False)

8. In case of most RAD-based methodologies, no special methods and

computer tools are used by analysts to make the analysis, design, and

implementation phases faster. (True/False)

7.5 Current Methodologies: Agile Development

Agile Development is one of the categories of system development

methodologies that are quite new. These methodologies are considered as

program-centric and comprise of some rules and practices which are quite

simple to follow. They concentrate on reforming the SDLC by removing

much of the modelling and documentation overhead and the time used up

on these tasks. As an alternative, projects highlight on simple, iterative

application development.

Extreme programming and Scrum are some of the examples of Agile

Development methodologies. To get a better idea about agile development

methodology, lets discuss extreme programming and Scrum in the next

sections.

7.5.1 Extreme programming

Extreme programming (XP) is based on the following core values:

Communication

Simplicity

Feedback

Courage.

These values offer a foundation XP that is used to generate any system.

Primarily, the developers must offer quick response to the end users on a

continuous basis and secondly, developers are required to keep it simple.

Then, developers must make additive alterations to grow the system and










they must embrace the change, not just accept it. Lastly, developers must

have a quality-first state of mind. XP also assists team members in

producing their own skills.

After a planning process, project teams carry out analysis, design, and

implementation phases iteratively. See figure 7.7 for the same.

Testing and competent programming practices are core to XP; each day

code is tested by keeping it in an integrative testing environment. If bugs are

present, the code is backed out. This testing continues until it is completely

free of errors. XP is based on re-factoring, which is a disciplined method to

reorganise code to make it simple.

Figure 7.7: An Extreme Programming-based Methodology

An XP project starts with user stories which illustrate the requirements that

the system should perform. Then, programmers perform coding in small,

simple modules and tests to ensure that the requirements are fulfilled. Users

are required to be accessible to clarify questions and issues as they occur.

Standards are considered to be significant to diminish confusion, so XP

teams make use of a general set of names, descriptions, and coding

practices.

XP work great for small projects with extremely motivated, consistent,

steady, and experienced teams. However, if there is lack of small projects or

qualified teams, then the probability of a successful XP project is reduced.

As a result, the use of XP together with outside contractors generates an














extremely problematical outcome. This is because the outside contractors

may never come together with insiders.

XP needs a great deal of discipline to avoid projects from becoming

distracted and disordered. Moreover, it is only suggested for the groups of

small developers and it is not suggested for mission-significant applications.

There is only code documentation as slight analysis and design

documentation is generated with XP. So, preservation of large systems

generated by means of XP may be not possible. In addition, as mission-

significant business information systems are likely to exist for a longer

duration, the utility of XP as a business information system development

methodology is unsure. Lastly, the methodology needs significant on-site

user input that is often difficult to attain.

7.5.2 Scrum

Scrum is another agile approach. The term is derived from the game

Rugby. Scrum is the method of starting play in which play starts when the

ball is thrown in between the forwards of both teams and the two sides

compete for possession.

The systems development interpretation of Scrum calls for the same

dedicated interaction. In a Scrum session, agile team members have

particular roles, having identifications such as chickens or pigs.

These roles are based on an old children story about the chicken and pig

who are talking about an eating house where eggs and ham would be

served. Nevertheless, the pig refuses, since that role would call for total

commitment, while for the chicken, it would only be a part input.

In the agile development, the pigs are the facilitator, product owner and the

development team; while the chickens are users and other stakeholders.

Scrum sessions have precise guidelines that emphasise time interaction,

and actions that result in deliverable system.

Agile Method Advantages & Disadvantages

Very flexible and efficient in dealing with change

Stress on team interaction

Reflect set of community-based values

Frequent deliverables constantly validate the project






Members need a high level of technical skills

A lack of structure can introduce risk factors

Project may be subject to significant change in scope

User requirements continue to evolve during the project


9. __________________ methodologies are referred as program-centric

and comprising of few rules and practices.

10. On small projects, the probability of a successful XP project is reduced.

(True/False)

7.6 Selecting the Appropriate Development Methodology

From the number of methodologies, the first challenge for analysts is to

decide the methodology to be used for developing a system. Selecting a

methodology is not easy, since any one methodology is not always the best.

Some standards and policies are followed by an organisation to conduct the

selection of methodology.

Check out figure 7.8 for some important criteria for the selection of

methodology.

Figure 7.8: Criteria for Selecting a Methodology



Frequently, these tools and techniques raise the complexity of the project

and need additional time for learning. However, the team turns out to be

experienced, once they are adopted. The tools and techniques can

significantly enhance the speed in which the methodology can provide a

final system.

Now, let us discuss the factors considered for selecting the appropriate

development methodology.

7.6.1 Clarity of user requirements

When the user is uncertain and not clear about his requirements from a

system, it becomes difficult to recognise these requirements by discussing

about them and illustrating them in written reports. Users are usually

required to interact with technology to actually identify what the new system

can do and how to apply it in the best way to suit their requirements.

The RAD methodologies of prototyping and throwaway prototyping are

generally more suitable when the requirements of a user are uncertain since

they offer prototypes to users for interaction, early in the SDLC. Agile

development may also be suitable if on-site user input is accessible.

7.6.2 Familiarity with technology

When a new technology is used by the system, and the technology is not

known by the analysts and programmers (for example, the first Web

development project with Java), then the possibility of success can be

improved by applying the new technology early in the methodology.

Throwaway prototyping methodologies are mainly suitable for such cases of

technology non-familiarity. This is because they explicitly support the

developers to generate design prototypes for regions having high rate of

threats. Phased development methodologies are also fine since they

generate chances to examine the technology deeply before completing the

design.

In case of prototyping-based methodologies, they are much less suitable,

since the early prototypes that are developed generally are not able to

access the new technology. The developers find out weaknesses or

difficulties in the new technology only after numerous prototypes and

numerous months.



7.6.3 System complexity

Complex systems need cautious and thorough analysis and design.

Throwaway prototyping methodologies are mainly suited for such thorough

analysis and design, but prototyping-based methodologies are not at all

suitable for such systems. Complex systems can be managed by the

traditional structured design methodologies.

But some main concerns may get unnoticed without the ability to hand over

the system or prototypes into users hands early on. Even though the

phased development-based methodologies allow users to interact with the

system quite early in the process, we have noticed that project teams who

follow these methodologies are likely to give less attention to the analysis of

the whole problem domain than they might if they were utilising other

methodologies.

7.6.4 System reliability

System reliability is one of the important factors in developing system. After

all, nobody requires an unreliable system. Sometimes reliability is really

significant for some applications (e.g., medical equipment, missile control

systems), whereas it is partially important for other applications (e.g.,

games, Internet video).

Throwaway prototyping methodologies are most suitable when system

reliability is the major concern. This is because they combine thorough

analysis and design phases with the capability for the project team to test

many dissimilar approaches via design prototypes before finishing the

design.

Prototyping-based methodologies are usually not a high-quality selection

when reliability is critical. This is due to the fact that they fall short of

cautious analysis and design phases that are essential for reliable systems.

7.6.5 Short time schedules

Projects comprising of short time schedules are well-matched for RAD-

based methodologies. This is because those methodologies are designed to

enhance the rapidity of development. Prototyping and phased development-

based methodologies are outstanding options in case of short timelines.

This is because they best facilitate the project team to adjust the

functionality in the system according to a particular date of delivery.



If the project schedule begins to slip, re-adjustment can be done by

eliminating functionality from the version or prototype under development.

Waterfall-based methodology is the worst option to choose when there is

shortage of time since they do not permit simple schedule variations.

7.6.6 Schedule visibility

Knowing whether a project is on schedule is one of the most significant

factors in developing system. This is mainly true of the structured design

methodologies since design and implementation take place at the end of the

project. Many of the important design decisions taken in case of the RAD-

based methodologies move previously in the project to assist project

managers identify and address risk factors and check the requirements.


11. Many organisations enclose standards and policies used for the

___________________ of methodology.

12. Throwaway prototyping-based methodologies are not appropriate when

system reliability is a high priority. (True/False)

13. Prototyping and ___________________________development-based

methodologies are good choices when timelines are short.

7.7 Summary

Let us recapitulate the important concepts discussed in this unit:

A system development methodology can be defined as a procedure of

performing all the steps required to analyse, design, implement, and

maintain information systems.

Structured design follows a step-by-step procedure for moving from one

level to the other level.

Waterfall development is considered as the original structured design

methodology where the analysts and users progress in sequence from

one phase to the next.

In parallel development methodologies, you can perform a general

design for the whole system rather than performing the design and

implementation in series.



RAD-based methodologies perform the adjustment of system

development lifecycle phases to obtain a portion of the system

developed quickly and deliver it to the users

The phased development-based methodologies are used to divide the

system into a series of versions that are developed in succession.

The prototyping-based methodologies carry out the analysis, design,

and implementation phases at the same time, and all three phases are

executed frequently in a series until the system is completed.

Agile Development is one of the categories of systems development

methodologies that are currently prevalent.

Extreme programming (XP) is based on the core values, that is,

communication, simplicity, feedback, and courage which offer a

foundation XP that is used by developers to generate any system.

Selecting a methodology is not easy, since any one methodology is not

always best. Some standards and policies are followed by an

organisation to conduct the selection of methodology.

7.8 Glossary

Agile development: The agile methodologies are programming centric

methodologies comprising of some simple rules which are followed

through a simple iterative development procedure.

Phased development: Phased Development methodology is used to

generate the system in a sequential manner in the form of separated

versions.

Prototyping: Prototyping builds a model of a system that is to be

developed.

RAD: The rapid application development (RAD) methodologies rapidly

obtain some part of the system and permit users feedback to make sure

that the whole system provides the correct requirements.

Waterfall development: It is a linear and sequential approach used in

software design and systems development.



7.9 Terminal Questions

1. Explain the concept of waterfall development methodology. Also discuss

the advantages and disadvantages of this methodology.

2. What is rapid application development (RAD)? Compare it with

structured design methodologies.

3. How does a prototyping-based methodology perform in the different

phases of SDLC? Illustrate.

4. Discuss the use of Agile Development methodology. Also explain the

concept of extreme programming.

5. Illustrate the process of selecting the appropriate development

methodology. Also discuss the various factors considered in selecting

the appropriate development methodology.

7.10 Answers


1. Process-centred

2. False

3. Waterfall development

4. Parallel development

5. False

6. analysis

7. True

8. False

9. Agile development

10. True

11. selection

12. False

13. phased

Terminal questions

1. In waterfall development methodology, the key deliverables for each

phase are usually capacious and are supplied to the project sponsor for

consent as the project moves from one phase to another phase. One of

the benefits of waterfall development is that system needs are



recognised much before programming starts. One of the drawbacks of

waterfall development is that there is a need of fully specied design

before programming starts. Refer section 7.3.

2. In case of RAD, the expectations of the users may increase thus

increasing the system requirements throughout the project. This was not

a case with structured design methodologies. Refer section 7.4.

3. The prototyping-based methodologies carry out the analysis, design,

and implementation phases at the same time, and all three phases are

performed frequently in a series until the system is completed. Refer

section 7.4.

4. Agile development methodology concentrates on reforming the SDLC by

removing much of the modelling and documentation overhead and the

time used on those tasks. Extreme programming (XP) is based on the

following core values: communication, simplicity, feedback, and

courage. Refer sections 7.5.

5. Selecting a methodology is not easy, since any one methodology is not

always the best. Various organisations contain standards and policies to

conduct the selection of methodology. Refer section 7.6.

7.11 References

D. E. Avison., Information systems development, McGraw-Hill.

Roy Hodgson., System development methodologies, Corporate Training

Pty Ltd.

MariteKirikova., Information systems development, Springer.

E-References:

http://akademik.bahcesehir.edu.

http://www.ecomval.gov.ph/IDforSAD/interactions/waterfall.html

http://www.ecomval.gov.ph/IDforSAD/interactions/parallel.html

http://www.ecomval.gov.ph

http://www.chrisshayan.com

SYSTEM AND DESIGN 4

Documents

system development methodology

single development methodology

concept of system design

system evaluation

system implementation

system modification

design unit

various methodologies