system analysis tutorial

SYSTEM ANALYSIS TUTORIAL

PREPARED BY: KABA N. DANIEL

1

Data flow diagrams (DFD) A data flow diagram (DFD) is a significant modeling technique for analyzing and constructing information processes. DFD literally means an illustration that explains the course or movement of information in a process. DFD illustrates this flow of information in a process based on the inputs and outputs. A DFD can be referred to as a Process Model. They show how data flow through the information system, but do not show program logic or processing. A set of DFDs provides a logical model that shows what the system does, not how it does it. DFD symbols DFD us four basic symbols that represent processes, data flows, data store and entities Gane and Sarson symbols Yourdon symbols

Process

Data flow

Data store External entity

• PROCESS SYMBOL Receives input data from and produces output that has a different content, form or both. This can also be referred to black box because input, outputs and general functions of the process are known, but underlying details and logic of the process are hidden.

Apply

payment

Apply

payment



2

• DATA FLOW SYMBOL This is a path for data to move from part of an information system to another. A data flow in a DFD represents one or more data items. The data name appears above or below or alongside the line. Consists of a singular noun or adjective if needed for example DEPOSIT, INVOICE, PAYMENT, GRADE etc.

• DATA STORE SYMBOL It is used in DFGD to represent data that the system is stores because one or more processes need to be use the data at a later time. Use simple

• ENTITY SYMBOL Provides data to the system or receives data from the system. DFD entities are also called terminators because they are data origins or final destination. They supply data to the system hence called source and receives data from the system hence called sink.

Guidelines for developing DFDs

• Draw and name a single process box that represents the entire system.

• Identify and add the external entities that communicate directly with the process box. Do this by considering origin and destination of the resource flows and data flows.

• Add the resource flows and data flows to the diagram.

• Don’t cross lines

• Dram context diagrams so as it fits one page.

• Use name of information system a s the process name.

• Use unique names within each set of symbols.

• Provide unique names and reference number for each process.

Context DFD

The context diagram represents the entire system under investigation. This diagram should be drawn first, and used to clarify and agree the scope of the investigation.

The components of a context diagram are clearly shown on this screen. The system under investigation is represented as a single process, connected to external entities by data flows and resource flows.

The context diagram clearly shows the interfaces between the system under investigation and the external entities with which it communicates. Therefore, whilst it is often conceptually trivial, a context diagram serves to focus attention on the system boundary and can help in clarifying the precise scope of the analysis.



3

Types of Data in DFD.

• Standing: day to day, up to date. • Historical: reference and archive. • Temporary: data required for a process but not retained. • Extracted: retrieved from various places to produce reports etc.

Example 1

Draw a context diagram that accepts supply of books from suppliers and borrows to students.

Return request

Availability

Book details

Order

Reservation

Enquiry

Student Admno

Example 2

Draw a Context diagram of the order system for Ouru superstores.

0

Library

system

Book supplier Borrower Book



4

Level 1 DFD

Shows the system’s major processes, data flows, and data stores at a high level of abstraction. When the Context Diagram is expanded into DFD level-0, all the connections that flow into and out of process 0 needs to be retained.

Example 1

Using the example 2 above draw a level 1 DFD for the order system.



5

Context DFD for the mail order system

Suppose you are given the details of a small mail order catalogue system that allows people to shop from home. When a customer receives the catalogue and wants to buy something, they can telephone, fax or email their order to the company. The company gets the order and sends the goods and an invoice. When the customer receives the goods with a delivery note, they send payment and receive a receipt for their payment.

Required:

Draw a Context DFD for the mail order system

Assignment 1

When a patient arrives at Level 5 Hospital in Kisii for Surgery with a repeat prescription request, the receptionist checks the prescription file and writes out a prescription. This has to be authorized by the doctor before being passed to the resident chemist for dispensing. The chemist then gives the prescription to the patient. If the patient is entitled to free prescriptions, the chemist verifies this and fills in the appropriate details on a form, which is filed in the free prescriptions file. Otherwise the chemist takes the appropriate amount of money from the patient and gives them a receipt.



6

Level 1 DFD

The next stage is to create the Level 1 Data Flow Diagram. This highlights the main functions carried out by the system. As a rule, we try to describe the system using between two and seven functions - two being a simple system and seven being a complicated system. This enables us to keep the model manageable on screen or paper.

Assignment 2

Convert the mail order system to a level 1 DFD.



7

Assignment 3

When FlashIT is interviewing and selecting new employees for their company, they ask applicants to send their application forms and their CVs to personnel. The personnel department then checks these forms for completeness and, if found to be complete, they are stored in the applications file. Otherwise these forms are returned to applicants for resubmission. The applications are then scrutinized for possible interviewees. Any candidates not considered suitable for the post are sent a refusal letter. Suitable candidates are requested to come in for interview. After interviews have taken place, a decision on the most suitable candidate is taken and they are offered the post. The interviewees who have been unsuccessful are sent a refusal letter.

Required:

Draw a level 0 DFD to represent the above data.

Level 1 of the FlashIT system.



8

Assignment 4

Kisii High School has a library that lends books to staff and students. Pupils are allowed to borrow six books and teachers are allowed to borrow ten. When someone borrows a book the library book file is updated, as is the borrower file. Everyone issued with a book has it for a period of one month, after which time they are sent a reminder. If, after six months, they haven't returned the book, they are sent a bill for the cost of recovery of the book.

Required:

Draw a level 1 and level DFD to represent the above information.

Level 1 DFD



9

Level 2 DFD

Assignment 5 The Treadmills Holiday Association (THA) provides good value holidays for its members and the general public. These holidays are of three kinds: holidays at home, holidays abroad and special interest holidays. Membership is achieved by booking a holiday of one week or more and is valid until September of the following year. Requests for information about holidays and for brochures are handled by the enquiries section. Bookings can be made initially by telephoning the bookings section for a 7 day option and then sending the completed application form (from the brochure) with the deposit to the association within the 7 day period. All incoming post is received by the administration section. Booking details are forwarded to the bookings section; deposits and balances are forwarded to the accounts section. The administration section also maintains the membership records using the names of those who have booked for a week or more, provided by the accounts section. It also sends out holiday brochures, newsletters and details of the Annual General Meeting to members. The balance of the cost of the holiday must be paid no later than 28 days before the commencement of the holiday. The accounts section sends final demand notices to those people who have not paid balances on time and sends confirmation of payment of balances to the bookings section.



10

The bookings section sends further details of the holiday centre and the holiday and tickets where appropriate to the people who have paid their balances. It also sends a weekly bookings summary to the managers of the various holiday centers. It is also responsible for creating and maintaining the records of bookings for each of, holidays abroad, holidays at home and special feature holidays and uses these on a day-to-day basis. The enquiry section also has access to these records. Required: Produce a Context diagram & Level 1 physical dataflow diagram for the following scenario. Entity Relationship Diagrams An ERD is often used as a way to visualize a relational database: each entity represents a database table, and the relationship lines represent the keys in one table that point to specific records in related tables. Entity Relationship Diagrams (ERDs) illustrate the logical structure of databases.

Entity Relationship Diagram (ERD)

There are three basic elements in ER models:

• Entities are the "things" about which we want to store information. • Attributes are the properties or data we collect about the entities. • Relationships provide the structure needed to draw information from multiple entities. In a

database ERD they show how two entities share information in the database structure.

They are often used to illustrate the logical structure of databases. e.g.



11

Entity Relationship Diagram Notations/Symbols

Entity

An entity is a business object that represents a group, or category of data. An entity is an object or concept about which you want to store information.

Weak Entity

A weak entity is an entity that must defined by a foreign key relationship with another entity as it cannot be uniquely identified by its own attributes alone.

Attribute

An attribute is a sub-group of information within an entity. A key attribute is the unique, distinguishing characteristic of the entity. For example, a student admission number will be the student’s key attribute.

Multivalued attribute



12

A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values.

Derived attribute

A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the employee's annual salary.

Relationships

Relationships illustrate how two entities share information in the database structure.

Cardinality

Cardinality specifies how many instances of an entity relate to one instance of another entity.

Ordinality is also closely linked to cardinality. While cardinality specifies the occurrences of a relationship, ordinality describes the relationship as either mandatory or optional. In other words, cardinality specifies the maximum number of relationships and ordinality specifies the absolute minimum number of relationships.



13

Recursive relationship

In some cases, entities can be self-linked. For example, employees can supervise other employees.

Example 1

Entity life history

An Entity Life History diagram is used to show the sequencing, iteration or timing of an entity. Entity Life History diagram shows the events that take place on an entity. For example take a supporter of a charity. An Entity Life History diagram represents the life cycle of entities within the database.

Entity Life Histories provide us with our third view of the system, the dynamic sequence, or time-based view of the system. It shows the processing cycle of an entity from creation to deletion. It



14

models all the possible changes to the values of the attributes (data items) during its life, and the sequence in which changes take place. ELHs use the structure diagram notation (also known as Jackson-like diagrams). The structure diagram consists of three simple constructs:

• Sequence

• Selection

• Iteration.

Entity Life History Notations

Entity

Use a simple rectangle to represent an entity. This entity box will be the starting point for your ELH

diagram.

Event

An event creates, modifies, or deletes an occurrence of one or more entity types. The first event should be placed to the left, and at the same height, as the events that are expected to follow it.



15

Selection

To represent a choice between a number of alternative events, mark the events with a small "o" (for option) on the upper right hand corner.

Iteration

If an event is repeated, place a small asterisk (*) in its upper right hand corner. All events under a single node must be of the same type. In other words, don't mix and match iteration, selection, and sequence event notations.

Parallel Structures

To illustrate an event that has no major effect on the system, such as a change of an address for an employee, use a parallel bar to note this exception to the system's normal life.



16

Quit and Resume

To represent an unusual event (i.e. an employee taking family medical leave), you can use pairs of "quit and resume" events. Each event marked with a "Q", can be replaced by an event marked with an "R."

Example 1

Example 2 A bank account is created by a customer opening the account. During the life of the account numerous transactions will be made affecting the account. The transactions can either be debits or credits. At any time the account holder may change their address held on the account. The account ceases to exist when it is closed by the account holder.



17

Entity

Open Life Close

Normal

Life

Transactions

Debit Credit

Parallel

Life

Changes* *

Assignment 1

A bank account is opened by Winston Smith at the BB Bank PLC. During the following year Winston makes a number of transactions which are either deposits or withdrawals. At the end of the year the account is audited and the interest due is added to the account. On 12th February the following year Winston closes his bank account. Required: Draw an ELH for the Account Entity in the following scenario.



18

Assignment 2

An applicant to the Africa Nazarene University sends in an application form. From the details contained on the application form the applicant is either rejected, given a conditional offer or given an unconditional offer. If an unconditional offer is made, then the offer may either be accepted or rejected by the applicant. If a conditional offer is made then the applicant upon notifying the University of their results will either be given an unconditional offer, which can be accepted or rejected or they will be rejected by the University.

Required:

Draw an ELH for the application entity in the following scenario.

The Data Dictionary

One of the most important parts of database is data dictionary, which is a read-only set of tables that provides information about the database. A data dictionary contains:

• The definitions of all schema objects in the database (tables, views, indexes, clusters, synonyms, sequences, procedures, functions, packages, triggers, and so on)

• How much space has been allocated for, and is currently used by, the schema objects • Default values for columns • Integrity constraint information • The names of Oracle users • Privileges and roles each user has been granted • Auditing information, such as who has accessed or updated various schema objects • Other general database information

Data Dictionary Notation

The data dictionary contains formal definitions of all the data items shown in the data-flow diagrams. If you didn't create data flow diagrams in your analysis, then in general, every data item in your solution must be included in the data dictionary. If you wrote Use Cases, then every noun that isn't an Actor is a data item or attribute. It is used to provide precise detail concerning the data entities. Importantly the dictionary items are defined as they are found in the problem domain, not in the implementation or solution domain.

The data dictionary has two different kinds of items:

• Composite data

• Elemental data.



19

Higher-level (composite) elements may be defined in terms of lower-level items. Elemental data are items that cannot be reduced any further and are defined in terms of the values that it can assume or some other unambiguous base type.

The general format of a data dictionary is similar to a standard dictionary; it contains an alphabetically ordered list of entries. Each entry consists of a formal definition and verbal description. The verbal description is simply a sentence or two in English describing the data element. The formal description provides a more precise definition using a mathematical sort of notation. COMPOSITE DATA

Composite data can be constructed in three ways: sequence, repetition, or selection of other data types.

sequence: + A plus sign indicates one element is followed by or concatenated with another element.

repetition: [ ] |

Square brackets are used to enclose one or more optional elements.

A vertical line stands for "or" and is used to indicate alternatives.

selection: {} {}y

Curly braces indicate that the element being defined is made up of a series of repetitions of the element(s) enclosed in the brackets. The upper limit on the number of allowable repetitions can be indicated by including an integer superscript on the right bracket. Here y represents an integer and indicates that the number of repetitions cannot be greater than y.

Examples

Sequence:

Mailing-address = name + address + city + zip-code * The address at which the customer can receive mail * repetition:

Completed-order = [ item-ordered ] * A complete customer order *

Selection: Atm-transaction = { deposit | withdrawal } * An customer transaction at an automated teller machine *



20

In these examples asterisks are used to delimit the comment or verbal description of the item, but other notations can be used as well.

ELEMENTAL DATA

Elemental data is described in terms of a data type or by listing the values that the item can assume. desired-temperature = floating point *Desired-temperature is the value the user sets for desired water temperature in the pool. It is a floating point number in the range from 0.0 to 100.0, inclusive. The units are Celsius.*

age = non-negative integer *Age is how old the customer is in years. Age is a whole number greater than or equal to zero.*

performances-attended = counter * Performances-attended is the number of performances this customer has attended. Note: Since the person doesn't get entered into the mailing list until they have attended a show this value can never be zero. *

counter = positive integer *Counter is a whole number greater than zero that can only be incremented by one and never decremented.*

Formal data dictionary entries can easily be created for more unusual sorts of data elements as well. The example below shows how a magazine subscription system might contain category-type information. In this case the data items are enumerated types and the definition lists all the allowed values. Do not create a separate entry for each enumerated value. If necessary, the meaning for the enumerated values can be explained in the supplementary notes.

Transaction-Type = { Renewal | New-Subscription | Cancellation }

Transaction-Type identifies the kind of transaction. New_Subscription is someone signing up for the first time. Renewal is a previous subscriber who is renewing. Cancellation is a subscriber terminating their subscription.

Payment-Method = { cash | check | money-order | charge-card }



21

Payment-Method is the method by which a customer paid for their transaction. (The values should be self-explanatory).

Details concerning input or output formats can be specified in the data dictionary.

New-Subscribers-Report = report-header + new-subscriber-list + report-summary

report-header = report-title + current-date

report-title = 'Monthly Report of New Subscribers'

new-subscriber-list = [ subscriber-name + subscriber-address ]

report-summary = 'The total number of new subscribers:' + Number-of-new-subscribers Any non-terminal terms used in these definitions must be defined elsewhere in the data dictionary. Single quote marks are used to surround and indicate literals.

Data Dictionary example1 __________________________________________________________ name guess count alias turn count description The number of incorrect guesses the player has made this game. definition 0 <= guess count <= guess limit supplementary __________________________________________________________ name guess limit alias none description the number of guesses a user is allowed before they lose the game. definition guess limit = 7 supplementary __________________________________________________________ name hidden word alias secret word description the word the player is trying to guess definition hidden word = [ alphabetic character ]30 supplementary __________________________________________________________ name guessed word alias none

