Inside this reading -...

Reading: Define and document business problems

Define and document business problems

Inside this ReadingDevelopment Methodologies 2

Traditional SDLC or Waterfall Model 2Iterative development 3Rapid application development (RAD) 4Incremental development methodology 5Evolutionary methodology 5

Project Scope 9Defining scope 9Project Aims 10Project Constraints 10Objectives 10System Boundaries 13

Document the business problem 16Problem Statement 16What is substantiation? 16Documentation Tools 17Organisation Standards 17Industry standards 20Summary 21

document.doc - 1 -© State of New South Wales, Department of Education and Training 2006


Development Methodologies

Development methodologies aim to standardise the steps taken to build a system, by defining both the tasks and the order in which they need to be performed. These steps are called the System Development Life Cycle or SDLC. There are many different development methodologies that are currently used within the industry, some of the most popular are:

Traditional or Waterfall

Iterative

RAD (Rapid Application Development)

Incremental

Evolutionary.

Traditional SDLC or Waterfall ModelAs the name implies the development consists of a sequentially ordered set of stages, where one stage naturally flows downhill into the next. See Figure 1.

A waterfall SDLC requires that one stage be completed fully before starting on the following stage. Once a stage has been completed, it can be quite difficult to go back and make changes to the output or deliverables.

For example, the outcome of the requirements–gathering stage is the modelling and documentation of the requirements. The design phase then takes the models and requirements produced to develop the actual design for the system. If the requirements change, this directly affects the design process.



Figure 1: 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 would find that the process of developing the system, expanding a design or implementing a report would help them discover issues and pose new questions that would 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 any sense. This has given rise to alternative development methodologies that take into account 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 developmentIterative development enables changes in requirements to be incorporated into the process by repeating a stage in the SDLC. The diagram in Figure 2 is simply a modified waterfall model that has arrows that go back to previous stages.



Figure 2: Modified waterfall model

Most of the commonly used SDLCs have an iterative component. You can see in Figure 3 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 finding of the testing.

Rapid Application Development (RAD)

Figure 3: 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 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 small period of time.

In this development model the prototype is used as the primary method for gathering requirements and facilitating the analysis.

Incremental development methodology

Figure 4: Incremental development model

The incremental development 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.

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 itself, which begins to undermine the advantages of the incremental model.

Evolutionary methodologyIn 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 6. There is always a ‘spring clean’ after every release, ensuring that the health of your system is in order.

Figure 5: 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.



The evolutionary methodology in practice

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.

Key methodology features

The following table summarises some of the key features of each of the methodologies described above.

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

The methodology you choose may depend upon some of the following factors:

Technologies. Many organizations invest heavily in particular types of technologies that support a particular software 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 software.

People. Skills are needed to use all of the methodologies discussed in this module. 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.



Project Scope

The scope of a project may be broadly defined by:

the aim (for example, to build a network for an office)

the end results (for example, to ensure that the local network is integrated into the whole company network)

the parameters that confine it (for example, the network is limited to the Sydney office)

exclusions (for example, the network will not be included in the Parramatta office).

Scoping a project is a vital thing to get right. The only way you can get an accurate idea of how much a project is going to cost and how long it’s going to take is to first know exactly what the project includes, and also, what it doesn’t include. That’s why you have to make sure the client is explicit about what they expect you to deliver.

Reflection

Consider a project you may have undertaken in your private life. It may have been renovating a property, or taking an overseas holiday. How well did you plan for it? Did you carefully ’scope the project‘, or did you approach it more casually? Looking back now, would you rather have scoped it more carefully than you did?

Defining scopeThe process of defining scope is critical to the success of a project. Without a clear understanding of exactly what constitutes the boundaries of a project, you cannot properly plan, budget for or manage it.

Before you can accurately define the scope, you need to first reach clear agreement with the client on what constitutes the project objectives. Once that is done, you should then have a clear idea of what is to be included in the scope of the project, and importantly, what is not to be included.

Sometimes there are multiple stakeholders, with diverse interests and expectations of a project. In this situation you have to take extra care to ensure that they effectively communicate these to you. It’s important to realise that communication is the most common obstacle to accurate scope



