topic 2 – 2843 determine and select appropriate...

Determine and select appropriate methodology for a given activity

2842.doc: © State of New South Wales, Department of Education and Training, 2006 1Developed by the Centre for Learning Innovation (CLI) for the TAFE Online Project, TAFE NSW

Overview

Image: Overview

This resource will help you to determine and select an appropriate development methodology for a specific activity within an information technology environment.

In this topic you will learn how to:

determine and define subject activity

define the criteria for selection of development methodology

review and evaluate a range of traditional and non-traditional system development methodologies

select appropriate system methodology to suit the activity.

This topic contains:

reading notes

activities

references

a topic quiz.

As you work through the reading notes you will be directed to activities that will help you practise what you are learning. The topic also includes references to aid further learning and a topic quiz to check your understanding.

Download a print version of this whole topic: Determine and select appropriate methodology for a given activity (347 KB 2842.doc)


Reading notes

Image: Reading notes

Knowledge of client business domainIn 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.


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.


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 stakeholdersA 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 interest front office

Analysts:

Avril Smith, Lidija Rossi, Michael Boynton

Avril Smith

End users—Australian equities front office

Analysts:

Quinton Jones, Terrence Brown, Anthony Wong

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 methodologiesA 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 (RDBMS)

software to create and manage relational databases

computer-aided software engineering (CASE) tools

support all stages of system development. 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


http://www.agilemodelling.com/

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


http://www.extremeprogramming.org/

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 deliveryLinear, non-iterative development


User input clearly defined

Iterative Non-linear

Rapid prototype Non-linearHigh user input

Incremental Linear with possibly non-linear sub-phasesMulti-delivery

Evolutionary Linear or non-linearMulti-delivery High user input

Criteria for selection of a methodologyThe 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.

SummaryTo 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.


Activities

Image: Activities

Activity 1—Knowledge of the client business domain

Visit the Coca-Cola website (http://www2.coca-cola.com/ourcompany/index.html) and read the company’s welcome statement. Does it give you a clear idea of the company’s core business? Which of the business documents mentioned in the reading notes for this section can you find on the site?

Feedback

The welcome statement clearly indicates the goal of manufacturing, marketing and distributing non-alcoholic beverages. There are links to sections such as ‘Our Beliefs’, ‘Our Diversity’, ‘Leadership’ and so on, which would come under the heading of mission statements and strategic goals.

Activity 2—Obtain knowledge of the client business domainUse the Internet to answer the following questions about the Environment Protection Authority Victoria as an example of a potential client.

Go to the website at http://www.epa.vic.gov.au/, then select About EPA and EPA Organisation chart.

In which directorate would you find the Community Relations department?

Feedback


http://www.epa.vic.gov.au/

http://www2.coca-cola.com/ourcompany/index.html

Sustainable development

Under which department does Regional Support Systems come?

Feedback

Regional services

If you wanted to apply for a job with the EPA, to which department would you address your application?

Feedback

Human Resources

If you had a complaint about excessive noise at a neighbouring business premises, to which department would you complain?

Feedback

Atmosphere and Noise

To whom does the Director of Water report?

Feedback

Chairman

Activity 3—Identify stakeholdersRead the scenario below:

Southern Dental Services is a small dental practice in a regional town. There are two dentists: Pamela Jones and Brian Huang. The practice has four support staff to manage the day-to-day running of the practice: Jane Emerson, who looks after the appointments; Brenda Gale, who handles the accounts; Keith Dickson, who manages the patient details; and Pauline Santoro, who organises the ordering of supplies, etc. Pauline obtains most of the supplies for the clinic from David Andrews, who runs a business selling medical and dental supplies. She orders all the other office-related products from Peter Smith’s business, OfficeStuff. The clinic has five hundred patients on its books, some of whom, like Mrs Mary O’Halloran, have been coming to the clinic since it opened ten years ago.

Now complete the following activity (39 KB 2842_activity3.doc):

For each of the people listed here (Peter Smith, Keith Dickson, Mary O’Halloran, Brian Huang, David Andrews, Pauline Santoro), identify which type of stakeholder they represent from the following three choices: supplier, staff or client. Complete the table and check your answers in the Feedback.


Feedback

Table 4: Identifying stakeholders

Person Type of stakeholder

Peter Smith supplier

Keith Dickson staff

Mrs Mary O’Halloran client

Brian Huang staff

David Andrews staff

Pauline Santoro staff

Activity 4—Evaluate system development methodologiesCreate a report describing the advantages and disadvantages of two system development methodologies. You should research at least one methodology that has not been covered in the reading.

Feedback

There is no feedback for this activity.


References

Image: References

Print

There are many software manuals, reference books and user guides available from libraries and bookshops, on CD-ROMS or on the Internet.

Note that many textbooks only cover the technical issues of a topic and do not discuss client-user relationships. Techniques to improve client and team communication may be found in books on management techniques and interpersonal skills.

Hawryszkiewycz, I. (2001) Introduction to Systems Analysis and Design, Pearson Education Australia.

Internet

The mindtools website has some interesting articles on stakeholders and their involvement in a project. Go to http://www.mindtools.com/ and select Project Planning and Management. Two links that are especially relevant are

Stakeholder Analysis

Stakeholder Management

The following links provide more information on the SDLC:

http://gates.comm.virginia.edu/

http://www.computerworld.com/

http://srmwww.gov.bc.ca/


http://srmwww.gov.bc.ca/

http://www.computerworld.com/

http://gates.comm.virginia.edu/rrn2n/teaching/sdlc.htm

http://www.mindtools.com/

Topic quiz

Image: topic quiz

This quiz will help you review the content you have learned in this topic.

Answer the questions, check the feedback at the end of each question and take note of the areas you need to learn more about.

1. Answer TRUE or FALSE:

An organisational chart gives an overview of staff and the functions of a business.

Feedback

Correct! This statement is True! An organisational chart gives an overview of staff and the functions of a business.

Incorrect. This statement is not false - it’s True! Go to the Reading notes and review the section on Knowledge of client business domain.

2. Answer TRUE or FALSE:

An incremental methodology is best used for a system that has a clear, fixed set of objectives.

Feedback

Correct! This statement is False! Incremental methodology is NOT useful where the system has a fixed set of objectives.

Incorrect. This statement is not true - it’s False! Go to the Reading notes and review the section on Incremental methodology and SDLC (the waterfall method).

3. A mission statement states the main purpose of the organisation and usually incorporates which of the following goals?

Financial


Social

Environmental

All of the above.

Feedback

Correct! A mission statement states the main purpose of the organisation and usually incorporates the following goals: financial, social, and environmental.

Incorrect. Go to the Reading notes and review the section on Knowledge of client business domain.

4. Which of the following is a traditional system development methodology?

RAD

Waterfall

Evolutionary prototype

All of the above.

Feedback

Correct! Waterfall is a traditional system development methodology.

Incorrect. Go to the Reading notes and review the section on Traditional SDLC or the waterfall model.

5. Which of the following methodologies requires a high level of user involvement throughout the project?

Waterfall

Incremental

RAD

All of the above.

Feedback

Correct! Rapid application development (RAD) requires a high level of user involvement throughout the project.

Incorrect. Go to the Reading notes and review the section on Rapid application development (RAD).


6. Which of the following is NOT a weakness of the waterfall model?

High user involvement throughout the project

Large amounts of documentation

Inability to incorporate changes in requirements

Feedback

Correct! High user involvement throughout the project is NOT a weakness of the waterfall model.

Incorrect. Go to the Reading notes and review the section on Traditional SDLC or the waterfall model.