description the letters that the player has correctly guessed, in their proper position in the word.

definition guessed word = [ alphabetic character ]30 supplementary __________________________________________________________ name continue choice alias none



22

description whether the user wants to play again or not definition continue choice = {yes | no } supplementary

State Transition Diagrams

An STD is a way of describing the time-dependent behavior of a system. Describes all of the system possible states of an object as events occur. Each diagram represents objects of a single class and tracks the different states of its objects through system.

States:

• A state is an observable mode of behavior of the system. • At any time a particular STD can only be in one state, but a system's behavior could be

described by more than one state transition diagram

Transition conditions:

• internal events or events external to the system

Transition actions:

• actions in response to the events • triggering one-shot actions • synchronizing between different STD's • producing control outputs

When to use the STD

• Use the state diagrams to show and demonstrate the behavior of the objects through the many uses of the system. Only use the STD for classes where it is necessary to understand the behavior of the object through the entire system.

Drawing STD's:

• Identify observable states of the system • Select the states with normal behavior • Specify the conditions that mark a transition



23

• Specify the actions to produce the observable behavior in the destination state for each transition

• If the system is complex, partition the diagram in several STD's

The STD use the basic rounded corner rectangle representing a state of the object and arrows indicating the transition to the next stage. The activity section of the state symbol depicts what activity the object will be doing while it is in that state.

STD notations Activity

Transition Initial stage

State name

Do/Action



24

Example 1 Draw a state diagram for the order system at nakumat supermarket. [Items available] [Items not available] Activity state An activity state shows the workflow behavior of a system. They are similar to state diagrams activities are the state of doing something. A state diagram describes the state of activities by showing the sequence of activities performed. While an activity diagram shows the activities that are conditional or parallel. When to use activity diagrams

Checking

Do/Check items

Dispatching

Do/Action

Cancel Delivered



25

It is used to model the workflow behind the system being designed. They are useful foe analyzing a use case by describing what actions need to take place and when they should occur. Activity diagrams notations Start Activity Fork/join Flow Merge/branch



26

End/stop Sample activity diagram Start

Fork Branch Merge



27

Join End Example 1 Draw an activity diagrams for processing an order.

Fill order

Receive order

Overnight delivery

Send invoice

Regular delivery Receive payment



28

Auditing

In accounting and finance terms, audit is a process which includes an examination of records or financial accounts to check their accuracy, an adjustment or correction of accounts an examined and verified account. However the concept is a bit different in case of information systems. An examination of systems, programming and datacenter procedures in order to determine the efficiency of computer operations.

Auditing is the independent examination of records and other information in order to form an opinion on the integrity of a system of controls and recommend control improvements to limit risks. There are several significant terms in that description:

• Independent - Auditors should not be directly involved with the operations or management of a function being audited. They should report to a separate line of management and be free to state the facts of a situation and their honest opinions without fear of recrimination from those in the subject area. Just as if not more importantly, independence is also a state of mind. It’s about being freethinking, able to gather the facts and consider situations objectively.

• Examination - auditing involved the gathering and assessment of factual information from various sources. It is important that the formal outputs of the auditing process (primarily audit reports containing recommendations for control improvements) are traceable to valid information sources.

• Records and other information- Including what are often called “audit records”. Auditors need to refer to information regarding the business processes and systems under review (such as completed data-entry forms, system-generated reports and, of course, the people involved in doing or managing the relevant business processes). IT auditors often use data analysis tools to examine computer records. Furthermore, all auditors normally interview staff in the business areas under review and may use other observational techniques to examine business processes in action.



29

• Opinion - auditors provide both objective facts and subjective opinions on a given situation. Although subjective, their opinions are based on an interpretation of the facts and are open to legitimate challenge.

• Integrity - literally means completeness, accuracy and trustworthiness. A control system which is only partially effective may be better than nothing or it may give a false sense of security: either way, the auditor will probably not be entirely impressed. Personal integrity is a core value for auditors.

• System of controls - different types of control operate at many levels. IT auditors work with technical controls built-in to the computer systems, of course, but also procedural controls (operations procedures etc.), legal controls (software licenses etc.), Human Resources controls (employment contracts, disciplinary procedures etc.) etc. These controls may be preventive (‘You can’t do that’), detective (‘I know exactly what you did and I’m really not happy about it’) or corrective in nature (‘Sort that bloody mess out and don’t ever do it again’).

• Recommend - auditors generate audit recommendations but have neither the authority to implement suggested changes nor can we force management to do so. We achieve improvements mostly by a process of explanation, justification and persuasion, explaining the risks represented by control weaknesses, justifying the need to change systems and/or processes, and persuading management to apply the necessary resources and direction in order to address the risks. As a last resort, audit’s big stick is political clout, a.k.a. friends in high places

• Control improvements - improving the system of controls generally means adding necessary controls that were missing, or at least improving those that were in place before the auditors started poking around. In very rare cases, auditors may actually recommend removing controls, generally because they are ineffective, disruptive or wasteful but this concept is so counter-cultural that Heads of Audit take a lot of persuading, I can tell you.

• Limit - risks, like fraudulent politicians, spam emails and bugs, can be reduced but not totally eliminated. Good business involves minimizing unnecessary risks cost-effectively and being prepared for the worst if, despite everything, things go wrong (contingency planning). It also involves taking calculated risks to make a profit - the key word being ‘calculated’.

• Risk –In an information processing context, risk is the chance combination of threats (usually caused by someone with malicious intent, sometimes just due to carelessness or incompetence), acting on vulnerabilities (weaknesses in the system, typically due to a lack of controls in many computer systems and operating procedures) to cause impacts (adverse outcome).

•

IS auditing

Information systems include accounting and finance function as a critical part of the entire system. Hence, these days audit of information systems as whole incisively focuses on finance and accounting aspect as well. For example, all banks and financial institutions have soft wares supporting interest computations. During the audit of IS, the integrity of the source code/program instructions have to be checked and assurance obtained that these have not been tampered with or altered in any manner.

An information technology (IT) audit or information systems (IS) audit is an examination of the controls within an entity's Information technology infrastructure. When transactions are 151 executed and recorded through computers, the lack of physical audit trail requires implementation of controls



30

with the Information systems so as to give the same result as controls are implemented in a manual information system IS audit focuses more on examining the integrity of controls and ensuring whether they are properly working. Obtained evidence evaluation can ensure whether the organization's information systems safeguard assets, maintains data integrity, and is operating effectively and efficiently to achieve the organization's goals or objectives.

Audit trails An audit trail is a logical record of computer activities/usage/processing pertaining to an operating or application system or user activities. An information system may have several audit trails, each devoted to a particular type of activity. All these audit trails are primarily extracted from the audit log recorded on chronological basis. The audit log is maintained only for the list of activities specified for which the log is to be maintained. The information can be recorded varies including but not limited to:

• Time stamp for the log in/out time

• Terminal in use

• Files accessed

• Transactions performed

• Amendments made Audit trails can provide a means to help accomplish several security-related objectives, including individual accountability, reconstruction of events (actions that happen on a computer system), intrusion detection, and problem analysis, as well as evidence of the correct processing regimes within a system Types of audit trails

• An event-oriented log

This usually contains records describing system events, application events, or user events. An audit trail should include sufficient information to establish what events occurred and who (or what) caused them.

• A record of every keystroke

Often called keystroke monitoring. Keystroke monitoring is the process used to view or record both the keystrokes entered by a computer user and the computer's response during an interactive session. Keystroke monitoring is usually considered a special case of audit trails. Benefits of audit trails

• Audit trails are technical mechanism that helps managers maintains individual accountability. Users can be identified by the log being maintained. Users are informed of what the password allows them to do and why it should be kept secure and confidential.

• Audit trails help to provide variants from normal behavior which may lead to unauthorized usage of resources.

• Audit trails can be used together with access controls to identify and provide information about users suspected of improper modification of data (e.g., introducing errors into a database).

• An audit trail may record "before" and "after" images, also called snapshots of records.



31

• Computer audit will reinforce organization data and information from getting lost to unauthorized access.

Soft system methodology

Soft Systems Methodology (SSM) was developed by Peter Checkland in the late 60’s at the University of Lancaster in the UK. Originally it was seen as a modeling tool, but in later years it has been seen increasingly as a learning and meaning development tool. Although it develops models, the models are not supposed to represent the real world, but by using systems rules and principles allow you to structure your thinking about the real world. The models are neither descriptive nor normative, though they may carry elements of both. One of the interesting things about SSM is that it constrains your thinking in order for you to expand your thinking. Thus blowing away the idea that system thinking is always expansive.

Like many other systems approaches the heart of SSM is a comparison between the world as it is, and some models of the world as it might be. Out of this comparison arise a better understanding of the world (research), and some ideas for improvement (action).

Soft Systems Methodology is an approach to inquiry into problem situations perceived to exist in the real world (Checkland and Scholes, 1990:18). It is a methodology used to support and to structure thinking about, and intervention in, complex organizational problems.

SSM is a process for managing the process of achieving organized action. SSM practitioners take managing to be the process of thinking-out and implementing organized action, and of reacting to changes in the world which might affect that action.

It does take the process of management to be the sole preserve of a class of workers called managers. Managing, in these terms, is an activity performed by all sorts of individuals, at all sorts of levels, in all sorts of formal and informal organizational groupings.

SSM assumes that each individual will see the world differently. Different world-views inevitably lead to varying understandings and evaluations of any situation, which lead in turn to different ideas for positive action. These ideas are not necessarily opposed to each other, but they may be different enough to make the difference a serious issue when deciding on a course of action.

Soft Systems Methodology attempts to foster learning and appreciation of the problem situation between groups of stakeholders rather than set out to solve a pre-defined problem. The complexity of many organizational social problem situations defeats attempts at defining a problem.

It originates from the more general field of Systems Engineering, but have departed from the tradition of hard systems thinking (in which the perceived reality is considered systemic and inquiry systematic) into what is referred to as soft systems thinking (where perceived reality is problematic and inquiry is systemic). In their discussion of SSM and information systems development, Hirschheim et al. (1995:242) point out that soft system methodology is a framework which does not force or lead the systems analyst to a particular solution, rather to an understanding.



32

Soft system methodology has evolved through several versions, with as the most widely cited. The presentation in this section is taken from a revised version of soft system methodology.

Soft Systems Methodology is based on the following ideas:

1. Problems do not exist independent of human beings, they are constructs of the concerned mind, defined by individual world view; therefore look not at the problem but at the situation.

2. Interrelationship of problems = (multiple problem situation). 3. Worldview - different (and equally valid) interpretations of the world by each individual. 4. Solutions are also intellectual constructs and no problem exists in isolation. 5. Improvements in situations are most likely through sharing of perceptions, persuasion and

debate. Analysts should be interactive/therapeutic rather than expert. 6. Analysts cannot be divorced from the problem.

The SSM has seven stages. Some of them address the real world and some of them — perhaps the most important parts — address a conceptual world.

Stage one: Problem definition (situation)

At this stage we don’t actually define the problem but assess the general area that interests us. We collect as much data as we can, qualitative, quantitative, by whatever method seems appropriate - survey, observation, measurement.

Stage two: Problem situation expressed

Firstly the situation needs to be expressed in all its richness. Stating what the problem requires situational and problem analysis - comprehending the problem domain of interest. What exactly the problem is. Some guidelines as to what should be included.



33

• Structures

• Processes

• Climate People

• Issues expressed by people

Stage three-Root definitions of relevant systems Stage three moves out of the real world and into the world of systems. This is the Stage out of which everything else grows. That is why Checkland called it the root definition stage, and is the unique and most challenging part of the methodology. The first step is to understand the concept of different perspectives that are possible to draw out of the rich picture.

Part of problem expression is identifying the situational elements and parties involved. Checkland uses the CATWOE to describe the human activity and situation.

CATWOE

• Clients - those who more or less directly benefit or suffer e.g. customers from the machinations.

• Actors - the players such as individuals, groups, institutions and agencies, who perform the scenes, read and interpret the script, regulate, push and improvise. Identify and examine the role of local and institutional actors. Owner to whom the system is answerable. Actors who facilitates the transformation to these customers

• Transformations- from start to finish. • Weltanschauung or world-view - what is going on in the wider world that is influencing and

shaping the situation and need for the system to adapt. what gives the transformation some meaning

• Owners - the activity is ultimately controlled or paid for by owners or trustees. Ownership and the human.

• Environment - The trends, events and demands of the political, legal, economic, social, demographic, technological, ethical, competitive, natural environments provide the context for the situation and specific problem arena. Environment that influences but does not control the system.

Stage four-Developing the model

Using the root definition you draw up a conceptual model using systems conventions. There are lots of ways of doing this, but Checkland recommends that beginners follow the process below:



34

1. Using verbs in the imperative write down activities necessary to carry out the Transformation.

2. Select activities which could be done at once i.e. not dependent on others.

3. Place these activities in a line, and then those that are dependent on these first activities in a line; continue until all are accounted for.

4. Indicate the dependencies.

5. Rearrange to avoid overlapping arrows where possible. Add a means of assessing performance and include the aspects of the environment identified in CATWOE.

6. Finally check whether your model demonstrates the following systems properties:

• A means of assessing performance.

• A decision taking process

• Components that are also systems i.e. the notion of sub-systems.

• Components that interact

• An environment with which the system may or may not interact.

• A boundary between the system and the environment that may be closed or open.

• Resources

• Continuity

Stage five- Compare Model and Real World. Gain Insights

Checkland suggests four ways of doing this:

• Unstructured discussions

• Structured questioning of the model using a matrix approach

• Scenario or dynamic modeling

• Trying to model the real world using the same structure as the conceptual model



35

The second is the most common — often using a matrix that looks at each component the model and asks:

• Does it exist in the real world?

• How does it behave?

• How is its performance identified and measured?

• Is this process any good?

Step six-Develop desirable and feasible interventions

At this point the methodology tends to stop being sequential and starts swinging back and forth through all seven stages of the methodology in order to gain the greatest leverage. On the basis of this analysis possible interventions are explored. Assessing the feasibility of these interventions are an important aspect of the methodology, and Checkland suggests several ways of doing this.

Stage seven-Action to Improve the Situation

This is where the methodology comes full cycle, and maybe starts a new cycle (rather like the cycles of expansive learning in Cultural-Historical Activity Theory)

System thinking

System thinking is the process of understanding how things influence one another within a whole. System thinking, in contrast, focuses on how the thing being studied interacts with the other constituents of the system - a set of elements that interact to produce behavior - of which it is a part. This means that instead of isolating smaller and smaller parts of the system being studied, systems thinking works by expanding its view to take into account larger and larger numbers of interactions as an issue is being studied. This results in sometimes strikingly different conclusions than those generated by traditional forms of analysis, especially when what is being studied is dynamically complex or has a great deal of feedback from other sources, internal or external.

In nature, systems thinking examples include ecosystems in which various elements such as air, water, movement, plants, and animals work together to survive or perish. In organizations, systems consist of people, structures, and processes that work together to make an organization healthy or unhealthy. System thinking has been defined as an approach to problem solving, by viewing problems as parts of an overall system, rather than reacting to specific part, outcomes or events and potentially contributing to further development of unintended consequences.



36

System thinking is not one thing but a set of habits or practices within a framework that is based on the belief that the component parts of a system can best be understood in the context of relationships with each other and with other systems, rather than in isolation. System thinking focuses on cyclical rather than linear cause and effect.

