Development Methodologies Notes

Reading notes—Determine and select
appropriate methodology for a given

activity
Knowledge of client business domain

In order to utilise technology effectively, it must fit the user’s goals. It is no
good developing a database that manages stock when the requirement was
for a system that manages contacts of potential customers. To ensure that
you start on the right track, it is important to have an understanding of the
organisation’s business domain.
What is the client’s core business? Sometimes it is apparent what the

organisation’s core business is. Coca-Cola Company, for example, which
has a high profile worldwide, is in the business of producing non-alcoholic
beverages. For other organisations, the question of what the client’s core
business is is not always so straightforward. How can you find out what an
organisation’s core business is?
Documents produced at a high level in the organisation are usually a good

source of information for determining a company’s core business or
businesses. Mission statements, strategic goals and organisational charts are
good examples of these. A mission statement states the main purpose of the
organisation and usually incorporates its financial, social and/or
environmental goals. Organisational charts can provide a graphical
representation of the business in terms of how it is organised to fulfil its core
business.
Where can you find this information?
One place might be in the company’s annual report. Also, many businesses
are promoted today via the Internet, where this information may be made
available.
2842: Determine and select appropriate methodology for a given activity 1

© State of New South Wales, Department of Education and Training, 2006
Activity 1
To practice finding information about a client business domain, complete

Activity 1—Knowledge of client business domain in the Activities section of
the Topic menu.
Organisational features and functions

Understanding an organisation’s core business helps to put into context the
business itself. With this in mind, we can begin to look at the various
functional areas that form part of an organisation. All businesses perform
basic business functions such as the following:
 producing a product or service
 selling
 marketing
 accounting
 managing human resources.
This is usually the case regardless of an organisation’s size. In small

operations, these functions may be performed by one person. Larger
organisations may be organised around the business functions. Information
technology is another function of business that is becoming commonplace.
As well as these basic business functions, some organisations perform
functions that are common to other organisations or unique to that
organisation alone. Research and development, legal consultancy and
special projects are some examples of these.
Organisation structure
Referring to an organisation chart provides an insight into how the
business is organised and managed. Some organisations are arranged along
functional lines where each business function comes under its own
manager. Other organisations structure themselves along product lines or
geographical areas. Management type can also be gleaned from a
business’s organisational chart.
Organisations that have a lot of middle management tend to have tall

hierarchical structure charts, whereas flatter structure charts indicate an
organisation that has few middle-level managers. Middle managers in these
latter types of organisations are said to have a wide span of control. This
refers to the spread of authority a middle manager has over staff at an
operational level.
2 2842: Determine and select appropriate methodology for a given activity

Lines of communication
Formal lines of communication are another aspect depicted in an
organisational chart. This has significance when analysing the requirements
for a given area within an organisation and how it interacts with other
departments. This needs to be interpreted from an informal perspective as
well as a formal one.
Image: Organisational chart for Shark Publishing showing three levels of staff, with
managing director at the top, then two middle managers, and five staff on the
bottom level; each position and the current job holder is named
Figure 1: Example of an organisational chart
Reflect
The manager of the purchasing department of a company has now been

promoted to director of finance. Her position has been given to the manager
of accounting and in turn a new staff member has been employed to fill this
role. Does this restructure necessitate any change to the company’s
organisational documentation?
Feedback
Yes! The organisation chart will need to be redrawn to show the new
responsibilities. Any other business documents which reference the name of
the person in one of these roles will also need to be changed.

Lines of communication (continued)
Many businesses will already have an organisational chart of their business
structure which you will be able to use for this purpose. If not, one of your
first tasks should be to create one.
An organisational chart can be hand-drawn or a software program can be

used to create it. Microsoft Word has a feature to automatically create an
organisational chart in a document.
Other features of an organisation are reflected in its policies and

procedures as well as the culture of the work environment. For example,
does it adhere to the principles of EEO (equal employment opportunity)? Is
the dress code formal or informal? Is there a history of promoting from
within the organisation, or are positions sourced externally?
What does all this have to do with technology?
An understanding of an organisation’s structure and functions, as well as