definition. Any misunderstandings or misinterpretations are likely to lead to mistakes in the scope definition.

Project ObjectivesAn objective is a task that will help achieve a goal. For the goal of maximising profit, for example, there may be several supporting objectives, such as producing a competitive product, marketing that product effectively, handling order entry and billing rapidly and accurately, and managing inventory efficiently.

Objectives can be specified in terms of improvements to the business’s processes and functions and what needs to be done to achieve these improvements.

Objectives are more concrete, measurable and specific than goals. They are the criteria that must be met for the project to be considered successfully completed.

It is important to define the objectives as precisely as possible to provide benchmarks against which to measure the success of the new system.

For example, it would be better to state, ‘ensure that data entry errors are less than 1%’ rather than ‘improve the data capture process’.

For example

Assume that your New Year’s Eve resolution for 2007 was to save enough money to have a holiday in Europe in January 2008. With this as your goal, what objectives would you have to meet to obtain this goal?

Some possibilities might include:

put $200 a month from your salary into a special savings account

reduce your spending on new clothes by $50 a month

only have one meal a week in a restaurant

sell your car.

As you can see from these suggestions, the objectives are quite specific and can be measured to make sure that they are being met.

Types of objectives

Some common types of objectives are:

functional objectives

process improvements



operational objectives

personal and job satisfaction needs.

Functional objectives

New or changed functional requirements, for example:

new or changed reports or screens

new services to be provided

new or revised security controls.

Process improvements

These may include

changes to the way data is accessed

changes to the sequence in which things are done

changes to input and output methods

changes to the processing steps.

Operational objectives

These include performance standards to be achieved by the new system, in terms of:

accuracy

timing.

Personal and job satisfaction needs

Important objectives include designing systems that are:

easy to use

allow users to be creative rather than just responding to computer outputs.

Project objectives can help you define the scope, since each objective should have at least one deliverable assigned to it.

To obtain achievable project objectives, they should be developed using the SMART method:

Objectives are well defined and clear.



You must be able to evaluate if the objectives are obtainable and how far away completion is.

You must obtain agreement on the objectives from stakeholders.

Considering resources, knowledge and time availability, can you accomplish the objectives?

How much time is needed to accomplish the objectives? This needs to be set accurately, too much or too little time may affect team performance.

Project Aims

Project aims are the physical outcomes that the client expects to be achieved at the completion of the project.

For example, the project aims for ensuring adequate security controls on a new system may include a:

facility to allocate and maintain passwords

facility to allocate and maintain security classification levels for different parts of the system.

Project ConstraintsThe constraints on your project are factors that will limit the options for project development. Constraints may be:

financial – for example, the project budget

legal – for example, contractual provisions

technical

political

deadlines.



Some typical constraints for an IT system might be that the system must: Function on the existing equipment

Interface with the existing accounts payable system

Accept input from 15 remote sites

Produce statistics for the government on hiring practices

Be operational by March 1st



Document the business problem

System BoundariesThe purpose of setting system boundaries is to limit the area of investigation. Boundaries need to be set otherwise the scope of the project can grow. Only those systems that are part of the problem or impact the solution need to be investigated. Some questions to ask to identify systems for investigation are:

Which people or systems does the system interact with?

What real–world objects and people does the system capture information about?

What business processes does the system support?

Create a context diagram

The purpose of a context diagram is to introduce everyone involved to all of the elements that make up the business area, i.e. real–world objects about which the existing system captures information.

The context diagram gives an overview of the whole system and shows how external entities interact with the system. External entities are the people or systems outside the system we are investigating, which interact with it in some way.

In the context diagram below:

the circle represents the system as one overall process

The boxes represent the external entities with which the system interfaces

The arrows represent information flowing from the system to the external entities and from the external entities into the system, the direction of the arrow head showing the direction that the information is flowing.

Only major data flows and external entities are shown in the context diagram.



Figure 6 is a context diagram describing a system that processes student enrolments.

Figure 6: Context diagram for student enrolments

The business processes that can be identified from this diagram are as follows:

A prospective student completes an application form and submits it to the enrolment office.