The concept of a system

Science systems thinkers consider that:

• A system is a dynamic and complex whole, interacting as a structured functional unit. • Energy, material and information flow among the different elements that compose the system. • A system is a community situated within an environment. • Energy, material and information flow from and to the surrounding environment via semi-

permeable membranes or boundaries. • Systems are often composed of entities seeking equilibrium but can exhibit oscillating, chaotic,

or exponential behavior.

A holistic system is any set of interdependent or temporally interacting parts. Parts are generally systems themselves and are composed of other parts, just as systems are generally parts or holons of other systems.

Science systems and the application of science systems thinking has been grouped into three categories based on the techniques used to tackle a system:

• Hard systems - involving simulations, often using computers and the techniques of operations research. Useful for problems that can justifiably be quantified. However it cannot easily take into account unquantifiable variables (opinions, culture, politics, etc), and may treat people as being passive, rather than having complex motivations.

Hard systems thinking is an approach to real-world problems in which an objective or end-to-be-achieved can be taken as given. Then, to meet or achieve the objective, a system is engineered. Problem solving according to this view consists of defining S1 and S0 and selecting the best means or ways of reducing the difference between them. In systems engineering (S1- S0) defines the need, or the objective to be attained, and systems analysis provides an ordered way of selecting the best among the alternative systems which could fulfill that need or objective. Problems of this kind are called hard problems or structured problems. A relevant point in hard systems thinking is that the problem is structured: there is a gap in between the desired future state and the present state; how to make the gap disappear is the problem. This can be contrasted to research made in using system ideas to tackle soft, unstructured problems. Hard system thinking makes use of the kind of thinking which is natural to design engineers. The role of a design engineer is considered to be to provide an efficient way of meeting a defined need. The design engineer works in a situation where what is required has been defined; his job is to examine how it can be provided.

• Soft systems - for systems that cannot easily be quantified, especially those involving people holding multiple and conflicting frames of reference. Useful for understanding motivations, viewpoints, and interactions and addressing qualitative as well as quantitative dimensions of problem situations. Soft system thinking, as opposed to hard systems thinking, is not goal-



37

directed in the sense that a particular study begins with the definition of the desired goal to be achieved. Hard systems thinking deals with structured problems. The research presented in this book concerns soft systems thinking, or more specifically, soft systems methodology for tackling unstructured problems with in the area of human activity systems. Unstructured problems are said to be soft problems. Such problems are more a feeling of unease with the situation in question than explicitly statable.

Structured problems are normally solved by (1) defining the problem; (2) taking action to solve the problem, then the problem is solved. Unstructured problems can not be tackled like this for two reasons. Firstly, such problems can not be defined although they can be detected or perceive'. Secondly, the contents of human activity systems are so multivarious, and the influences to which they are subject so many that time always modifies the problem, it modifies how the problem is perceived. Such perceptions are said to be always subjective and changing with time.

What we learn from system thinking

• Sometimes a system that we believe is failing is actually succeeding, but for a different purpose than we thought the system had

Systems Thinking can help us see that failing systems may really simply be designed for a purpose other than what we assume or have been told.

• Difficulties in solving problems often stem from the fact that problems do not occur in isolation, but in relation to each other

Systems thinking can help us see that what may seem an isolated problem is actually part of an interconnected network of related issues.

• Issues relate to each other in specific ways based on feedback cycles

Systems thinking can help us see the positive and negative feedback cycles that may be affecting an issue of importance to us.

• Attempting to solve complex issues without a systems thinking approach may lead to unintended consequences, despite our best intentions.

Systems thinking can help us avoid unintended consequences by making us aware of how they may be created by previously unrecognized feedback cycles or delays.

Cost benefit analysis

Cost benefit analysis is a technique for assessing the monetary social costs and benefits of a capital investment project over a given time period.

Cost benefit analysis is done to determine how well, or how poorly, a planned action will turn out. Cost benefit analysis finds, quantifies, and adds all the positive factors. These are the benefits. Then it



38

identifies, quantifies, and subtracts all the negatives, the costs. The difference between the two indicates whether the planned action is advisable.

Example 1

As an HOD mathematics computing department, you are proposing the purchase 1million computers to increase output. Before you can present the proposal to the principal, you know you need some facts to support your suggestion, so you decide to run the numbers and do a cost benefit analysis. You itemize the benefits. With the computers, you can produce increase performance by 20 per cent from the current percentage of 40 per cent. The old PII computers currently in use can be replaced. The results will be impressive hence attract more applicants. You are convinced these outweigh the costs.

Example 2

As the Production Manager, you are proposing the purchase of a 1 Million stamping machine to increase output. Before you can present the proposal to the Board of directors, you know you need some facts to support your suggestion, so you decide to run the numbers and do a cost benefit analysis.

You itemize the benefits. With the new machine, you can produce 100 more units per hour. The three workers currently doing the stamping by hand can be replaced. The units will be higher quality because they will be more uniform. You are convinced these outweigh the costs. There is a cost to purchase the machine and it will consume some electricity. Any other costs would be insignificant.

You calculate the selling price of the 100 additional units per hour multiplied by the number of production hours per month. Add to that two percent for the units that aren't rejected because of the quality of the machine output. You also add the monthly salaries of the three workers. That's a pretty good total benefit.

Then you calculate the monthly cost of the machine, by dividing the purchase price by 12 months per year and divide that by the 10 years the machine should last. The manufacturer's specs tell you what the power consumption of the machine is and you can get power cost numbers from accounting so you figure the cost of electricity to run the machine and add the purchase cost to get a total cost figure. You subtract your total cost figure from your total benefit value and your analysis shows a healthy profit. All you have to do now is present it to the VP, right? Wrong. You've got the right idea, but you left out a lot of detail.

Main Stages in the Cost Benefit Analysis

Stage 1

Calculation of social costs & social benefits. This would include calculation of tangible Benefits and Costs (i.e. direct costs and benefits), intangible Benefits and Costs (i.e. indirect costs and benefits – externalities). Sensitivity analysis of events occurring



39

Stage 2:

Discounting the future value of benefits - costs and benefits accrue over time. Individuals normally prefer to enjoy the benefits now rather than later – so the value of future benefits has to be discounted

Stage 3

Comparing the costs and benefits to determine the net social rate of return

Stage 4

Comparing net rate of return from different projects.

Cost benefit analysis evaluation methods

Return on investments (ROI)

ROI analysis compares investment returns and costs by constructing a ratio, or percentage. ROI analysis compares the magnitude and timing of investment gains directly with the magnitude and timing of investment costs. A high ROI means that investment gains compare favorably to investment costs.

In most ROI methods, an ROI ratio greater than 0.00 (or a percentage greater than 0%) means the investment returns more than its cost. When potential investments compete for funds, and when other factors between the choices are truly equal, the investment—or action, or business case scenario—with the higher ROI is considered the better choice, or the better business decision.

Example 1

A new sewing machine that is expected to cost 500,000 over the next five years and deliver an additional 700,000 in increased profits during the same time. What is the ROI for a new sewing machine?

ROI = Gains – Investments costs * 100

Investment costs

ROI = 700, 000 – 500, 000 * 100

500, 000

= 200,000 * 100



40

500, 000

= 40%

Competing Investments: ROI from Cash Flow Streams

This section illustrates ROI calculation from a cash flow stream for two competing investments. For example consider a five year project A and project B. business analysts will look first at the net cash flow streams from each investment. The net cash flow data and comparison table appear below.

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Total Net cash flow A 0 20 30 40 70 80 140 Net cash flow B 0 70 60 40 30 20 120

Two aspects of the data are apparent at once, Investment for project A has the greater overall net cash flow for the five year period.

In order to calculate ROI, the analyst needs to see both cash inflows and outflows for each period (year) as well as the net cash flow. The tables below show these figures for each investment, including also cumulative cash flow and Simple ROI for the investment at the end of each year.

Example 2

Consider the two projects below.

Project A

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Total Cash inflow A 0 40 50 75 95 105 365 Cash outflow A 100 20 20 35 25 25 225 Net Cash Flow A –100 20 30 40 70 80 240

Project B

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Total Cash inflow B 0 100 90 75 50 40 355 Cash outflow B 100 30 30 35 20 20 235 Net Cash Flow B –100 70 60 40 30 20 220



41

Project B

ROI = (Total inflow to the end of year 5) – (Total outflow to the end of year 5) * 100

Total outflow to the end of year 5

ROI = (0+100+90+75+50+50) – (100+30+30+35+20+20) * 100

100+30+30+35+20+20

ROI = 355 – 235 * 100

235

ROI = 120 * 100

235

ROI = 0.5106383 * 100

ROI = 51%

Net present value (NPV) and Discounted cash flow (DCF)

The Net Present Value (NPV) of a project indicates the expected impact of the project on the value of the firm. Projects with a positive NPV are expected to increase the value of the firm. When choosing among mutually exclusive projects, the project with the largest (positive) NPV should be selected. The NPV is calculated as the present value of the project's cash inflows minus the present value of the project's cash outflows.

Discounted Cash Flow (DCF) is a cash flow summary adjusted to reflect the time value of money. When discounted cash flow events in a cash flow stream are added together, the result is called the Net Present Value (NPV).

Future Value

What future money is worth today is called its Present Value (PV). What it will be worth in the future when it finally arrives is called its Future Value (FV).

FV = PV (1+i) n



42

Where FV = future value

PV = present value

i = interest (discount) rate

n= number of periods

Example

What is the future value (FV) in one year, of 1, 00 invested today, at an annual interest rate of 5%?

FV1 = PV (1+i) n

= 100 (1 + 0.05)1

= 105

Present Value

PV1 = FV

(1+i) n

Where

PV = present value

FV = future value

i = interest (discount) rate

n= number of periods

Example

What is the value today of a 1, 00 payment arriving in one year, using a discount rate of 5%?

PV1 = (100) / (1.0 + 0.05)1

= 100/ (1.05)

= 95

We should be able to see why PV will decrease if we either:



43

∗ Increase the interest rate

∗ Increase the number of periods before the FV arrives.

What is the Present Value of 1, 00 we will receive in 5 Years, using a 5% discount rate?

PV5 = 100 / (1.0 +0.05)5

= 100 / (1.276)

= 75.13

NPV = FV0 + FV1 + FV2 + FV3…………..FVn

(1+i) n0 (1+i) 1 (1+i) 2 (1+i) 3 (1+i) n

Example

Consider two competing investments in computer equipment. Each call for an initial cash outlay of 100, 000, and each return a total a 200, 000 over the next 5 years making net gain of Kshs 100, 000 But the timing of the returns is different, as shown in the table below (Case A and Case B), and therefore the present value of each year’s return is different. The sum of each investment’s present values is called the Discounted Cash flow (DCF) or Net Present Value (NPV). Using 10% discount rate again.

Payback Period

The Payback Period represents the amount of time that it takes a project to recover its initial cost. The payback period is the amount of time (measured in years) to recover the initial investment in a project.

Simple payback period

Net cash flow (FV) Net cash flow (FV)

Year 0 – 100 – 100

Year 1 60 20

Year 2 60 20

Year 3 40 40

Year 4 20 50

Year 5 20 10



44

Payback Period = Initial Investment Cost

(in years) Annual Operating Savings

Example 1

Consider the example of a shop evaluating the purchase of a still to recycle its waste solvent. The shop manager analyzes both his current operation and the option of using a still. The installation of a still will cost Kshs.70, 000. But provide a net annual operational savings of Kshs.40, 000. When the net annual savings is divided into the initial cost, the manager finds that the still will pay for itself in 1.7 years:

Payback Period = Initial Investment Cost

(in years) Annual Operating Savings

= 70, 000 40,000 = 1.75 yrs

Example 2

The previous example assumes that the annual cash flow is the same each year. In reality, there are significant costs such as depreciation and taxes that will cause cash flows to vary each year. If the annual cash flow differs from year to year, the payback period is determined when the accrued cash savings equal the initial investment costs (i.e., when the cumulative cash flow balance equals zero).

For example the initial investment in a project is Kshs.100, 000. The projected savings is Kshs.4,

000 for the first year, Kshs. 4,000 for the second year, Kshs.2, 500 for the third year, Kshs. 2,000

in the fourth year, and Kshs. 2,000 for the fifth year. What will be the payback period?



45

INTRODUCTION TO SYSTEM DESIGN

A collection of components that work together to realize some objective forms a system. Basically

there are three major components in every system, namely input, processing and output. In a system

the different components are connected with each other and they are

interdependent.

System Design The design phase decides how the system will operate, in terms of the hardware, software, and network infrastructure; the user interface, forms, and reports that will be used; and the specific programs, databases, and files that will be needed. Although most of the strategic decisions about the system were made in the development of the system concept during the analysis phase, the steps in the design phase determine exactly how the system will operate. The design phase has four steps:

1. The design strategy must be developed. This clarifies whether the system will be developed by the company’s own programmers, whether it will be outsourced to another firm or whether the company will buy an existing software package.

2. This leads to the development of the basic architecture design for the system that describes the hardware, software, and network infrastructure that will be used. In most cases, the system will add or change the infrastructure that already exists in the organization. The interface design specifies how the users will move through the system (e.g., navigation methods such as menus and on-screen buttons) and the forms and reports that the system will use.

3. The database and file specifications are developed. These define exactly what data will be stored and where they will be stored.

4. The analyst team develops the program design, which defines the programs that need to be written and exactly what each program will do.

This collection of deliverables (architecture design, interface design, database and file specifications, and program design) is the system specification that is handed to the programming team for



46

implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another decision is made by the project sponsor and approval committee about whether to terminate the project or continue. Design tools and methods

1. Flowcharts

The pictorial representation of the programs or the algorithm is known as flowcharts. It is a diagrammatic representation of the various steps involved in designing a system.

Flowchart symbols

A flowchart consists of a set of flowchart symbols ‘connected by arrows. Each symbol contains information about what must be done at that point and the arrow shows the flow of execution of the algorithm i.e. they show the order in which the instructions must be executed. The purpose of using flowcharts is to graphically present the logical flow of data in the system and defining major phases of processing along with the various media to be used.



47

Flowcharts are of three types:

• System flowcharts • Run flowcharts • Program flowcharts

a) System Flowcharts

System flowchart describes the data flow for a data processing system. It provides a logical diagram of how the system operates. It represents the flow of documents, the operations performed in data processing system. It also reflects the relationship between inputs, processing and outputs. Following are the features of system flowcharts:

• The sources from which data is generated and device used for this purpose. • Various processing steps involved. • The intermediate and final output prepared and the devices used for their storage.

This is a sample of system flowchart for the following algorithm:

• Prompt the user for the centigrade temperature.

• Store the value in C

• Set F to 32+(* C/5)

• Print the value of C , F

• Stop

System Flowchart



48

b) Run flowcharts

Run flowcharts are used to represent the logical relationship of computer routines along with inputs, master files, transaction files and outputs.

Run Flowchart



49

(c) Program flowcharts

A program flowchart represents, in detail, the various steps to be performed within the system for transforming the input into output. The various steps are logical/ arithmetic operations, algorithms etc. It serves as the basis for discussions and communication between the system analysts and the programmers. Program flowcharts are quite helpful to programmers in organizing their programming efforts. These flowcharts constitute an important component of documentation for an application.



50

Strengths, weaknesses, and limitations of flowchart