how they interact, is essential for the organisation to be efficiently supported
by available technology. It is also important to be able to investigate and
select technology to support the organisation’s goals.
Reflect
An organisation has produced its statement of strategic goals for the next three
years. One of these goals includes a migration to e-business. What business
functions would be affected by such a goal?
Feedback
Basically, all of them! This particular goal will require some careful
planning and liaison between all functional departments and the IT
department.
Knowledge of current business functions

Although each type of business has functions and requirements that are
specific to the industry in which it operates, there are many functions that
are common to all businesses. Some of the common functions of a business
are discussed below.
Human resources (HR)

Human resources (HR) maintains information about the people who work
for the company. Within the HR area, there will be processes for handling
personnel functions and payroll functions.

The personnel processes includes keeping track of personal data about the
staff, such as address, date of birth, marital information, employment record,
position in the company, leave entitlements and skills details.
The payroll processes manage production of payslips and cheques,

including calculating pay for the period, tax and superannuation
contributions and storing information to meet the legal requirements of the
tax office.
Inventory
This area keeps track of all the items owned by the business. It records item
descriptions, quantities, locations and value.
There are two distinct types of items owned by a company:

 assets
 consumables.
Asset register
Assets are the items needed to carry out the organisation’s business, for
example the office furniture, computers and company cars. Since these
assets are often located in different areas of the company, an asset register
is needed to keep track of them.
Consumables can be of two different types—stock and parts—and

different processes are required to handle them.
Stock inventory
This keeps track of the products that the business has manufactured and
sold. It is important to maintain accurate records of these details for analysis
of what the company should produce in the future. For example, there is no
reason for a car manufacturer to keep producing one hundred red four-wheel
drive vehicles every week if the company has only sold fifty in the previous
year. It would make more sense to change production schedules to make
more green four-wheel drives if the company sold five hundred green
vehicles last year but currently only makes ten a week.
Parts inventory
A parts inventory keeps track of all of the parts that are used to
manufacture the company’s products. Some examples of parts may be the
wheels, spark plugs, bolts and doors that are used to manufacture a car. It is
important to keep track of what parts the business has so that there will be
no delays in production because the necessary parts are not available. This
area is crucial to the efficient running of the production side of the business.

A typical parts inventory function would include the following:
 a parts issue process which issues parts to the rest of the business
 an inquiry process to allow staff to check on current levels of
inventory
 a stock take process to check for discrepancies between actual and
recorded inventory levels
 an ordering process which is responsible for ordering parts from
suppliers when necessary; this involves keeping statistics on usage
of parts, details of suppliers and how long it takes them to deliver the
parts
 once parts have been delivered to the company, the parts delivery
process will add the parts received to the current stock record and
provide the accounting area with details of these so that payment can
be made to the suppliers.
The following chart shows a typical parts inventory function:
Image: Inventory chart with ‘Inventory’ in the top level box and ‘Parts Issue’
‘Ordering’ ‘Delivery’ ‘Inquiry’ and ‘Stock take’ in the six boxes on the second level.
Figure 2: Inventory function chart
Finance
The finance area keeps track of all the financial aspects of the business.
The most common processes are:

 accounts receivable
 accounts payable.
Accounts receivable
This function keeps track of money owed to the business. It creates

invoices when goods are sold, checks the customer’s credit limit, records
payments that have been made against the invoices and sends reminders for
overdue payments.

Accounts payable
This function keeps track of the money owed by the company. This
involves recording all orders raised by the business and checking the details
against goods and invoices received from suppliers. Payment is made once
details have been checked.
General accounts
This function handles the funds used within a business and generates reports
detailing the use of assets and resources. It includes preparation of budgets
for departments within the business, monitoring spending and producing
annual income and expenditure figures.
Marketing
Marketing has two functions: one is to sell the company’s products or

services and the other is to determine what products or services to sell and
who to sell them to. Determining what to sell and who to sell to is termed
market research and may involve market surveys which ask people about
their preferences for certain products.
The sales function will involve identifying the best place and method for
selling the company’s products or services and may include selling in a
store, by phone or mail order or via the Internet.
Production
This function is found in all businesses that produce a physical product. The
company will usually have one or more factories where the product is
manufactured using consumable items. The product is then sold to
customers.
Processes involved in this area include scheduling, i.e. a plan of what