The enrolment office staff process the enrolment and send the student details to the relevant teaching department.

The accounts department provides details of the amount that the student is required to pay for this course and the enrolment staff create an account to give to the student.

The student pays the fee to the enrolment staff and this is then forwarded to the accounts department.

The enrolment staff give the student a timetable

In this situation, the student is an external entity, because they are providing information to the enrolment system. The accounts department is also an external entity for the same reason. Both of these external entities also receive information from the system. The teaching department is also an external entity because it receives information from the system. The specific type of information is labelled on the arrows.



Since a context diagram is a simple diagram it is very easy for users with no computing skills to understand the business processes that it portrays.

Problem StatementNow that we have defined the business problem in terms of its boundaries, scope and the objectives to be achieved we must put these findings into a document to present to the client. Developing a problem statement will provide you with a documented basis for the project that can be used to develop common understanding and manage stakeholder expectations.

This document will be used by management to determine whether to authorise a continuation of the project to the next stage, which will entail an analysis of the current system.

The format of a Problem Statement will vary depending on the organisation’s standards and procedures, but it should contain the following information:

System background or context

Description of the problem

Scope

Objectives

Constraints

Have a look at a sample problem statement on the web.

Go to the website for The Mayfield Handbook of Technical and Scientific Writing

https://mit.imoat.net/handbook/home.htm , select Table of Contents , then 1.3 Problem Statement

What is substantiation? Substantiation at this stage means to obtain agreement from the client that the contents of the problem statement are correct – specifically the scope and objectives of the investigation that will be performed – and may involve changes in response to client feedback.

If the report covers several different business areas then there may be more than one person who will need to check the accuracy of the contents.

It may also include an authorisation to either continue to the next phase, in this case an analysis of the problem, or to terminate the project at this point.


https://mit.imoat.net/handbook/home.htm


The decision will be made by the client, based on the information contained in the report

Documentation ToolsDocumentation tools include any technical resources and materials that are used to develop and support documentation.

Some tools, which can be used to create text, drawings and software specifications, include:

Word processing software, eg MS Word or Open Office

Drawing software, eg MS Visio

Database software, eg MS Access

Project management software, eg MS Project

Web page development software, eg MS FrontPage or Dreamweaver

Spreadsheet software, useful for analysis, eg MS Excel

Systems analysis and design CASE tools, eg System Architect.

Help authoring software, eg Help Developers Kit – HDK

Templates are predefined outlines that contain the structure and format of a document. The writer opens the template and inserts the required text or diagrams into the relevant area of the template. The advantage of this is that a standard layout can be used and the writer will be prompted for information for the required sections, thus reducing the possibility that important items may be overlooked. Software packages that are used for producing documentation will usually include templates for most of the standard business documents that a company might use.

Often, during a project, you will develop standards specifically for that project. This would be done in collaboration with the other members of the project team and incorporating any existing organisational standards.

Organisation StandardsOrganisational standards are a set of rules or procedures providing a guide as to how to correctly perform a specific activity or operation within an organisation. They’re also often referred to as organisational guidelines. There should be a set of standards for every type of activity within an organisation.

The major aim of organisational standards is to increase the efficiency or productivity of an organisation by following prescribed steps. The standards



are also used as a benchmark from which potential improvements can be easily identified.

Standards are also essential for producing and maintaining good documentation. They make it easier to develop, use and maintain documentation.

There is great benefit in today’s business world for all documentation produced by an organisation to be consistent with the company image. ‘Corporate branding’ as it is often called or ‘corporate identity’ promotes consistency and engenders confidence in existing and potential clients.

An effective way for an organisation to create a consistent style or image, and ensure all employees follow the style requirements is to produce a style guide that is to be used in all of its documentation, to project the correct corporate image.

Style Guide

A style guide is a reference document that contains a set of formatting and layout instructions defining the business guidelines for each type of document to be used within the company. It provides guidelines for designing, developing, editing and presenting company information. It will also contain the basic templates, controls and rules of design for the business’s documentation. Style guides ensure consistency throughout the company, allowing each department to contribute to the presentation and maintenance of an organisation’s image.