A system flowchart is a valuable presentation aid because it shows how the system’s major components fit together and interact. In effect, it serves as a system roadmap. During the information gathering stage, a system flowchart is an excellent tool for summarizing a great deal of technical information about the existing system. A system flowchart can also be used to map a hardware system. System flowcharts are valuable as project planning and project management aids. Using the system flowchart as a guide, discrete units of can be identified, cost estimated, and scheduled. On large projects, the components suggest how the work might be divided into subsystems.

A system flowchart’s symbols represent physical components, and the mere act of drawing one implies a physical decision. Consequently, system flowcharts are poor analysis tools because the appropriate time for making physical decisions is after analysis has been completed.

A system flowchart can be misleading. For example, an on-line storage symbol might represent a diskette, a hard disk, a CD-ROM, or some combination of secondary storage devices. Given such ambiguity, two experts looking at the same flowchart might reasonably envision two different physical systems. Consequently, the analyst’s intent must be clearly documented in an attached set of notes.

2. Jackson Structured Programming

Jackson Structured Programming or JSP is a method for structured programming based on correspondences between data stream structure and program structure. The method is closely related in concept to creating a flowchart for a regular expression that describes the data stream structure, but tries to build a program structure that matches more than one data stream and provides guidance and techniques to compensate the limited look ahead and the clashes between the structures of the different data streams.

JSP was originally developed in the 1970s by IT consultant Michael A. Jackson and documented in his 1975 book Principles of Program Design. Jackson's aim was to improve the general standard of COBOL programming, but the method is still useful when coding with modern programming languages such as C and Perl. And while JSP was originally geared towards writing batch-style file processing programs, its principles are still useful when programming in the small, below the level where object-oriented methods become important.



51

JSP Diagrams and Notations

A Jackson Structured Programming diagram is used to explain the inner workings of a program. At a glance they seem similar to algorithm flowcharts, but the likeness is only superficial. With a JSP diagram each step on the same branch is performed top down - left to right.

With JSP diagrams there are three types of box notations used to represent the workings of a program.

All programs have three control structures Sequence, Selection and Iteration.

JSP structures programs in terms of four component types:

• Fundamental operations • Sequences • Iterations • Selections



52

1. Sequence

2. Selection



53



54

3. Iteration



55

Comparative review of JSP and traditional Flowcharting

A diagrammatical comparison between traditional flowcharting and JSP methodology is covered in this section. A snap shot picture between the designs clearly shows that JSP is found to be simplistic, clear and avoids the fuzziness shown by the flowchart method. The JSP methodology tends to avoid the fuzziness that can be created by too many notations adopted by flowcharting.



56



57

3. Jackson structured development (JSD)

Jackson System Development (JSD) is a method of system development that covers the software life cycle either directly or, by providing a framework into which more specialized techniques can fit. Jackson System Development can start from the stage in a project when there is only a general statement of requirements. However, many projects that have used Jackson System Development actually started slightly later in the life cycle, doing the first steps largely from existing documents rather than directly with the users. The later steps of JSD produce the code of the final system. Jackson’s first method, Jackson Structured Programming (JSP), is used to produce the final code. The output of the earlier steps of JSD is a set of program design problems, the design of which is the subject matter of JSP. Maintenance is also addressed by reworking whichever of the earlier steps are appropriate.

From the technical point of view there are three major stages in Jackson System Development, each divided into steps and sub-steps.



58

The Modeling Stage

In the modeling stage the designer creates a collection of entity structure diagrams and identifies the

entities in the system, the actions they perform, the time-ordering of the actions in the life of the

entities, and the attributes of the actions and entities. Entity structure diagrams use the diagramming

notation of Jackson Structured Programming structure diagrams.

Purpose of these diagrams is to create a full description of the aspects of the system and the

organization. Developers have to decide which things are important and which are not. Good

communication between developers and users of the new system is very important.

Entity is any object that is important in the system, which is modeled. Each entity may have a set of

actions to perform. Action may be characterized by:

1. It takes place at a point in time. A process cannot be an action, because it takes place over a

period of time.

2. It must take place in the real world, outside of the system.

3. It cannot be decomposable into sub actions.

Entity is characterized by:

1. It performs an action or undergoes an action in time.

2. It must exist in the real world. It cannot be a construct of the system that models the real

world.

3. It must be regarded as individual.

In the Entity/Action Step we make a list of candidate entities and actions. To every action we assign

an associated entity and set of attributes. Next, in the Entity Structure Step, we introduce constraints

in the ordering of an entity's actions. A structure diagram is made.

This stage is the combination of the former Entity/Action Step and the Entity Structures Step.

In the modeling stage the developers make a description of the aspects of the business or organization that the system will be concerned with. To make this a description they must analyze their business, choosing what is relevant and ignoring what is not. They have to consider the organization as it will be, not as it is now.



59

The model description is written very precisely. This precision forces the developer to ask detailed questions. It encourages good communication and understanding between developers, users, and everyone else involved with the new system.

The model description consists of actions, entities and related information. An action is an event, usually in the external reality, that is relevant to the system and whose occurrence the system must record. In implementation terms, actions might cause database updates. We start Jackson System Development by making a list of actions with definitions and associated attributes. Diagrams describe ordering relationships between actions. The diagrams describe the entities, people or, things that the system is concerned with.

The data that is to be stored for each entity is then defined. In effect we are choosing what is to be remembered by each entity about the actions that affect it. The full definition of this data includes an elaboration of the entity diagram to show in detail the update rules.

The result of the modeling stage is a set of tables, definitions and diagrams that describe:

• in user terms exactly what happens in the organization and what has to be recorded about what happens, and

• in implementation terms, the contents of the database, the integrity constraints and the update rules.

The Network Stage

In the network stage a model of the system as a whole is developed and represented as a system

specification diagram (SSD) (also known as a network diagram). Network diagrams show processes

(rectangles) and how they communicate with each other, either via state vector connections

(diamonds) or via data stream connections (circles).

In this stage is the functionality of the system defined. Each entity becomes a process or program in

the network diagram. External programs are later added to the network diagrams. The purpose of

these programs is to process input, calculate output and to keep the entity processes up-to-date. The

whole system is described with these network diagrams and is completed with descriptions about the

data and connections between the processes and programs.

The Initial Model Step specifies a simulation of the real world. The Function Step adds to this

simulation the further executable operations and processes needed to produce output of the system.

System Timing Step provides synchronization among processes, introduces constraints. This stage is

the combination of the former ‘Initial model’ step, the ‘Function’ step and the ‘System Timing’ step.



60

In the network stage we build up a precise description of what the system has to do, including the outputs that are to be produced and the way the system is to appear to the user. This description is in terms of a network of programs. We start this network by making one program for each of the entities that was defined during the modeling stage. The network is then built up incrementally by adding new programs and connecting them up to the existing network. New programs are added for the following reasons:

• To collect inputs for actions, check them for errors, and pass them to the entity programs. In this way entity programs are kept up-to-date with what's happening outside;

• To generate inputs for actions that do not correspond to external events. Such actions are substitutes for real world events, perhaps because those events cannot be detected;

• To calculate and produce outputs.

There are two means of connecting programs in the network. These are by data streams (represented on our network diagram of circles) and by state vector inspection (represented on our network diagrams by diamonds). Whatever kind of connection is appropriate; the entity programs play a pivotal role in the construction of the network. Most of the new programs can be connected directly to the entity programs.

We draw a whole set of network diagrams to describe the system. Different networks usually only have entity programs in common. The complete system is represented by the overlay of all the diagrams.

The diagrams are supported by textual information describing the contents of the data streams and state vector connections. The new programs that are added to the network are defined using the same diagrammatic notation used to describe the ordering of actions. These new programs are designed using the JSP (Jackson Structured Programming) method, which is now a subset of JSD.

The Implementation Stage

In the implementation stage the abstract network model of the solution is converted into a physical

system, represented as a system implementation diagram (SID). The SID shows the system as a

scheduler process that calls modules that implement the processes. Data streams are represented as

calls to inverted processes. Database symbols represent collections of entity state-vectors, and there

are special symbols for file buffers (which must be implemented when processes are scheduled to run

at different time intervals).

The central concern of Implementation Step is optimization of system. It is necessary to reduce the

number of processes because it is impossible to provide each process that is contained in specification

with its own virtual processor. By means of transformation, processes are combined in order to limits

their number to the number of processors.



61

The result of the implementation stage is the final system. This stage is the only one directly concerned with the machine and the associated software on which the system is to run. Therefore, as well as producing and testing code, the implementation stage covers physical design issues. In particular it covers:

• physical data design, and • reconfiguring the network by combining programs.

Physical data design is about the design of files or databases. The details of database design depend on the particular DBMS being used. However, the necessary information about the application is all available from the network stage. The most important is the data defined for each entity and the high volume accessing of that data as defined by the frequently used state vector connections.

The result of the network stage is a highly distributed network of programs. Often, for convenience or efficiency, we convert programs into subroutines, in effect combining several programs into one, so that a fragment of the network is implemented as a single program. The network is reconfigured from a form appropriate for specification into a form appropriate for implementation.

Projects and Plans

We have presented the three stages of JSD as a simple linear progression. On a project, however, the stages overlap to a greater or lesser degree, and not just because people make mistakes that have to be corrected later. The stages and substages are nevertheless important because they classify and organize the technical work, they clarify the choices open to a project manager, and illuminate the risks when a decision has to be taken out of order.

The following are some examples of the overlap of the stages:

• We can start adding programs to the network before the model is complete. • The detail designed of many of the simpler programs in the network can be done at the same

time they are implemented. • The physical data designed can be started before the low frequency programs have been added

to the network. • We may do a little each of model, network and implementation as the basis of a feasibility

study. • On a large project the model-network-implementation of one release may overlap with that of

the next.

None of these overlapping is compulsory. A set of circumstances exists that makes each sensible. A project plan is made based on the technical framework of JSD and on the political and organizational circumstances of the project.



62

4. Prototyping

Prototyping is the process of building a model of a system. In terms of an information system, prototypes are employed to help system designers build an information system that intuitive and easy to manipulate for end users. Prototyping is an iterative process that is part of the analysis phase of the systems development life cycle. Creating a scaled-down or incomplete version of a system to demonstrate or test aspects of the system

During the requirements determination portion of the systems analysis phase, system analysts gather information about the organization's current procedures and business processes related the proposed information system. In addition, they study the current information system, if there is one, and conduct user interviews and collect documentation. This helps the analysts develop an initial set of system requirements. Prototyping can augment (enlarge) this process because it converts these basic, yet sometimes intangible, specifications into a tangible but limited working model of the desired information system. The user feedback gained from developing a physical system that the users can touch and see facilitates an evaluative response that the analyst can employ to modify existing requirements as well as developing new ones. Prototyping comes in many forms - from low tech sketches or paper screens(Pictive) from which users and developers can paste controls and objects, to high tech operational systems using CASE (computer-aided software engineering) or fourth generation languages and everywhere in between. Many organizations use multiple prototyping tools. For example, some will use paper in the initial analysis to facilitate concrete user feedback and then later develop an operational prototype using fourth generation languages, such as Visual Basic, during the design stage. Importance of prototyping

• Aids UI design

• Provides basis for testing

• Team-building

• Allows interaction with user to ensure satisfaction

Advantages of Prototyping:

• Reduces development time.

• Reduces development costs.

• Requires user involvement.

• Developers receive quantifiable user feedback.

• Facilitates system implementation since users know what to expect.

• Results in higher user satisfaction.

• Exposes developers to potential future system enhancements.



63

Disadvantages of Prototyping

• Can lead to insufficient analysis.

• Users expect the performance of the ultimate system to be the same as the prototype.

• Developers can become too attached to their prototypes

• Can cause systems to be left unfinished and/or implemented before they are ready.

• Sometimes leads to incomplete documentation.

• If sophisticated software prototypes (4th GL or CASE Tools) are employed, the time saving benefit of prototyping can be lost.

Prototype An easily modified and extensible model (representation, simulation or demonstration) of a planned software system, likely including its interface and input/output functionality. A prototype is simply a stripped-down model of the system, focusing on how the windows will look and how the user can navigate between the windows. Its purpose is to provide a better view of the final system than just words, or even words combined with hard-copy pictures of windows, can provide.

Characteristics of a good non-disposable prototype

• Executability Works sufficiently well with live user input to permit usability testing

• Maturation Can evolve, given sufficient refinement, into the final product

• Representation Has the "look and feel" and performance characteristics of the planned system

• Scope As a minimum, simulates the 20% of the functions that customers will use 80% of the time

The prototyping process or stages

• Perform customer needs analysis in a JAD session but leave requirements incomplete.

• Build a low-fidelity prototype to clarify initial requirements.

• Iterate (re-specify, re-design, re-evaluate) until the team, both users and developers, agree that the fidelity and completeness of the evolving prototype are sufficiently high.

• Freeze these specifications.

• Finish building the product exactly as prototyped.

• The prototyping process experiences a series of birthdays while traditional software development experiences a series of deadlines.



64

Type of prototyping

• Paper Prototyping

It is a cost-efficient method where users attempt to complete realistic tasks by interacting with a paper version of the interface, created in a drawing program, as in a drawing program or in HTML. The participant works with the paper screens by signifying the actions they would take. In turn, a person playing the role of the computer administers the screens in the order that the user expects to see them. The person acting as the computer, does not guide or instruct the participant, but simply administers the screens. An observer can take notes, or the session can be videotaped, if only one person is administering the paper prototypes.

• Rapid Prototyping

can be any of a variety of processes which avoids tooling time in producing prototypes or prototype parts and consequently allows (generally non-functioning) prototypes to be produced within hours or days rather than weeks. These prototypes are frequently used to quickly test the product's technical feasibility or consumer interest.

• Virtual Prototyping

It is computer-based prototyping without the option of a physical part or object. It uses virtual to create product prototypes and test their properties.

• Incremental Prototyping

Evolves well-built prototypes into a component that is delivered in either an increment or a complete computer system.

• Conventional Prototyping

It is the calculative category where most conventional prototyping processes fall. These would include machining processes like milling, turning, and grinding. Machining methods are difficult to use on parts with very small internal cavities or complex geometry.



65

Throw away prototyping



66

Structured English

Structured English is one more tool available to the analyst. It comes as an aid against the problems of ambiguous language in stating condition and actions in decisions and procedures. Here no trees or tables are employed; rather with narrative statements a procedure is described. Thus it does not show but states the decision rules. The analyst is first required to identify the conditions that occur in the process, subsequent decisions, which are to be made and the alternative actions to be taken.

Here the steps are clearly listed in the order in which they should be taken. There are no special symbols or formats involved unlike in the case of decision trees and tables, also the entire procedure can be stated quickly as only English like statements are used.

Structured English borrows heavily from structured programming as it uses logical construction and imperative statements designed to carry out instructions for actions. Using "IF", "THEN", "ELSE" and "So" statement decisions are made. In this structured description terms from the data dictionary are widely used which makes the description compact and straight.

The two building blocks of Structured English are (1) structured logic or instructions organized into nested or grouped procedures, and (2) simple English statements such as add, multiply, move, etc. (strong, active, specific verbs)

Five conventions to follow when using Structured English:

• Express all logic in terms of sequential structures, decision structures, or iterations.

• Use and capitalize accepted keywords such as: IF, THEN, ELSE, DO, DO WHILE, DO UNTIL, PERFORM

• Indent blocks of statements to show their hierarchy (nesting) clearly.

• When words or phrases have been defined in the Data Dictionary, underline those words or phrases to indicate that they have a specialized, reserved meaning.

• Be careful when using "and" and "or" as well as "greater than" and "greater than or equal to" and other logical comparisons.