product or part of a product will be made by what machines at what times.
This plan will then be used to determine what parts are needed, where and
when they are needed. The plan can also be used to provide details of the
staff that are required.
Activity 2
To practise finding out information about a client business domain,

complete Activity 2—Obtain knowledge of the client business domain in the
Activities section of the Topic menu.

Reflect
Think about a business that you have worked for. What business functions did it
have? What business functions did it have that were specific to that
industry?
Feedback
When trying to define a business problem, it is important to identify which
business functions are involved and the links between them.
Some functions will be core business functions, which mean that they are
critical to the running of the business. It’s important to identify which the
core business functions are in order to ensure that any proposed solution will
take into account the critical nature of these functions in the overall business
environment.
Role of stakeholders
A stakeholder is someone who holds an interest in something. In this topic,
a stakeholder refers to a person who has an interest in, or is affected by, the
business problem that is being investigated.
Imagine that your local bank branch is being forced to close.

 Who would be directly affected by this action?
 Who would be indirectly affected?
 Who would have an interest in ensuring that the branch stayed open?
 Who would have an interest in ensuring that the branch was closed?
There are a lot of people who have a stake in the closure of a bank branch.
Some of the groups of people who would be directly affected include the
following:
 the bank’s customers in particular
 older people or people with special needs who do not like to use
ATMs, phone banking or Internet banking
 local businesses who rely on a nearby branch to meet their
operational banking needs
 people without transport and low-income earners who can walk to
their local branch or who need only travel a short distance to do their
banking
 the bank’s employees, who may lose their jobs.

Some of the groups of people who would be indirectly affected include the
following:
 local businesses who often find that customers will shop in larger
centres where a bank branch is still operating
 the community, which often suffers when services are not available
locally; the possibility exists that other essential community services
may also be relocated to larger centres
 community groups who may be concerned that the sense of
community is at risk when daily interaction between residents is
distributed further afield, away from local community centres.
Some of the groups of people who have a stake in ensuring that branches
stay open include the following:
 the greater community, which may be concerned that bank service
levels and the needs of the community are becoming secondary
priorities to bank profit and financial image
 politicians, who represent the needs of the community and local
businesses
 government departments who deal with people who may be affected,
particularly those who would be disadvantaged by a bank’s closure
 other small business centres, who see that they may be at risk of
losing their banking facilities as well.
Some of the groups of people who have a stake in ensuring that branches are
closed include the following:
 the bank’s management and board of directors
 the bank’s investors and shareholders
 larger shopping centres that may benefit from increased custom.
As you can see, one event can have an impact on many people.
Who are the stakeholders?

If an IT solution to the problem is being considered, stakeholders may
include the following:
Those directly affected

 The client
 Affected users
 IT staff working on the project or associated projects
 Managers of the affected business area

 Steering committees.
Those indirectly affected

 IT staff working on associated projects
 IT management.
Interested parties
 The managers of other departments
 Company directors
 Managing director.
Management has an indirect but controlling stake in any project that is

initiated within the company. Many companies also have a steering
committee for IT projects. This committee determines the direction of
projects or initiatives within the company.
Upper management or a steering committee are usually the primary

stakeholders and have the final say when projects are signed off for
acceptance.
Why is it important to ensure that upper management are adequately

informed about the status of a project, changes that will have an impact on
the project, and additional risks and implications that have become apparent
during the analysis and design phases?
Obviously, upper management will not be checking to see that design

documents are in order; however, they read the status reports, take
recommendations from other management and team leaders and ensure that
projects are in place in order to deliver the business benefits that were
identified during the project start-up phase. Changes to schedules, increased
risks to projects and impacts on quality or budget are of interest to upper
management. At the end of the day, they are responsible for where money is
spent within the company and, with accurate information, they can assess
the benefits to the company of projects and initiatives.
It is necessary to understand the types of stakeholder and to ensure that:

 you don’t forget about any type of stakeholder
 you have a representative of each type of stakeholder that has the
authority to sign off requirements for their group.
You may use a table like that shown in Table 1 below as a checklist to
ensure you are not missing any categories of stakeholder.