Style guides can be as short as a single page that just lists variations from a commercially available guide or the main company style guide. Or, they can be lengthy in–house guides with no reference to commercial guides.

Style guides often contain three types of information:

process (how things are done, eg how to create a document and get it approved for publication)

design (what documents should look like to conform to the business image)

style (standard content should be in the document, and if there is a template to use).

A style guide consists of rules and suggestions or recommendations to be followed when producing a document or presentation. What should be rules (that are non–negotiable) and what should be only suggestions depends on management’s choice and company policy. Thus, the rules will vary from business to business.

The production of a style guide needs to go through a formal development process and it is important that the planning and development of a style



guide be done with the understanding that it is a living/evolving document. Items can be added, removed or changed as decisions are made/revisited, or situations change. Moreover, the guide should be regularly updated to reflect current business needs/policies and circulated to all who may be affected by the changes.

The style guide should contain design decisions that directly affect writing and editing, for example:

the conventions to be used on chapter and section and page numbering

the style for each level of heading, titles for figure and tables as well as the layout of vertical lists

the rules for highlighting text (eg bold, underline or italics type)

which template is to be used for which type of document

which version of English to use (eg American or British)

which system of measurement to use if not metric and specifying any variations (eg ‘dots per inch’ in a metric guide)

mandatory reference materials like an industry style guide, a particular dictionary, the company’s design and process guides

which elements such as title page, preface, table of contents, glossary, index, copyright details are required, and what to include in them

on which pages should headers and footers appear and what they should contain

when to spell out numbers and when to use numerals as well as defining the punctuation to be used in numbers over 999.

writing style, level of language usage

any special requirements such as whether or not the singular ‘they’ is acceptable or if there are any terms to be avoided

when and how to use screen captures.

An organisation may:

create its own style guide

refer to a publicly available style guide (such as past editions of the Government Publishing Style Manual) for certain standards such as the use and spelling of words and language terms

purchase a style guide that can be adapted and added to by the company.



Sample style guides

Spend some time now to look at the kinds of guidelines or standards for attributes (of content and/or formatting) you’ll find in a style guide. Use the Internet to access these examples:

This style guide is produced and used by AusAID, the Australian Government’s Overseas Aid Program: http://www.ausaid.gov.au/publications/pdf/style_guide.pdf

This style guide is produced by the University of New England to assist students in their academic writing: http://www.une.edu.au/tlc/styleguide/styleguide.pdf

The Rural Industries Research and Development Corporation’s style guide: http://www.rirdc.gov.au/researchpriorities/styleguide.pdf

Industry standardsStandards are set both by the organisation for which you work and by the industry in which the business operates.

Industry standards are generally adopted by organisations to ensure that the documentation that they produce is of good quality and relevant to their specific industry. Organisations then modify these standards to incorporate their own organisational policies and requirements.

Standards Australia

In Australia, most industry standards are published by Standards Australia. They are an independent, non–government organisation. However, through a Memorandum of Understanding, they are recognised by the Commonwealth Government as the peak non–government Standards body in Australia. They represent Australia on the two peak International Standards organisation, ISO and IEC. Their primary role is to prepare standards through an open process of consultation and consensus in which all interested parties from a variety of industries are invited to participate.

Research

Visit the Standards Australia web site at http://www.standard.com.au and take a look at some of the products and services that they provide.


http://www.standard.com.au/

http://www.rirdc.gov.au/researchpriorities/styleguide.pdf

http://www.une.edu.au/tlc/styleguide/styleguide.pdf

http://www.ausaid.gov.au/publications/pdf/style_guide.pdf


Copyright rules and responsibilities

There are some basic standards which all organisations have to abide by because they are covered by legislation. Copyright is one of these. Occupational health and safety is another.

ResearchGo to www.copyright.org.au to check out the Australian standards with respect to copyright.

SummaryThe system boundaries and scope of a problem must be identified so that we have a starting point for further investigation. Objectives and expected aims must also be identified. A Problem Statement can then be produced which will contain the above details in a format based on the standards and guidelines of the business.


http://www.copyright.org.au/

Inside this reading -...

Documents

Transcript of Inside this reading -...