Developing Structured Statements

Three basic types of statements are employed to describe the process.

1. Sequence Structures - A sequence structure is a single step or action included in a process. It is independent of the existence of any condition and when encountered it is always taken. Usually numerous such instructions are used together to describe a process.

2. Decision Structures - Here action sequences described are often included within decision structures that identify conditions. Therefore these structures occur when two or more actions can



67

be taken as per the value of a specific condition. Once the condition is determined the actions are unconditional.

3. Iteration Structures- these are those structures, which are repeated, in routing operations such as DO WHILE statements.

The decision structure of example discussed in previous sections may be given in structured English as in the figure shown above

Functional decomposition

Breakdown of a list of items into classifications or groups on the basis of the function each item performs or is used for.

Breaking down a process into non-redundant operations. In structured programming, it provides a hierarchical breakdown of the program into the individual operations, or routines, that are required.

Decomposition is the process of starting at a high level and dividing entities into smaller and smaller related parts. Functional decomposition is a business analysis technique for breaking down a “business operation” into functional components. A Functional Decomposition Diagram (FDD) shows a hierarchical organization of the business functions that comprise the business operation. It does not show the sequence of events. A FDD is distinct from a process flow diagram (PFD), which shows the sequence of events of a business operation or function.



68

Why is functional decomposition used?

The main purpose of functional decomposition is to break up a large or complex business operation or function into smaller and more manageable chunks. It therefore facilitates understanding of the business operation or function and hence is a useful tool in conducting analysis and design. Functional decomposition is used in determining the functional requirements of a solution and in defining these in the functional requirements document. A large or complex function is more easily understood when broken down using functional decomposition. Functional decomposition can be used to break up a large or complex business operation into smaller components, prior to developing process flow diagrams.

How to perform functional decomposition

• Organise a meeting with the experts, the people managing and working with the business operation.

• Identify and name the business operations to be decomposed

• For each business operation, start at the top level and ask “what does this business operation consist of?” Draw the first level components.

• Decompose the first level components with their functions and continue to decompose to lower levels until sufficient level of detail is achieved.

• Hand draws the initial functional decomposition in front of the expert, getting them to confirm the components.

• Ask questions to determine the purpose of each function and record this information.

How to perform functional decomposition

Check for completeness:

• Is the whole business operation represented? • Are all components shown

• Are the connections between the components correct?

• Refine as necessary.

Review with the experts:

• Do an end to end walk-through of the business operation, checking each function to confirm that it is correct.

• Ask if there are any other areas of the business operation that are not already covered.



69

A sample Functional Decomposition Diagram

Levels of Detail for Functional Decomposition

Enterprise Level of Detail At the enterprise level , the root of the Function Chart may contain the name of the organization (or a major function or sub-function within an organization). The root is broken down into no more than three levels of detail. A brief description is provided for each function.

The second level identifies major business functions, typically related to Planning, Execution, and Control.



70

Note that administrative functions such as Finance, Accounting, and Personnel should not be top level functions. Top level functions should only be functions that directly contribute to the production of an organization's product or service. Administrative functions should only be further decomposed if required, for example, if a system is being developed to support administrative functions. Because Function Charts read so similarly to Organization Charts, i.e., both use a top-down structure, it can be politically very difficult to convince the Corporate Vice President of Finance and Personnel, for example, that his or her function is not a top level function. One method of addressing this is to draw separate Function Charts for each of the administrative functions so that each has its own top level Function Chart. This does not take much time, gets these functions included in the documentation, and works well as long as the charts are not further expanded. Another method of addressing this is to include administrative functions under a function called, for instance, Organizational Support.

Conceptual Level of Detail At the conceptual level, leaf level functions (i.e., lowest level functions) on the enterprise level chart within the context of the system are decomposed into the next level of detail. This level identifies the major business processes necessary to accomplish each function. Processes identified at this level typically correspond to application systems or sub-systems, for example, Sales, Finance, or Purchasing.

Functional Decomposition at the conceptual level of detail helps define the scope of a project.



71

Logical Level of Detail

At the logical level, the Function Chart decomposes processes into the lowest level of detail. Functional Decomposition at this level identifies all the processes within the scope of the project. The lowest level processes on the Function Chart can be documented using Action Diagrams, Structured English, or Pseudocode.

Drawing functional decomposition

Start by

• identifying high level process

• then break them down into sub-process until they cannot be decomposed or broken down any further

• each process has an action word in it such as o Add o Delete o Sort o Search

Structured walkthrough

As a new system is developed, structured walkthrough is the meeting together of programmers and/or analysts on a regular basis to evaluate (i.e. walkthrough) their designs or codes. These walkthroughs provide constructive criticism and the opportunity to detect and correct logic errors before the testing phase of systems development occurs.

Top-Down Analysis

In top-down analysis, the analyst begins with an overview of the entire system and gradually progresses until details at the lowest level are understood. This is an interactive process such that the analysis, design, coding, testing, and installation steps occur at each level. The greatest benefit to top-down analysis is that the difficult interface bugs are found early in the development process rather than at the end.



72

CASE tools

C - Computer

A - Aided, Assisted, Automated

S - System, Software

E - Engineering

CASE is a category of software tools which aid a developer to create and maintain software. A CASE tool is a software tool that automates a particular task within the System Development Life Cycle. CASE tools are automated, microcomputer-based (PC-based) software packages for systems analysis and design. Reasons to use CASE tools are:

• to increase analyst productivity • to facilitate communication among analysts and users • to provide continuity between life cycle phases • to assess the impact of maintenance

Upper CASE (front-end CASE) tools are used to perform analysis and design. Lower CASE (back-end CASE) tools generate computer language source code from CASE design. The advantages of generating source code include:

• the time to develop new systems decreases • the time to maintain generated code is less than to maintain traditional systems • computer programs may be generated in more than one programming language • CASE design may be purchased from third-party vendors and tailored to organizational needs • generated code is free from programming coding errors

The automation of methodology that assists in systems development and software engineering is called computer aided software engineering (CASE). The term software engineering is associated with a few well-known methodologies such as Warnier-Orr Diagrams and data flow diagrams. Systems analysis and design of business application systems, including accounting systems, once used methodologies that were primarily based on pencils and templates. Recently developed methodologies, such as CASE, are employing design automation techniques linked to code generators as well as computer-aided planning and analysis. CASE has been defined as a corporate philosophy that imposes the engineering discipline on the development of application software. CASE focuses on the entire systems development life cycle (SDLC) from preliminary design to analysis to implementation to maintenance. Creating application software involves numerous stages that overlap. Stages of software development include many different activities and require different tools and techniques from the point of conception through the maintenance of the finished system. The features of CASE tools assist the developer in all stages of the SDLC: planning, system analysis, system design, system implementation, operation, and maintenance.



73

Decision Tables

A decision table is a tabular form that presents a set of conditions and their corresponding actions. The decision table is a chart with four sections listing all the logical conditions and actions. In addition the top section allows space for title, date, author, system and comment.

Condition Stubs Condition stubs describe the conditions or factors that will affect the decision or policy. They are listed in the upper section of the decision table.

Action Stubs Action stubs describe, in the form of statements, the possible policy actions or decisions. They are listed in the lower section of the decision table.

Rules Rules describe which actions are to be taken under a specific combination of conditions. They are specified by first inserting different combinations of condition attribute values and then putting X's in the appropriate columns of the action section of the table.



74

Sections of a decision table

TITLE : Author : Comments :

DATE : System :

Condition Stub Condition Entry

Action Stub Action Entry

The condition stub contains a list of all the necessary tests in a decision table. In the lower left-hand corner of the decision table we find the action stub where one may note all the processes desired in a given module. Thus Action Stub contains a list of all the processes involved in a decision table.

The upper right corner provides the space for the condition entry-all possible permutations of yes and no responses related to the condition stub. The yes and no possibilities are arranged as a vertical column called rules. Rules are numbered 1, 2, and 3 and so on. We can determine the rules in a decision table by the formula:

Number of rules = 2^N = 2N where N represents the number of condition and ^ means exponentiate. Thus a decision table with four conditions has 16 (24 = 2 x 2 x 2 x 2 = 16) rules one with six conditions has 64 rules and eight conditions yield 256 rules.

The Condition entry contains a list of all the yes/no permutations in a decision table. The lower right corner holds the action entry. X’s or dots indicate whether an action should occur as a consequence of the yes/no entries under condition entry. X’s indicate action; dots indicate no action. Thus Action entry indicates via dot or X whether something should happen in a decision table.

Example 1

In Kisii level 5 hospital no charges are reimbursed to the patient until the deductible has been met. After the deductible has been met, reimburse 50% for Doctor's Office visits or 80% for Hospital visits.

There will be 4 rules. The first condition (Is the deductible met?) has two possible outcomes, yes or no. The second condition (type of visit) has two possible outcomes, Doctor's office visit (D) or Hospital visit (H). Two times two is four.



75

Conditions 1 2 3 4

1. Deductible met? Y Y N N

2. Type of visit D H D H

Actions

1. Reimburse 50% X . . .

2. Reimburse 80% X . .

3. No reimbursement . . X X

Example 2

In Kisii level 5 hospital no charges are reimbursed to the patient until the deductible has been met. After the deductible has been met, the amount to be reimbursed depends on whether or not the doctor or hospital is a Preferred Provider. For preferred providers Doctor's office visits are reimbursed at 65% and Hospital visits are reimbursed at 95%. For other providers reimburse 50% for Doctor's Office visits or 80% for Hospital visits.

There will be 8 rules. The first condition (Is the deductible met?) has two possible outcomes, yes or no. The second condition (Is it a Preferred Provider?) has two possible outcomes, yes or no. The third condition (type of visit) has two possible outcomes, Doctor's office visit (D) or Hospital visit (H). Two times two times two is 8.

Conditions 1 2 3 4 5 6 7 8

1. Deductible met? Y Y Y Y N N N N

2. Preferred Provider? Y Y N N Y Y N N

3. Type of visit D H D H D H D H

Actions

1. Reimburse 65% X

2. Reimburse 95% X

3. Reimburse 50% X

4. Reimburse 80% X

5. No reimbursement X X X X



76

Example 3

In Kisii level 5 hospital no charges are reimbursed to the patient until the deductible has been met. Doctor's office visits are reimbursed at 50%, Hospital visits are reimbursed at 80% and Lab visits are reimbursed at 70%.

There will be 6 rules. The first condition (Is the deductible met?) has two possible outcomes, yes or no. The second condition (type of visit) has three possible outcomes, Doctor's office visit (D) or Hospital visit (H) or Lab visit (L). Two times three is 6.

Conditions 1 2 3 4 5 6

1. Deductible met? Y Y Y N N N

2. Type of visit D H L D H L

Actions

1. Reimburse 50% X

2. Reimburse 80% X

3. Reimburse 70% X

4. No reimbursement X X X

Example 4

No charges are reimbursed to the patient until the deductible has been met. Hospital visits are reimbursed at 80% and Lab visits are reimbursed at 70%. Doctor's office visits are reimbursed at 90% for Participating Physicians or 50% for others. The question of whether the Doctor is a Participating Physician is only applicable for Doctor's office visits; it is not applicable for Hospital visits or Lab work.

There will be 12 rules. The first condition (Is the deductible met?) has two possible outcomes, yes or no. The second condition (type of visit) has three possible outcomes, Doctor's office visit (D) or Hospital visit (H) or Lab visit (L). There are two possible outcomes to the question of whether in the case of a Doctor's Office visit the Doctor is a Participating Physician, yes or no. Two times three times two is 12.

Conditions 1 2 3 4 5 6 7 8 9 10 11 12

1. Deductible met? Y Y Y Y Y Y N N N N N N

2. Type of visit D D H H L L D D H H L L

3. Participating Physician? Y N Y N Y N Y N Y N Y N

Actions

1. Reimburse 50% X

2. Reimburse 70% X

3. Reimburse 80% X

4. Reimburse 90% X

5. No reimbursement X X X X

6. Impossible or N/A X X X X



77

Example 5

Determine whether you need to wear a light jacket, heavy jacket, or no jacket at all when you leave the house. You need a heavy jacket if the temperature is below 50 degrees. You can make do with a light jacket if the temperature is between 50 and 70. At 70 and above you only need a light jacket if there is precipitation.

There will be 6 rules. The first condition (Is there rain?) has two possible outcomes, yes or no. The second condition (temperature) has three possible outcomes. Two times three is 6.

Conditions 1 2 3 4 5 6

1. Rain? Y Y Y N N N

2. Temperature Less than

50 Between 50-

70 More than

70 Less than

50 Between 50-

70 More than

70

Actions

1. Heavy Jacket X X

2. Light Jacket X X X

3. No Jacket X

Example 6

Hostel Assignment Decision Table

Conditions 1 2 3 4 5 6 7 8

1. Gender M M M M F F F F

2. Fresher Y Y N N Y Y N N

3. College A B A B A B A B

Actions

1. Mt. Kenya X X

2. Kilimanjaro X X X X

3. Ruwenzori X X



78

Leap Year Decision Table

Conditions 1 2 3 4 5 6 7 8

1. Divisible by 4 Y Y Y Y N N N N

2. Divisible by 100 Y Y N N Y Y N N

3. Divisible by 400 Y N Y N Y N Y N

Actions

1. Leap Year X X

2. Not Leap Year X X

3. Impossible X X X X

Example 7

If order is from book store

And if order is for 6 copies

Then discount is 25%

Else (if order is for less then 6 copies)

No discount is allowed

Else (if order is from libraries)

If order is for 50 copies or more


Else if order is for 20 to 49 copies


Else if order is for 6 to 19 copies

Then discount is 5%



79

Else (order is for less then 6 copies)

No discount is allowed

Example 8

A marketing company wishes to construct a decision table to decide how to treat clients according to three characteristics: Gender, City Dweller, and age group: A (under 30), B (between 30 and 60), C (over 60). The company has four products (W, X, Y and Z) to test market. Product W will appeal to female city dwellers. Product X will appeal to young females. Product Y will appeal to Male middle aged shoppers who do not live in cities. Product Z will appeal to all but older females.

1. Identify Conditions & Values The three data attributes tested by the conditions in this problem are gender, with values M and F; city dweller, with value Y and N; and age group, with values A, B, and C as stated in the problem.

2. Compute Maximum Number of Rules The maximum number of rules is 2 x 2 x 3 = 12

3. Identify Possible Actions The four actions are: market product W, market product X, market product Y, market product Z.

4. Enter All Possible Rules The top of the table would look as follows: Note that all combinations of values are present.



80

Rules Proc. 1 2 3 4 5 6 7 8 9 10 11 12 Name Sex F M F M F M F M F M F M City Y Y N N Y Y N N Y Y N N Age A A A A B B B B C C C C

5. Define Actions for each Rule The bottom of the table would look as follows: Market 1 2 3 4 5 6 7 8 9 10 11 12 W X X X X X X Y X Z X X X X X X X X X X

6. Verify the Policy Let us assume that the client agreed with our decision table.

7. Simplify the Table There appear to be no impossible rules. Note that rules 2, 4, 6, 7, 10, 12 have the same action pattern. Rules 2, 6 and 10 have two of the three condition values (gender and city dweller) identical and all three of the values of the non- identical value (age) are covered, so they can be condensed into a single column 2. The rules 4 and 12 have identical action pattern, but they cannot be combined because the indifferent attribute "Age" does not have all its values covered in these two columns. Age group B is missing. The revised table is as follows:

Rules Process 1 2 3 4 5 6 7 8 9 10 Gender F M F M F F M F F M City Dweller Y Y N N Y N N Y N N Age Group A - A A B B B C C C Actions Market 1 2 3 4 5 6 7 8 9 10 W X X X



81

X X X Y X Z X X X X X X X X

Decision Tree

The decision tree defines the conditions as a sequence of left to right tests. A decision tree helps to show the paths that are possible in a design following an action or decision by the user. Decision tree turns a decision table into a diagram. This tool is read from left to right, decision results in a fork, and all branches end with an outcome. Figure 6 illustrates the decision tree for the book order decision table we saw earlier.

Major steps in building Decision Trees:

• Identify the conditions

• Identify the outcomes (condition alternatives) for each decision

• Identify the actions

• Identify the rules.

Decision Tables are useful when complex combinations of conditions, actions, and rules are found or you require a method that effectively avoids impossible situations, redundancies, and contradictions. Decision Trees are useful when the sequence of conditions and actions is critical or not every condition is relevant to every action.

Basic Computer Programming Constructs:

• Sequence

• Selection (If-Else Conditional)

• Iteration (Loops)

Example 1

Decision Tree for Book Order



82

Application for a job decision tree

Assignment to students Study the decision table below and use it answer the questions that follow In Kisii level 5 hospital no charges are reimbursed to the patient until the deductible has been met. After the deductible has been met, reimburse 50% for Doctor's Office visits or 80% for Hospital visits.

There will be 4 rules. The first condition (Is the deductible met?) has two possible outcomes, yes or no. The second condition (type of visit) has two possible outcomes, Doctor's office visit (D) or Hospital visit (H). Two times two is four.

Conditions 1 2 3 4

1. Deductible met? Y Y N N

2. Type of visit D H D H

Actions

1. Reimburse 50% X . . .

2. Reimburse 80% X . .

3. No reimbursement . . X X

Required:

i. From the above decision table data draw a decision tree



83

Advantages of decision tables

• Are simple to understand and interpret. People are able to understand decision tree models after a brief explanation.

• Have value even with little hard data. Important insights can be generated based on experts describing and their preferences for outcomes.

• Use a white box model. If a given result is provided by a model, the explanation for the result is easily replicated by simple math.

• Can be combined with other decision techniques. • The writing and drawing can be taken over completely by the computer.

• A number of routine jobs that induce many errors when performed manually can be automated, e.g.: filling action entries, generating the complete set of condition combinations.

• Introducing a workbench in the design process provides interactive possibilities that simplify the design process, such as automatic checking for consistency, correctness and completeness.

• The system can be used for optimization purposes, such as optimal contraction, layout, and decomposition into subtables or conversion into efficient code.

• Making good use of the interfacing features of decision tables to other representation formalisms, such as program code, trees, rules, is only possible through flexible computer support.

Limitations

• Easy to understand

• Map nicely to a set of business rules

• Applied to real problems

• Make no prior assumptions about the data

• Able to process both numerical and categorical data

• Output attribute must be categorical

• Limited to one output attribute

• Decision tree algorithms are unstable

• Trees created from numeric datasets can be complex

• Decision-tree learners create over-complex trees that do not generalize the data well. This is called overfitting. Mechanisms such as pruning are necessary to avoid this problem.

• There are concepts that are hard to learn because decision trees do not express them easily, such as parity or multiplexer problems.



84

Structured charts IPO charts An IPO chart records the input, process, and output of a process, or program module. It is commonly used when designing spreadsheet formulas, calculated fields in databases, and algorithms in programming. Hierarchy charts are read from top to bottom and from left to right. The top module of the chart is a statement of the problem. At each lower level of the chart the problem is broken down into smaller parts. There are no special symbols for the IPO part of the task. Each numbered process box in the hierarchy chart would have one IPO diagram that identifies the process, lists its inputs and outputs, and lists the intervening processing. Example 1

Using IPO chart to calculate age of a student.

INPUT PROCESSING OUTPUT

Age

Ask what data is needed to generate this output; date of birth, current date


Date of birth, Current date Age

Finally, work out the algorithm (calculation strategy) to get the output from the input: in this case, find the number of days between the date of birth and the current date, divide by 365.25 to convert it to years.


Date of birth, Current date (Current Date - Date of Birth) / 365.25 Age



85

Example 2 Calculating the sum of two numbers


Sum

Ask what data is needed to generate this output; date of birth, current date


Num1,num2 Sum

Finally, work out the algorithm (calculation strategy) to get the output from the input: in this case, sum up num1 and num2 to get the total of the two numbers.


Num1, num2 Num1+num2 sum

HIPO charts

The acronyms HIPO stands for Hierarchy Input Process Output

The hierarchy chart is a top-down visual representation of the main process in the system. Since they use only two symbols they are simple to use and provide a good guide to the components of the problem. They can be expanded to any necessary level of detail, although usually a few levels will be adequate for most problems. The only major disadvantage of hierarchy diagrams is that they show only the structure of the program. It is hard to deduce much about the processing logic from just a hierarchy diagram.

There are only two symbols for hierarchy diagrams:

• Rectangle - represent a group of activities or module.

• Connecting line - connects the process boxes.



86

Example 1

DATA STRUCTURE TABLE

The table summarises field information in a table in a database.

Data structure diagrams



87

This diagram shows the relationships between tables in a database

DATA STRUCTURE CHARTS

Visually shows the structure of data – fields, records, tables etc.



88

System development life cycle II

Design

In systems design the design functions and operations are described in detail, including screen layouts, business rules, process diagrams and other documentation. The output of this stage will describe the new system as a collection of modules or subsystems.

The design stage takes as its initial input the requirements identified in the approved requirements document. For each requirement, a set of one or more design elements will be produced as a result of interviews, workshops, and/or prototype efforts.

Design elements describe the desired software features in detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudo code, and a complete entity-relationship diagram with a full data dictionary. These design elements are intended to describe the software in sufficient detail that skilled programmers may develop the software with minimal additional input design.

Design involves three important aspects:

• Output design

• Input design

• Storage design

Output design

Output is the primary purpose of any system. Output design is often discussed before other aspects of design because, from the client's point of view, the output is the system. Output is what the client is buying when he or she pays for a development project. Inputs, databases, and processes exist to provide output. Guidelines for both paper and screen outputs design.

• Problems often associated with business information output are information delay, information (data) overload, paper domination, excessive distribution, and nontailoring.

• Mainframe printers: high volume, high speed, located in the data center Remote site printers: medium speed, close to end user.

• COM is Computer Output Microfilm. It is more compact than traditional output and may be produced as fast as non-impact printer output.

• Turnaround documents reduce the cost of internal information processing by reducing both data entry and associated errors.



89

• Periodic reports have set frequencies such as daily or weekly; ad hoc reports are produced at irregular intervals.

• Detail and summary reports differ in the the former support day-to-day operation of the business while the latter include statistics and ratios used by managers to assess the health of operations.

• Page breaks and control breaks allow for summary totals on key fields.

• Report requirements documents contain general report information and field specifications; print layout sheets present a picture of what the report will actually look like.

• Page decoupling is the separation of pages into cohesive groups.

• Two ways to design output for strategic purposes are (1) make it compatible with processes outside the immediate scope of the system, and (2) turn action documents into turnaround documents.

• People often receive reports they do not need because the number of reports received is perceived as a measure of power.

• Fields on a report should be selected carefully to provide uncluttered reports, facilitate 80-column remote printing, and reduce information (data) overload.

• The types of fields which should be considered for business output are: key fields for access to information, fields for control breaks, fields that change, and exception fields.

• Output may be designed to aid future change by stressing unstructured reports, defining field size for future growth, making field constants into variables, and leaving room on summary reports for added ratios and statistics.

• Output can now be more easily tailored to the needs of individual users because inquiry-based systems allow users themselves to create ad hoc reports.

• An output intermediary can restrict access to key information and prevent unauthorized access.

• An information clearinghouse (or information center) is a service center that provides consultation, assistance, and documentation to encourage end-user development and use of applications.

• The specifications needed to describe the output of a system are: data flow diagrams, data flow specifications, data structure specifications, and data element specifications.



90

Output Design Objectives

• Assure Purposeful Output • Make Meaningful to User • Provide Appropriate Quantity • Appropriate Distribution • Assure Timeliness • Choose Effective Output Method

Choosing Output Technology

• Who will use/see the output? • How many people will need the output? • Where is the output needed (distribution/logistics) • What is the purpose of the output? • How quickly is the output needed? • How frequently will the output be accessed? • How long must the output be stored? • What special regulations apply? • What is the cost?

Output Documents

Printed Reports

• External Reports: for use or distribution outside the organization; often on preprinted forms. • Internal Reports: for use within the organization; not as "pretty", stock paper, greenbar, etc.

• Periodic Reports: produced with a set frequency (daily, weekly, monthly, every fifth Tuesday, etc.)

• Ad-Hoc (On Demand) Reports: irregular interval; produced upon user demand.

• Detail Reports: one line per transaction. • Summary Reports: an overview. • Exception Reports: only shows errors, problems, out-of-range values, or unexpected

conditions or events.

Input Design

• A source document differs from a turnaround document in that the former contains data that change the status of a resource while the latter is a machine readable document.

• Transaction throughput is the number of error-free transactions entered during a specified time period.



91

• A document should be concise because longer documents contain more data and so take longer to enter and have a greater chance of data entry errors.

• Numeric coding substitutes numbers for character data (e.g., 1=male, 2=female); mnemonic coding represents data in a form that is easier for the user to understand and remember. (e.g., M=male, F=female).

• The more quickly an error is detected, the closer the error is to the person who generated it and so the error is more easily corrected.

• An example of an illogical combination in a payroll system would be an option to eliminate federal tax withholding.

• By "multiple levels" of messages, Shneiderman means allowing the user to obtain more detailed explanations of an error by using a help option, but not forcing a lengthy message on a user who does not want it.

• An error suspense record would include the following fields: data entry operator identification, transaction entry date, transaction entry time, transaction type, transaction image, fields in error, error codes, date transaction reentered successfully.

• A data input specification is a detailed description of the individual fields (data elements) on an input document together with their characteristics (i.e., type and length).

Data Entry Methods

• keyboards • optical character recognition (OCR) • magnetic ink character recognition (MICR) • mark-sense forms • punch-out forms • bar codes • intelligent terminals

Interactive Screen Design

The seven step path that marks the structure of an interactive system is

• Greeting screen (e.g., company logo)

• Password screen -- to prevent unauthorized use

• Main menu -- allow choice of several available applications

• Intermediate menus -- further delineate choice of functions

• Function screens -- updating or deleting records

• Help screens -- how to perform a task

• Escape options -- from a particular screen or the application



92

.

Storage design

Designing the File or Database

The objectives in the design of data storage organization are:

• The data must be available when the user wants to use it. • The data must be accurate and consistent. • Efficient storage of data as well as efficient updating and retrieval • It is necessary that information retrieval be purposeful. • The information obtained from the stored data must be in an integrated form to be useful for

managing, planning, controlling, or decision making.

There are two approaches to the storage of data in computer-based systems. The first method is to store the data in individual files, each unique to a particular application. A file can be designed and built quite rapidly, and the concerns for data availability and security are minimized. Also, systems analysts can choose an appropriate file structure according to the required processing speed of the particular application system. The second approach to the storage of data in a computer-based system involves building a database, which is a formally defined and centrally controlled store of data intended for use in many different applications.

The effectiveness objectives of the database include:

• Ensuring that data can be shared among users for a variety of applications • Maintaining data that are both accurate and consistent • Ensuring all data required for current and future applications will be readily available • Allowing the database to evolve and the needs of the users to grow • Allowing users to construct their personal view of the data without concern for the way the

data are physically stored

Keys are data items in a record that are used to identify the record. Key fields are used for record retrieval (lookup). There are different types of keys:

• Primary Key. Uniquely identifies a record. • Secondary Key. May not be unique. • Concatenated Key. The key consists of a combination of two or more fields. • Foreign Key. A field in one record that is the key of another record. Used for linking a record

in one file or table with a record in another file or table.

A file contains groups of records used to provide information for operations, planning, management, and decision making. Files can be used for storing data for an indefinite period of time or they can be used to store data temporarily for a specific purpose. A master file contains records with all pertinent information about an entity. A transaction file contains the detail records representing individual transactions. Transactions records may be used to update a master file.



93

Causes of system downtime

• Software defects/failures • Planned administrative downtime

o Operating system or application upgrades o Database administration o System or Network Reconfiguration

• Operator Error • Hardware Error/Maintenance • Building or Site Disaster (Fire, explosion, etc.) • Metropolitan area or Regional Disaster (Earthquake, Flood, Tornado, Blizzard)

Modular system design approach

A module is a bounded contiguous group of statements having a single name and that can be treated as a unit. In other words, a single block in a pile of blocks.

Cohesion:

How well the activities within a single module relate to one another. Separate modules should be relatively independent (loosely coupled). This facilitates development, maintenance by teams; reduces chance of unintended ripple effects on other modules when changes made to a module.

Modularity is important because:

• It allows assignment of different programmers and analysts to separate tasks.

• Small sections can be developed independently.

• Maintenance causes minimal disruption.

Guidelines for Modularity

• Make sure modules perform a single task, have a single entry point, have a single exit point. • Isolate input-output (I-O) routines into a small number of standard modules that can be

shared system-wide. • Isolate system-dependent functions (e.g., getting date or time) in the application to ease

possible future conversions to other computer platforms or to accommodate future operating system revisions.



94

Conceptual Design

A conceptual design is an abstract or high level design which includes only the most important components and entities. The main goal of a conceptual design is to provide an understandable picture of the overall purpose of the proposed solution. Components may include major technology systems, external systems that are required for integration or overall functionality, high level data flow, and system functionality. Think of this as the "black box" diagram where portions of the diagram may be simply a technology component to-be-named-later but is identified with its role and purpose.

Logical Design

A logical design is a more detailed design which includes all major components and entities plus their relationships. The data flows and connections are detailed in this stage. The target audience is typically developers or other systems architects. However, it is possible to create logical designs for business purposes to ensure that all components and functionality is accounted and well understood. Logical designs do not include physical server names or addresses. They do include any business services, application names and details, and other relevant information for development purposes.

Physical Design

A physical design has all major components and entities identified within specific physical servers and locations or specific software services, objects, or solutions. Include all known details such as operating systems, version numbers, and even patches that are relevant. Any physical constraints or limitations should also be identified within the server components, data flows, or connections. This design usually precludes or may be included and extended by the final implementation team into an implementation design.

System implementation and testing

Implementation is the process of assuring that the new information system is operational and then allowing the users to take over its operation. Users must be trained in the use of the new system. Data must be converted from the format used in the old system to a format suitable for the new system and a strategy must be chosen for migrating users from the old system to the new system. And, once implemented the new system must be evaluated.

System testing

This is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software testing also provides an objective, independent view of the software to allow the business to appreciate and understand the risks at implementation of the software. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs. Software testing can also be stated as the process of validating and verifying that a software program/application/product:



95

• Meets the business and technical requirements that guided its design and development;

• Works as expected.

• Can be implemented with the same characteristics.

Functional vs non-functional testing

Functional testing refers to tests that verify a specific action or function of the code. These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the questions:

• Can the user do this?

• Does this particular feature work?

Non-functional testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or security. Non-functional testing tends to answer such questions as

• How many people can log in at once?

Static vs. dynamic testing