Table 1: Checklist of stakeholder categories
Category Stakeholders Representatives
Sponsors Kim Woo (Head of

Investment)
Project managers Jill Anderson
External supplier –
Internal supplier Fran Keating (IT Manager)
Infrastructure IT Grace Lam (NSW Systems
Manager)
Test team Anthony Farrelly (Investment
Systems Test Lead)
End users—Fixed Analysts: Avril Smith
interest front office
Avril Smith, Lidija Rossi,
Michael Boynton
End users— Analysts: Anthony Wong
Australian equities
Quinton Jones, Terrence
front office
Brown, Anthony Wong
Each project will have different types of stakeholders depending on the size
of the project and the type of organisation. See Figure 3 for an example of
stakeholders in a project.

Image: Diagram showing stakeholders in proposed system (as inner circle)
surrounded by outer circle with stakeholders such as Systems administrator
(system maintenance), Users (reservation clerks around Australia), Bus drivers
(get reports from the system), CEO (needs the system to deliver cost savings), and
Software supplier (who builds the system)
Figure 3: An example of the stakeholders involved in the BIGBUS reservation

system
End users
The stakeholders who will usually have the most involvement in the
development process are the end users. These are the people who will use
the system being developed on a regular basis, either to enter information
into the system or to get information out of the system as a means of
performing their normal business functions.
Categories of end users
You need to ensure that you consider possible differences between end
users.
For example:
 Are the users geographically separated?
 Are there different levels of access to information?
 Are there users who provide support for the system?
 Are there users who are outside the organisation?
 Are there large numbers of users, for example the public?
Consider unusual types of end users
Where users are outside the organisation or there are large numbers of them,
the process of selecting representatives may require planning. For example,
if you are building a public Internet site, how are you going to ask your
users what their needs are?
It is likely that someone within the organisation will be given the role of
representing the needs of these users. This person should have a vested
interest in ensuring the external users are looked after. For example, the
sales manager would make a good representative for these users, whereas
the head of infrastructure would not.

Verify your research
The process of documenting the stakeholders often involves a process of
navigating through an organisation a little bit at a time. As you speak to one
stakeholder, others may emerge, so continually look for verification that you
haven’t missed anyone. This may not need be the case if you know the
organisation well.
If a stakeholder is discovered later in the course of developing requirements,

they will have to be considered, so take the time to do this job well now!
Activity 3
To practise identifying stakeholders, complete Activity 3—Identify

stakeholders in the Activities section of the Topic menu.
System development methodologies

A system development methodology describes the techniques, tools, roles,
deliverables, standards and activities for the development of a system.
Development methodologies aim to standardise the process by defining both
the steps to be taken and the order in which they need to be performed.
This is called the System Development Life Cycle or SDLC.
System development life cycle (SDLC)

What is the SDLC?
Let’s firstly consider what a life cycle is. We usually use the term ‘life
cycle’ to refer to natural systems such as marine ecosystems, where the
growth of fish, coral reefs, plankton and predators are all described in
relationship to each other.
Think how you would describe the life cycle of a butterfly. The life cycle is
a series of changes or stages that occur in the lifetime of the butterfly.
A simple life cycle for a butterfly might be similar to the one depicted in
Figure 4.

Image: Circular diagram illustrating the life cycle of a butterfly. The word ‘birth’ is at
the top outside the circle and includes ‘egg’ and ‘egg hatches’. The next stage in
the cycle is ‘growth’, which includes ’caterpillar’ and ‘metamorphosis’. This is
followed by the stage called ‘life’, which includes ‘butterfly’, ‘mates’, ‘lays eggs’. The
final stage in the cycle on the circle is ‘death’, which includes ‘dies’.
Figure 4: Life cycle of a butterfly
In a similar way, computer systems have a life cycle. They are bought,
installed, used for a while, possibly upgraded, and eventually thrown away
when a better product comes on the market.
When you develop computer systems, you can identify a set of stages that
are required from the recognition of a specific need to the implementation
and eventual retiring of the system.
Current development methodologies

There are four basic features of development models that we will be
considering:
1. The role of business users and their contribution to systems
development
2. Linear versus non-linear task flow
3. Iterative versus non-iterative nature of the life cycle—the ability to
revisit and reassess different stages of the SDLC
4. Monolithic or staged delivery—the ability to phase the
implementation and delivery of a system
There are many different development methodologies that are currently used
within the industry. Some of the most popular system development
methodologies currently in use include the following:
 traditional SDLC or waterfall
 iterative

 Rapid Application Development (RAD)
 incremental
 evolutionary.
Traditional SDLC or the waterfall model

As the name implies, the traditional SDLC or waterfall model development
consists of a sequentially ordered set of stages where one stage naturally
flows downhill into the next. See Figure 5.
A waterfall SDLC requires one stage to be completed fully before starting

on the following stage. It can be quite difficult to go back and make changes
to the output or deliverables once a stage has been completed.
For example, the outcome of the requirements-gathering stage is the

modelling and documentation of the requirements. In the design phase, the
models and requirements are interpreted and the actual design for the system
is then developed. If the requirements change, this directly affects the design
process.
Image: Diagram of a waterfall SDLC model with one computer on the bottom left
and another at top right. A series of boxes decline from top left to bottom right with
connecting arrows. The boxes, from top to bottom, are ‘Project concept’,
‘Requirements analysis’, ‘Design and architecture’, ‘Build’, ‘Testing and
deployment’, ‘Maintenance and enhancement’, and finally ‘Retirement’.
Figure 5: Waterfall SDLC model
The waterfall model developed as a way of freezing requirements and

design since the cost of implementing a system was once extremely
expensive. Major changes to requirements would arrest the huge process of
coding and building the system. The waterfall model prevented the
development from being placed into a constant state of incompleteness.

The reality of almost all computer systems is that fixed requirements do
not exist. Analysts often find that the processes of developing the system,
expanding a design or implementing a report help them discover issues and
pose new questions that change the requirements.
As development tools have become cheaper, easier to use and allow faster
implementation, the idea of forcing developers to reject changing
requirements no longer makes sense. This has given rise to alternative
development methodologies that take into account the fact that requirements
are rarely ever stable and realistically cannot be frozen if the resulting
system is to meet a real business need.
Many aspects of the waterfall model are still useful in modern development
methodologies; however, the idea of large applications development has
been almost entirely supplanted by smaller-sized projects that are iterative
and take advantage of user-interactive methods.
Iterative development models
Iterative development models enable changes in requirements to be

incorporated into the process by repeating a stage in the SDLC. The diagram
in Figure 6 is simply a modified waterfall model that has arrows that go
back to previous stages.
Image: Graphic with computer in top right hand side. The boxes, from top to
bottom, are ‘Project concept’, ‘Requirements analysis’, Design and architecture’,
‘Build’, and ‘Testing and deployment’.
Figure 6: Modified waterfall model
Most of the commonly used SDLCs have an iterative component. You can
see in Figure 6 that if an issue is discovered during the testing phase, we can
go back to the design or build stages. In some cases, it may even be
necessary to review the requirements based on the testing findings.

Rapid application development (RAD)
Image: Graphic with computer on the left and boxes above with the words ‘Project
concept’ leading to the computer, and then to a box for ‘Requirements prototype’
and then flowing to boxes on the right for ‘Analysis’, ‘Design and architecture’,
‘Build’, ‘Testing and deployment’, ‘Maintenance and enhancement’, and finally
‘Retirement’. The arrows flow from one box to the next in only one direction
Figure 7: Rapid development model
Some projects are more suited to a RAD style of system development,

which focuses on creating prototypes that can be used in production if they
prove useful. If a prototype is not useful, it is either improved or discarded
and a new prototype created.
In general, RAD methods emphasise getting a quick return for the money
invested in developing software. They attempt to make the analysis and
design phases short and very focused. This is justified on the basis that
requirements are changing so quickly and time-to-market is so critical that
the returns are lost if they take longer than a very short period.
There are four main ingredients for a successful RAD project:

 tools
 methodology
 people
 management.
Tools
RAD’s success is in reducing the time and hence the cost of the
development task. It is therefore essential that tools are available to help
developers create applications quickly and easily. The types of tools
required may include the following:

Table 2: Tool types required
Tool type Function
graphical user interface (GUI) generators quickly create visual interfaces and then
generate underlying source code
4th-generation languages (4GLs) Full-featured program languages which
reduce programming effort by creating
programs with far fewer lines of code
relational database management systems software to create and manage relational
(RDBMS) databases
computer-aided software engineering support all stages of system development.
(CASE) tools All analysis and design models are retained
in an encyclopaedia and can be reused in
later projects
Methodology
Developers must adhere to the RAD methodology which integrates

advanced development techniques such as Joint Application Design (JAD)
and prototyping and clearly defines development tasks.
People
Having the right people for the job is as critical as having the right tools.
RAD requires a user-sponsor who can make things happen by motivating
other users and removing political or bureaucratic barriers.
Throughout the development project, RAD uses JAD sessions, a technique

to greatly reduce elapsed time spent on analysis and design stages. A JAD
session is an intense working session lasting about four days, run by a leader
(or facilitator) and attended by 6–10 key people who have knowledge of the
area under study and the authority to make decisions for that area. The
session will either determine the requirements for a new system or develop a
general new system design. The costs of a JAD session can be high—a
major time commitment from senior people in the organisation and an
experienced and highly skilled facilitator must be employed—and therefore
key users and managers must be committed to attending and participating.
RAD also requires a highly skilled development team, sometimes called a

SWAT team (skilled with advanced tools). This is a small group of no
more than five people - all experienced, well-trained developers who can
work together efficiently and effectively. Through their experience, these
members may have developed their own libraries of reusable designs which
can further speed development.

Management
RAD’s success requires that management demonstrate support by helping

manage the organisational changes required. Management must agree that
decisions made by their representatives in JAD sessions are binding and
equivalent to formal sign-offs in the traditional SDLC.
Management must also ensure that effective project management tools and
techniques are employed so that the benefits of RAD can be measured.
In this development model, the prototype is used as the primary method for
gathering requirements and facilitating the analysis. Users find it much
easier to determine what they don’t like or don’t want once they have seen
something actually running. This also helps to determine what they do need
or want.
There are many variations on this style of development. Here are some
references for more information:
 Agile methodologies: These are a set of values rather than a
prescriptive process. Agile methodologies aim to be more responsive
to users’ changing requirements. Users are actively involved in
analysis and modelling efforts. For an example, go to the following
website: http://www.agilemodelling.com/
 Dynamic systems development method: DSDM is an industry-
standard RAD methodology. It provides a generic process which is
tailored for use by an organisation based on the particular business
and technical constraints. DSDM provides a framework for
developing systems. Different tools can be used to support this
methodology.
 eXtreme programming: This suits risky projects with dynamic
requirements. XP emphasises such things as close and constant
customer involvement in defining and prioritising requirements. For
more information, go to the following website:
http://www.extremeprogramming.org/
 Adaptive software development—Crystal: This is targeted at
software teams where competition creates extreme pressure on the
delivery process.

Incremental methodology
Image: Diagram of development model from ‘Project concept’ in first box, then
arrows leading to ‘Requirements prototype’, ‘Analysis’, ‘Design and architecture’,
‘Build’, ‘Testing and deployment’, ‘Release 1.0’, ‘Requirements prototype’,
‘Analysis’, ‘Design and architecture’, ‘Build’, ‘Testing and deployment’, ‘Release
2.0’.
Figure 8: Incremental development model
The incremental model introduces the idea of a product release. A large

computer system is decomposed in such a way that several distinct sub-
products are identified. Then each of these sub-products has its own SDLC.
The incremental methodology defines how these sub-products relate to
each other and describes the overall delivery of the whole system.
If we were to pick out some key features of a word processing package,

we might identify some of the following functionality:
 editing and modifying text
 formatting text
 saving a document
 printing a document
 spell checking
 importing text documents from other applications
 cutting, pasting and copying text
 displaying pictures and graphics
 displaying tables and graphs.
We could put the features we have listed into three categories:

1. essential
2. desirable
3. nice to have.

If we were to deliver the word processing functionality in stages, we can
identify three product releases:
 Version 1.0—Word processing basics, having all features
categorised as essential
 Version 2.0—Word processing regular, having all features