There are many approaches to software testing. Reviews, walkthroughs, or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. Static testing can be (and unfortunately in practice often is) omitted. Dynamic testing takes place when the program itself is used for the first time (which is generally considered the beginning of the testing stage). Dynamic testing may begin before the program is 100% complete in order to test particular sections of code (modules or discrete functions). Typical techniques for this are either using stubs/drivers or execution from a debugger environment. For example, spreadsheet programs are, by their very nature, tested to a large extent interactively (on the fly), with results displayed immediately after each calculation or text manipulation

Testing methods

1. The box approach

Software testing methods are traditionally divided into white- and black-box testing. These

two approaches are used to describe the point of view that a test engineer takes when

designing test cases.

• White box testing

White box testing is when the tester has access to the internal data structures and



96

algorithms including the code that implement these.

Types of white box testing

• API testing (application programming interface) - testing of the application using public and private APIs

• Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test designer can create tests to cause all statements in the program to be executed at least once)

• Fault injection methods - improving the coverage of a test by introducing faults to test code paths

• Mutation testing methods • Static testing - White box testing includes all static testing. •

2. Black box testing

Black box testing treats the software as a black box - without any knowledge of internal

implementation.

Black box testing methods

• equivalence partitioning

• boundary

• value analysis

• all-pairs testing

• fuzz testing

• model-based testing, traceability matrix,

• exploratory testing

• Specification-based testing.

Specification-based testing

Specification-based testing aims to test the functionality of software according to the applicable requirements. Thus, the tester inputs data into, and only sees the output from, the test object. This level of testing usually requires thorough test cases to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either is or is not the same as the expected value specified in the test case. Specification-based testing is necessary, but it is insufficient to guard against certain risks.

Advantages and disadvantages

The black box tester has no bonds with the code, and a tester's perception is very simple: a code must have bugs. Black box testers find bugs where programmers do not. On the other hand, black box testing has been said to be like a walk in a dark labyrinth without a flashlight, because the tester doesn't know how the software being tested was actually constructed.



97

Grey box testing

Grey box testing (gray box testing)

Involves having knowledge of internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as grey box, because the input and output are clearly outside of the "black-box" that we are calling the system under test. This distinction is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test.

Types of testing (levels of testing)

Unit testing

Unit testing is also called component testing. Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level. These types of tests are usually written by developers to ensure that the specific function is working as expected. One function might have multiple tests, to catch corner cases or other branches in the code. Unit testing alone cannot verify the functionality of a piece of software, but rather is used to assure that the building blocks the software uses work independently of each other.

Integration testing

Integration testing is any type of software testing that seeks to verify the interfaces between components against a software design. Software components may be integrated in an iterative way or all together. Integration testing works to expose defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system.

System testing

System testing tests a completely integrated system to verify that it meets its requirements.

System integration testing

System integration testing verifies that a system is integrated to any external or third party systems defined in the system requirements.

Regression testing

Regression testing focuses on finding defects after a major code change has occurred. Specifically, it seeks to uncover software regressions, or old bugs that have come back. Such regressions occur



98

whenever software functionality that was previously working correctly stops working as intended. Typically, regressions occur as an unintended consequence of program changes, when the newly developed part of the software collides with the previously existing code. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged. The depth of testing depends on the phase in the release process and the risk of the added features. They can either be complete, for changes added late in the release or deemed to be risky, to very shallow, consisting of positive tests on each feature, if the changes are early in the release or deemed to be of low risk.

Acceptance testing

Acceptance testing can mean one of two things

A smoke test is used as an acceptance test prior to introducing a new build to the main testing process, i.e. before integration or regression. Acceptance testing performed by the customer, often in their lab environment on their own hardware, is known as user acceptance testing. Acceptance testing may be performed as part of the hand-off process between any two phases of development.

Alpha testing

Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.

Beta testing

Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.

Non-functional testing

Special methods exist to test non-functional aspects of software. In contrast to functional testing, this establishes the correct operation of the software. Non-functional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing, is an example of non-functional testing. Non-functional testing, especially for software, is designed to establish whether the device under test can tolerate invalid or unexpected inputs, thereby establishing the robustness of input validation routines as well as error-handling routines. Various commercial non-functional testing tools are linked from the software fault injection



99

page; there are also numerous open-source and free software tools available that perform non-functional testing.

Software performance testing and load testing

Performance testing is executed to determine how fast a system or sub-system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage.

Load testing is primarily concerned with testing that can continue to operate under a specific load, whether that is large quantities of data or a large number of users. This is generally referred to as software scalability. The related load testing activity of when performed as a non-functional activity is often referred to as endurance testing.

Volume testing is a way to test functionality. Stress testing is a way to test reliability. Load testing is a way to test performance. There. The terms load testing, performance testing, reliability testing, and volume testing, are often used interchangeably.

Stability testing

Stability testing checks to see if the software can continuously function well in or above an acceptable period. This activity of non-functional software testing is often referred to as load testing.

Usability testing

Usability testing is needed to check if the user interface is easy to use and understand.

Security testing

Security testing is essential for software that processes confidential data to prevent system intrusion by hackers.

Internationalization and localization

Internationalization and localization is needed to test these aspects of software, for which a pseudo localization method can be used. It will verify that the application still works, even after it has been translated into a new language or adapted for a new culture.

Destructive testing

Destructive testing attempts to cause the software or a sub-system to fail, in order to test its robustness.

System changeover methods

The are five implementation strategies (changeover methods)



100

• Direct Changeover (Crash or Cold Turkey) • Parallel Conversion • Gradual or Phased Conversion • Modular Prototype • Distributed Conversion

Implementation strategies model

System changeover model or methods

The process of putting the new information system online and retiring the old system is known as system changeover. There are four changeover methods which are:

Direct cutover



101

The direct cutover approach causes the changeover from the old system to the new system to occur immediately when the new system becomes operational. It is the least expensive but involves more risks than other changeover methods.

Advantage

As we know health centre does not have enough funds for implementing the new system so it would be easier to implement direct cutover method in the health centre.

Disadvantage

This method of system changeover involves more risks of total system failure and it is preferred for commercial software packages. So if there is a system failure in health centre then it will be difficult to store information of child who visits health centre. And if there is no proper storage then there will be incorrect reports and monitoring of child’s health will not be properly done. Parallel operation The parallel operation changeover method requires that both the old and the new information systems operate fully for a specified period. Data is input to both systems and output generated by the new system is compared with the equivalent output from the old system. When users, management, and IT group are satisfied that the new system operates correctly then the old system is terminated. It is the most costly changeover method and involves lower risks.

Advantage

The advantage of parallel system is lower risk of system failure so all the tasks can be done properly at health centre. If the new system does not work properly, the health centre can use the old manual system as a backup until appropriate changes are made.

Disadvantage

As we know parallel system is the most costly changeover method as both old and new systems operate fully for specified period and we also know that the budget of health centre is also low so it will be difficult for health centre to follow this changeover process.

Pilot operation: The pilot changeover method involves implementing the complete new system at a selected location of a company. Direct cutover method and operating both systems for only the pilot site. The group that uses the new system first is called the pilot site. By restricting the implementation to a pilot site reduces the risk of system failure as compared with is less expensive than a parallel system.

Advantages

Pilot operation is combination of both direct cutover and parallel operation, which restricts the implementation to a pilot site and reduces risk of system failure as compared with a direct cutover method. Operating system only at pilot site is less expensive than parallel operation for entire health centre and all health centers.



102

If we use parallel approach to complete the implementation then the changeover period can be much shorter if system proves successful at the pilot site so a lot of time will be consumed at health centre in implementing the new system.

Disadvantage

This method is also costly as compared to the direct cutover.

Phased operation The phased operation changeover method involves implementing the new system in stages, or modules. We can implement each subsystem by using any of the other three changeover methods. In this approach risk of errors or failures is limited to the implemented module only as well as it is less expensive than the full parallel operation.

Advantages

As we know in this method we have to implement the new system in stages, or modules, which is less prone to risk of system failure or errors at health centers, as failure is limited to the implemented module only. It is also less expensive than parallel system because we have to work only with one part of system at a time.

Disadvantage

As the system, which we are implementing, involves various phased operation like treatment, measuring weight, registration, vaccination etc so it can cost more than the pilot approach.

Training of system end-users

Overview

Quality attributes are the overall factors that affect run-time behavior, system design, and user experience. They represent areas of concern that have the potential for application wide impact across layers and tiers. Some of these attributes are related to the overall system design, while others are specific to run time, design time, or user centric issues. The extent to which the application possesses a desired combination of quality attributes such as usability, performance, reliability, and security indicates the success of the design and the overall quality of the software application.

When designing applications to meet any of the quality attributes requirements, it is necessary to consider the potential impact on other requirements. You must analyze the tradeoffs between multiple quality attributes. The importance or priority of each quality attribute differs from system to system; for example, interoperability will often be less important in a single use packaged retail application than in a line of business (LOB) system.

This chapter lists and describes the quality attributes that you should consider when designing your application. To get the most out of this chapter, use the table below to gain an understanding of how quality attributes map to system and application quality factors, and read the description of each of the quality attributes. Then use the sections containing key guidelines for each of the quality attributes to understand how that attribute has an impact on your design, and to determine the decisions you must make to addresses these issues. Keep in mind that the list of quality attributes in this chapter is not



103

exhaustive, but provides a good starting point for asking appropriate questions about your architecture.

System design qualities and objectives

The following table describes the quality attributes covered in this chapter. It categorizes the attributes in four specific areas linked to design, runtime, system, and user qualities. Use this table to understand what each of the quality attributes means in terms of your application design.

Category Quality attribute

Description

Conceptual Integrity

Conceptual integrity defines the consistency and coherence of the overall design. This includes the way that components or modules are designed, as well as factors such as coding style and variable naming.

Maintainability

Maintainability is the ability of the system to undergo changes with a degree of ease. These changes could impact components, services, features, and interfaces when adding or changing the functionality, fixing errors, and meeting new business requirements.

Design Qualities

Reusability

Reusability defines the capability for components and subsystems to be suitable for use in other applications and in other scenarios. Reusability minimizes the duplication of components and also the implementation time.

Availability

Availability defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period. Availability will be affected by system errors, infrastructure problems, malicious attacks, and system load.

Interoperability

Interoperability is the ability of a system or different systems to operate successfully by communicating and exchanging information with other external systems written and run by external parties. An interoperable system makes it easier to exchange and reuse information internally as well as externally.

Manageability

Manageability defines how easy it is for system administrators to manage the application, usually through sufficient and useful instrumentation exposed for use in monitoring systems and for debugging and performance tuning.

Performance

Performance is an indication of the responsiveness of a system to execute any action within a given time interval. It can be measured in terms of latency or throughput. Latency is the time taken to respond to any event. Throughput is the number of events that take place within a given amount of time.

Reliability Reliability is the ability of a system to remain operational over time. Reliability is measured as the probability that a system will not fail to perform its intended functions over a specified time interval.

Run-time Qualities

Scalability Scalability is ability of a system to either handle increases in load



104

without impact on the performance of the system, or the ability to be readily enlarged.

Security

Security is the capability of a system to prevent malicious or accidental actions outside of the designed usage, and to prevent disclosure or loss of information. A secure system aims to protect assets and prevent unauthorized modification of information.

Supportability Supportability is the ability of the system to provide information helpful for identifying and resolving issues when it fails to work correctly.

System Qualities

Testability

Testability is a measure of how easy it is to create test criteria for the system and its components, and to execute these tests in order to determine if the criteria are met. Good testability makes it more likely that faults in a system can be isolated in a timely and effective manner.

User Qualities

Usability

Usability defines how well the application meets the requirements of the user and consumer by being intuitive, easy to localize and globalize, providing good access for disabled users, and resulting in a good overall user experience.

The following sections describe each of the quality attributes in more detail, and provide guidance on the key issues and the decisions you must make for each one:

Availability

Availability defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period. Availability will be affected by system errors, infrastructure problems, malicious attacks, and system load. The key issues for availability are:

• A physical tier such as the database server or application server can fail or become unresponsive, causing the entire system to fail. Consider how to design failover support for the tiers in the system. For example, use Network Load Balancing for Web servers to distribute the load and prevent requests being directed to a server that is down. Also, consider using a RAID mechanism to mitigate system failure in the event of a disk failure. Consider if there is a need for a geographically separate redundant site to failover to in case of natural disasters such as earthquakes or tornados.

• Denial of Service (DoS) attacks, which prevent authorized users from accessing the system, can interrupt operations if the system cannot handle massive loads in a timely manner, often due to the processing time required, or network configuration and congestion. To minimize interruption from DoS attacks, reduce the attack surface area, identify malicious behavior, use application instrumentation to expose unintended behavior, and implement comprehensive data validation. Consider using the Circuit Breaker or Bulkhead patterns to increase system resiliency.

• Inappropriate use of resources can reduce availability. For example, resources acquired too early and held for too long cause resource starvation and an inability to handle additional concurrent user requests.



105

• Bugs or faults in the application can cause a system wide failure. Design for proper exception handling in order to reduce application failures from which it is difficult to recover.

• Frequent updates, such as security patches and user application upgrades, can reduce the availability of the system. Identify how you will design for run-time upgrades.

• A network fault can cause the application to be unavailable. Consider how you will handle unreliable network connections; for example, by designing clients with occasionally-connected capabilities.

• Consider the trust boundaries within your application and ensure that subsystems employ some form of access control or firewall, as well as extensive data validation, to increase resiliency and availability.

Conceptual Integrity

Conceptual integrity defines the consistency and coherence of the overall design. This includes the way that components or modules are designed, as well as factors such as coding style and variable naming. A coherent system is easier to maintain because you will know what is consistent with the overall design. Conversely, a system without conceptual integrity will constantly be affected by changing interfaces, frequently deprecating modules, and lack of consistency in how tasks are performed. The key issues for conceptual integrity are:

• Mixing different areas of concern within your design. Consider identifying areas of concern and grouping them into logical presentation, business, data, and service layers as appropriate.

• Inconsistent or poorly managed development processes. Consider performing an Application Lifecycle Management (ALM) assessment, and make use of tried and tested development tools and methodologies.

• Lack of collaboration and communication between different groups involved in the application lifecycle. Consider establishing a development process integrated with tools to facilitate process workflow, communication, and collaboration.

• Lack of design and coding standards. Consider establishing published guidelines for design and coding standards, and incorporating code reviews into your development process to ensure guidelines are followed.

• Existing (legacy) system demands can prevent both refactoring and progression toward a new platform or paradigm. Consider how you can create a migration path away from legacy technologies, and how to isolate applications from external dependencies. For example, implement the Gateway design pattern for integration with legacy systems.

Interoperability

Interoperability is the ability of a system or different systems to operate successfully by communicating and exchanging information with other external systems written and run by external parties. An interoperable system makes it easier to exchange and reuse information internally as well as externally. Communication protocols, interfaces, and data formats are the key considerations for interoperability. Standardization is also an important aspect to be considered when designing an interoperable system. The key issues for interoperability are:

• Interaction with external or legacy systems that use different data formats. Consider how you can enable systems to interoperate, while evolving separately or even being replaced. For example, use orchestration with adaptors to connect with external or legacy systems and



106

translate data between systems; or use a canonical data model to handle interaction with a large number of different data formats.

• Boundary blurring, which allows artifacts from one system to defuse into another. Consider how you can isolate systems by using service interfaces and/or mapping layers. For example, expose services using interfaces based on XML or standard types in order to support interoperability with other systems. Design components to be cohesive and have low coupling in order to maximize flexibility and facilitate replacement and reusability.