categorised as desirable
 Version 3.0—Word processing deluxe, having all features
categorised as nice to have.
Although the sub-life cycle of the incremental model is usually a rapid

prototyping model, it could just as easily be the traditional waterfall model.
The weaknesses of the waterfall model have been addressed because
missing requirements can be included in the next release of the system. If
the sub-products are small enough, the waiting time for the changed
requirements is not too long. Ideally, the sub-project should take from 12
weeks to 24 weeks. Any sub-project that takes longer than six months is
starting to look like a major project in itself, which begins to undermine the
advantages of the incremental model.
Evolutionary methodology
In most development models, the implementation of a large system is rarely

reviewed. Enhancements and additional releases tend to be built around
existing models and code. The catchcry of ‘if it ain’t broke, don’t fix it’
usually applies to computer systems, particularly when they are extremely
complex.
What generally happens is that a better design is implemented alongside

existing code, ensuring that the old functionality still works correctly.
Eventually, parts of the system become orphaned (no-one uses it any more)
or worse—the system loses its integrity because the whole thing is so
complex that no one knows how it works anymore. Commonly, developers
only tinker around the edges, cautiously adding bits and sometimes even
building functionality that already exists but has been forgotten.
The evolutionary model includes a cleanup of the system model and the
implementation as part of the ongoing life cycle of the system (see Figure
9). There is always a ‘spring clean’ after every release, ensuring that the
health of the system is in order.

Image: Diagram of evolutionary prototype model with ‘Project concept’ in the first
box and then arrows leading to ‘Prototype’, ‘Release 2.0’, ‘Prototype’, ‘Clean up
implementation’, ‘Clean up implementation’, ‘Clean up implementation’, ‘Release
1.0’, ‘Evolve Prototype’, and ‘Release 3.0’.
Figure 9: Evolutionary prototype model
In the worst case, this additional stage of cleaning up the implementation

can take as long as the original implementation. Remember, however, that
once you have built a system, you generally understand the problem
extremely well and holistically. When you build it a second time, without
large requirements changes, the system will much more closely resemble the
system that should have been built in the first place. The system will have
fewer bugs and greater adherence to the quality standards that are the
benchmark for a good system, such as reliability, correctness, robustness
and maintainability.
Advocates of the evolutionary model argue that since the maintenance and
enhancement phase of a system’s life is much greater than all of the other
stages put together, then reducing the cost of maintenance of the system -
even if the build and implementation time is doubled - can still work out as
a cost-saving advantage in the long term.
Key methodology features

The following table summarises some of the key features of each of the
methodologies described above:
Table 3: Key attributes of development models
Development model Key attributes
Waterfall Single delivery

Linear, non-iterative development
User input clearly defined
Iterative Non-linear
Rapid prototype Non-linear
High user input

Incremental Linear with possibly non-linear sub-phases
Multi-delivery
Evolutionary Linear or non-linear
Multi-delivery
High user input
Criteria for selection of a methodology

The selection of a systems development methodology will be based on the
type of client and the type of business problem that you are addressing.
In general, the following factors should be considered:

 Technologies: Many organisations invest heavily in technologies
that support a particular development methodology. These
technologies will determine some of the options you may choose.
 Tools: Similarly, companies have organisational standards that may
specify which tools are to be used for developing systems.
 People: Skills are needed to use all of the methodologies discussed.
Some only require a low skill level, while others require highly
developed skills. The methodology you choose will be limited by the
skills of the users and developers alike.
 Organisational patterns: The methodology used may also depend
on things like work patterns, physical proximity, virtual teams,
different types of employees, and outsourcing.
The process chosen will ideally conform to current organisational standards,

be able to evolve into the future and be usable in other contexts within the
organisation.
While the specific methodology may not be crucial to the success of a

project, an inappropriate methodology can definitely hinder the meeting of
budgetary, time or quality constraints.
Comparison of methodologies
Traditional SDLC
This is best suited to systems that

 are large, batch and mainframe
 have clearly defined objectives
 are processing-intensive (eg transaction processing systems for
payroll, order processing)
 use a technology that is familiar to the developers.

Disadvantages include the following:
 take time to complete the project
 lack of user involvement during the design and analysis phase
 difficulty in reacting to major changes in requirements during the
project
 require strong project management
 require strong technical background from the analysts
 are documentation-intensive.
Iterative development
This is a variation on the waterfall method, but it allows phases to be

revisited to allow reaction to changing business needs.
RAD
This is best used for large, complex system development projects that may
take one to three years to complete and involve twenty to fifty people at any
time.
Disadvantages include requiring

 highly skilled developers with experience in the use of advanced
tools
 a high level of user commitment throughout the project.
Incremental methodology
This is best used for systems that can be

 broken down into a series of sub-products
 implemented in versions.
Evolutionary prototyping
This is best used when the proposed system

 is leading-edge, i.e. requirements cannot safely be frozen before
beginning design and implementation
 is being developed for a dynamic environment where business needs
are constantly changing
 automates a real-time, highly interactive application with many
complex user interfaces.

Disadvantages include the following:
 requires highly skilled developers with experience in the use of
advanced tools.
Activity 4
To practise evaluating system development methodologies, complete

Activity 4– Evaluate system development methodologies in the Activities
section of the Topic menu.
Summary
To ensure the best outcome for a system development, it is important to use
the most appropriate system development methodology. This will involve
researching a range of currently used methodologies and evaluating their
suitability based on the specifics of the system to be developed.


Development Methodologies Notes

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Development Methodologies Notes

Uploaded by

Copyright:

Available Formats

Reading notes—Determine and select

appropriate methodology for a given

Knowledge of client business domain

What is the client’s core business? Sometimes it is apparent what the

Documents produced at a high level in the organisation are usually a good

Where can you find this information?

2842: Determine and select appropriate methodology for a given activity 1

To practice finding information about a client business domain, complete

Organisational features and functions

This is usually the case regardless of an organisation’s size. In small

Organisations that have a lot of middle management tend to have tall

2 2842: Determine and select appropriate methodology for a given activity

Figure 1: Example of an organisational chart

The manager of the purchasing department of a company has now been

2842: Determine and select appropriate methodology for a given activity 3

An organisational chart can be hand-drawn or a software program can be

Other features of an organisation are reflected in its policies and

What does all this have to do with technology?

An understanding of an organisation’s structure and functions, as well as

Knowledge of current business functions

Human resources (HR)

4 2842: Determine and select appropriate methodology for a given activity

The payroll processes manage production of payslips and cheques,

There are two distinct types of items owned by a company:

Consumables can be of two different types—stock and parts—and

2842: Determine and select appropriate methodology for a given activity 5

The following chart shows a typical parts inventory function:

Figure 2: Inventory function chart

The most common processes are:

This function keeps track of money owed to the business. It creates

6 2842: Determine and select appropriate methodology for a given activity

Marketing has two functions: one is to sell the company’s products or

Processes involved in this area include scheduling, i.e. a plan of what

To practise finding out information about a client business domain,

2842: Determine and select appropriate methodology for a given activity 7

Imagine that your local bank branch is being forced to close.

8 2842: Determine and select appropriate methodology for a given activity

Who are the stakeholders?

Those directly affected

2842: Determine and select appropriate methodology for a given activity 9

Those indirectly affected

Management has an indirect but controlling stake in any project that is

Upper management or a steering committee are usually the primary

Why is it important to ensure that upper management are adequately

Obviously, upper management will not be checking to see that design

It is necessary to understand the types of stakeholder and to ensure that:

10 2842: Determine and select appropriate methodology for a given activity

Category Stakeholders Representatives

Sponsors Kim Woo (Head of

2842: Determine and select appropriate methodology for a given activity 11

Figure 3: An example of the stakeholders involved in the BIGBUS reservation

Categories of end users

Consider unusual types of end users

12 2842: Determine and select appropriate methodology for a given activity

If a stakeholder is discovered later in the course of developing requirements,

To practise identifying stakeholders, complete Activity 3—Identify

System development methodologies

System development life cycle (SDLC)

2842: Determine and select appropriate methodology for a given activity 13

Figure 4: Life cycle of a butterfly

Current development methodologies

14 2842: Determine and select appropriate methodology for a given activity

Traditional SDLC or the waterfall model