• Lack of adherence to standards. Be aware of the formal and de facto standards for the domain you are working within, and consider using one of them rather than creating something new and proprietary.

Maintainability

Maintainability is the ability of the system to undergo changes with a degree of ease. These changes could impact components, services, features, and interfaces when adding or changing the application’s functionality in order to fix errors, or to meet new business requirements. Maintainability can also affect the time it takes to restore the system to its operational status following a failure or removal from operation for an upgrade. Improving system maintainability can increase availability and reduce the effects of run-time defects. An application’s maintainability is often a function of its overall quality attributes but there a number of key issues that can directly affect maintainability:

• Excessive dependencies between components and layers, and inappropriate coupling to concrete classes, prevents easy replacement, updates, and changes; and can cause changes to concrete classes to ripple through the entire system. Consider designing systems as well-defined layers, or areas of concern, that clearly delineate the system’s UI, business processes, and data access functionality. Consider implementing cross-layer dependencies by using abstractions (such as abstract classes or interfaces) rather than concrete classes, and minimize dependencies between components and layers.

• The use of direct communication prevents changes to the physical deployment of components and layers. Choose an appropriate communication model, format, and protocol. Consider designing a pluggable architecture that allows easy upgrades and maintenance, and improves testing opportunities, by designing interfaces that allow the use of plug-in modules or adapters to maximize flexibility and extensibility.

• Reliance on custom implementations of features such as authentication and authorization prevents reuse and hampers maintenance. To avoid this, use the built-in platform functions and features wherever possible.

• The logic code of components and segments is not cohesive, which makes them difficult to maintain and replace, and causes unnecessary dependencies on other components. Design components to be cohesive and have low coupling in order to maximize flexibility and facilitate replacement and reusability.

• The code base is large, unmanageable, fragile, or over complex; and refactoring is burdensome due to regression requirements. Consider designing systems as well defined layers, or areas of concern, that clearly delineate the system’s UI, business processes, and data access functionality. Consider how you will manage changes to business processes and dynamic business rules, perhaps by using a business workflow engine if the business process tends to change. Consider using business components to implement the rules if only the business rule values tend to change; or an external source such as a business rules engine if the business decision rules do tend to change.



107

• The existing code does not have an automated regression test suite. Invest in test automation as you build the system. This will pay off as a validation of the system’s functionality, and as documentation on what the various parts of the system do and how they work together.

• Lack of documentation may hinder usage, management, and future upgrades. Ensure that you provide documentation that, at minimum, explains the overall structure of the application.

Manageability

Manageability defines how easy it is for system administrators to manage the application, usually through sufficient and useful instrumentation exposed for use in monitoring systems and for debugging and performance tuning. Design your application to be easy to manage, by exposing sufficient and useful instrumentation for use in monitoring systems and for debugging and performance tuning. The key issues for manageability are:

• Lack of health monitoring, tracing, and diagnostic information. Consider creating a health model that defines the significant state changes that can affect application performance, and use this model to specify management instrumentation requirements. Implement instrumentation, such as events and performance counters, that detects state changes, and expose these changes through standard systems such as Event Logs, Trace files, or Windows Management Instrumentation (WMI). Capture and report sufficient information about errors and state changes in order to enable accurate monitoring, debugging, and management. Also, consider creating management packs that administrators can use in their monitoring environments to manage the application.

• Lack of runtime configurability. Consider how you can enable the system behavior to change based on operational environment requirements, such as infrastructure or deployment changes.

• Lack of troubleshooting tools. Consider including code to create a snapshot of the system’s state to use for troubleshooting, and including custom instrumentation that can be enabled to provide detailed operational and functional reports. Consider logging and auditing information that may be useful for maintenance and debugging, such as request details or module outputs and calls to other systems and services.

Performance

Performance is an indication of the responsiveness of a system to execute specific actions in a given time interval. It can be measured in terms of latency or throughput. Latency is the time taken to respond to any event. Throughput is the number of events that take place in a given amount of time. An application’s performance can directly affect its scalability, and lack of scalability can affect performance. Improving an application’s performance often improves its scalability by reducing the likelihood of contention for shared resources. Factors affecting system performance include the demand for a specific action and the system’s response to the demand. The key issues for performance are:

• Increased client response time, reduced throughput, and server resource over utilization. Ensure that you structure the application in an appropriate way and deploy it onto a system or systems that provide sufficient resources. When communication must cross process or tier boundaries, consider using coarse-grained interfaces that require the minimum number of calls



108

(preferably just one) to execute a specific task, and consider using asynchronous communication.

• Increased memory consumption, resulting in reduced performance, excessive cache misses (the inability to find the required data in the cache), and increased data store access. Ensure that you design an efficient and appropriate caching strategy.

• Increased database server processing, resulting in reduced throughput. Ensure that you choose effective types of transactions, locks, threading, and queuing approaches. Use efficient queries to minimize performance impact, and avoid fetching all of the data when only a portion is displayed. Failure to design for efficient database processing may incur unnecessary load on the database server, failure to meet performance objectives, and costs in excess of budget allocations.

• Increased network bandwidth consumption, resulting in delayed response times and increased load for client and server systems. Design high performance communication between tiers using the appropriate remote communication mechanism. Try to reduce the number of transitions across boundaries, and minimize the amount of data sent over the network. Batch work to reduce calls over the network.

Reliability

Reliability is the ability of a system to continue operating in the expected way over time. Reliability is measured as the probability that a system will not fail and that it will perform its intended function for a specified time interval. The key issues for reliability are:

• The system crashes or becomes unresponsive. Identify ways to detect failures and automatically initiate a failover, or redirect load to a spare or backup system. Also, consider implementing code that uses alternative systems when it detects a specific number of failed requests to an existing system.

• Output is inconsistent. Implement instrumentation, such as events and performance counters, that detects poor performance or failures of requests sent to external systems, and expose information through standard systems such as Event Logs, Trace files, or WMI. Log performance and auditing information about calls made to other systems and services.

• The system fails due to unavailability of other externalities such as systems, networks, and databases. Identify ways to handle unreliable external systems, failed communications, and failed transactions. Consider how you can take the system offline but still queue pending requests. Implement store and forward or cached message-based communication systems that allow requests to be stored when the target system is unavailable, and replayed when it is online. Consider using Windows Message Queuing or BizTalk Server to provide a reliable once-only delivery mechanism for asynchronous requests.

Reusability

Reusability is the probability that a component will be used in other components or scenarios to add new functionality with little or no change. Reusability minimizes the duplication of components and the implementation time. Identifying the common attributes between various components is the first step in building small reusable components for use in a larger system. The key issues for reusability are:



109

• The use of different code or components to achieve the same result in different places; for example, duplication of similar logic in multiple components, and duplication of similar logic in multiple layers or subsystems. Examine the application design to identify common functionality, and implement this functionality in separate components that you can reuse. Examine the application design to identify crosscutting concerns such as validation, logging, and authentication, and implement these functions as separate components.

• The use of multiple similar methods to implement tasks that have only slight variation. Instead, use parameters to vary the behavior of a single method.

• Using several systems to implement the same feature or function instead of sharing or reusing functionality in another system, across multiple systems, or across different subsystems within an application. Consider exposing functionality from components, layers, and subsystems through service interfaces that other layers and systems can use. Use platform agnostic data types and structures that can be accessed and understood on different platforms.

Scalability

Scalability is ability of a system to either handle increases in load without impact on the performance of the system, or the ability to be readily enlarged. There are two methods for improving scalability: scaling vertically (scale up), and scaling horizontally (scale out). To scale vertically, you add more resources such as CPU, memory, and disk to a single system. To scale horizontally, you add more machines to a farm that runs the application and shares the load. The key issues for scalability are:

• Applications cannot handle increasing load. Consider how you can design layers and tiers for scalability, and how this affects the capability to scale up or scale out the application and the database when required. You may decide to locate logical layers on the same physical tier to reduce the number of servers required while maximizing load sharing and failover capabilities. Consider partitioning data across more than one database server to maximize scale-up opportunities and allow flexible location of data subsets. Avoid stateful components and subsystems where possible to reduce server affinity.

• Users incur delays in response and longer completion times. Consider how you will handle spikes in traffic and load. Consider implementing code that uses additional or alternative systems when it detects a predefined service load or a number of pending requests to an existing system.

• The system cannot queue excess work and process it during periods of reduced load. Implement store-and-forward or cached message-based communication systems that allow requests to be stored when the target system is unavailable, and replayed when it is online.

Security

Security is the capability of a system to reduce the chance of malicious or accidental actions outside of the designed usage affecting the system, and prevent disclosure or loss of information. Improving security can also increase the reliability of the system by reducing the chances of an attack succeeding and impairing system operation. Securing a system should protect assets and prevent unauthorized access to or modification of information. The factors affecting system security are confidentiality, integrity, and availability. The features used to secure systems are authentication, encryption, auditing, and logging. The key issues for security are:



110

• Spoofing of user identity. Use authentication and authorization to prevent spoofing of user identity. Identify trust boundaries, and authenticate and authorize users crossing a trust boundary.

• Damage caused by malicious input such as SQL injection and cross-site scripting. Protect against such damage by ensuring that you validate all input for length, range, format, and type using the constrain, reject, and sanitize principles. Encode all output you display to users.

• Data tampering. Partition the site into anonymous, identified, and authenticated users and use application instrumentation to log and expose behavior that can be monitored. Also use secured transport channels, and encrypt and sign sensitive data sent across the network

• Repudiation of user actions. Use instrumentation to audit and log all user interaction for application critical operations.

• Information disclosure and loss of sensitive data. Design all aspects of the application to prevent access to or exposure of sensitive system and application information.

• Interruption of service due to Denial of service (DoS) attacks. Consider reducing session timeouts and implementing code or hardware to detect and mitigate such attacks.

Supportability

Supportability is the ability of the system to provide information helpful for identifying and resolving issues when it fails to work correctly. The key issues for supportability are:

• Lack of diagnostic information. Identify how you will monitor system activity and performance. Consider a system monitoring application, such as Microsoft System Center.

• Lack of troubleshooting tools. Consider including code to create a snapshot of the system’s state to use for troubleshooting, and including custom instrumentation that can be enabled to provide detailed operational and functional reports. Consider logging and auditing information that may be useful for maintenance and debugging, such as request details or module outputs and calls to other systems and services.

• Lack of tracing ability. Use common components to provide tracing support in code, perhaps though Aspect Oriented Programming (AOP) techniques or dependency injection. Enable tracing in Web applications in order to troubleshoot errors.

• Lack of health monitoring. Consider creating a health model that defines the significant state changes that can affect application performance, and use this model to specify management instrumentation requirements. Implement instrumentation, such as events and performance counters, that detects state changes, and expose these changes through standard systems such as Event Logs, Trace files, or Windows Management Instrumentation (WMI). Capture and report sufficient information about errors and state changes in order to enable accurate monitoring, debugging, and management. Also, consider creating management packs that administrators can use in their monitoring environments to manage the application.

Testability

Testability is a measure of how well system or components allow you to create test criteria and execute tests to determine if the criteria are met. Testability allows faults in a system to be isolated in a timely and effective manner. The key issues for testability are:

• Complex applications with many processing permutations are not tested consistently, perhaps because automated or granular testing cannot be performed if the application has a monolithic



111

design. Design systems to be modular to support testing. Provide instrumentation or implement probes for testing, mechanisms to debug output, and ways to specify inputs easily. Design components that have high cohesion and low coupling to allow testability of components in isolation from the rest of the system.

• Lack of test planning. Start testing early during the development life cycle. Use mock objects during testing, and construct simple, structured test solutions.

• Poor test coverage, for both manual and automated tests. Consider how you can automate user interaction tests, and how you can maximize test and code coverage.

• Input and output inconsistencies; for the same input, the output is not the same and the output does not fully cover the output domain even when all known variations of input are provided. Consider how to make it easy to specify and understand system inputs and outputs to facilitate the construction of test cases.

User Experience / Usability

The application interfaces must be designed with the user and consumer in mind so that they are intuitive to use, can be localized and globalized, provide access for disabled users, and provide a good overall user experience. The key issues for user experience and usability are:

• Too much interaction (an excessive number of clicks) required for a task. Ensure you design the screen and input flows and user interaction patterns to maximize ease of use.

• Incorrect flow of steps in multistep interfaces. Consider incorporating workflows where appropriate to simplify multistep operations.

• Data elements and controls are poorly grouped. Choose appropriate control types (such as option groups and check boxes) and lay out controls and content using the accepted UI design patterns.

• Feedback to the user is poor, especially for errors and exceptions, and the application is unresponsive. Consider implementing technologies and techniques that provide maximum user interactivity, such as Asynchronous JavaScript and XML (AJAX) in Web pages and client-side input validation. Use asynchronous techniques for background tasks, and tasks such as populating controls or performing long-running tasks.

Documentation Documentation may refer to the process of providing evidence (to document something) or to the communicable material used to provide such documentation (i.e. a document). Documentation may also (seldom) refer to tools aiming at identifying documents or to the field of study devoted to the study of documents and bibliographies. Software documentation



112

Software documentation or source code documentation is written text that accompanies computer software. It either explains how it operates or how to use it, or may mean different things to people in different roles.

Types of Documentation

When it comes to technical writing; software documentation is an important one and always in demand. Documentation is an important part of software engineering. Types of documentation include:

• Requirements -- Statements that identify attributes, capabilities, characteristics, or qualities of a system. This is the foundation for what shall be or has been implemented

• Architecture/Design -- Includes relations to an environment and construction principles to be used in design of software components

• Technical -- Documentation of code, algorithms, interfaces, and APIs • End User -- Manuals for the end-user, system administrators and support staff • Marketing -- How to market the product and analysis of the market demand

Requirement Specification

This document portrays and describes what the customer has asked for in a form of technical document to actually define what the product will do.

Functional Specification

It is the document giving a good volume of information about the functioning of the product. This document is for the customer before any development starts.

Design Specification

This document is written after the client has approved the Functional Specification. It gives images and the look and feel, the color scheme, fonts etc about the product in form of document.

User Manual/Guide

It is a printed guide that contains introduction of the product or software, how to use it, context about the interface, what the controls mean etc.

Hardware Manual

It is a guide for how the working of a physical existing product can be handled. Giving a procedural guide with images to make the user understand the hardware.



113

Software Manual

This guide is for giving the instructions to the user about installing a software, how to initialize it, how to use it, what steps to take out a required result and defined terms of the product.

Installation Manual

An installation manual is one, which gives quick installation information about either the hardware or software. These sometimes include Quick Start guides. Quick Start guides are the ones inserted in the CD cases or packed with the product composed of 1 or sometimes 10-14 pages.

Online Help

The online helps are the online guides and electronic form of the user guides.

Online Support: Online support is for helping a user through a problem, may it be trouble shooting, looking for a solution or any other difficulty

Application Helps

These helps are suitable for the desktop applications, or intranet applications. They are Win help and HTML help. Win help is rarely used, whereas HTML help is similar to the help opening in MS office.

Application Notes

These are the direct reference notes that give exact information about using a product. The customer organizations and companies usually use these documents.

Data Sheets

These documents are used as advertising media in the consumer market. It has a language, which gives information about the product-to-be launched. It imparts details on the characterization of the product thus explaining what benefits customers will get if they purchase it.

system analysis tutorial

Documents

entities share

entity relationship

mail order

context diagram

cardinality

logical structure

context dfd

store information