system analysis and design-purbanchal university notes for bit/bca

7/28/2019 System analysis and design-purbanchal university notes for BIT/BCA

1/39

System Analysis and Design

Systems are created to solve problems. One can think of the systems approach as an organized

way of dealing with a problem. In this dynamic world, the subject System Analysis and Design

mainly deals with the software development activities.

Chapter 1

System Environment:

System: 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.

For example, Human body represents a complete natural system. We are also bound by manynational systems such as political system, economic system, educational system and so forth. The

objective of the system demands that some output is produced as a result of processing the

suitable inputs.

A system is simply a set of components that interact with each other to accomplish some purposeor a particular goal. i.e. physical sensation is a complex nervous system; it is a set of brain, spinal

cord, nerves and special sensitive cells under your skin, that work together to make you fill hot,

cod and so on. System of words and symbols, economic system etc. A business is also a system.Its components are marketing, manufacturing, sales, research, shipping, accounting and

personnel all work together to create a profit that benefits the employees and stock holders of

the firm. Each of these components is itself a system and it is called subsystem. i.e. the

accounting department may consist of accounts payable, account receivable, billing, auditing andso on.

Environment: Are the entity outside the boundaries of the system.

To achieve their purpose, system interacts with their environment. The systems that interact with

their environment (receive input & produce output) are called open system.

The systems that do not interact with their surroundings are called closed systems. In real life all

systems are open system. Thus closed systems exist only as a concept.

Any system use a basic control model consists of


2/39

- A standard for acceptable performance.

- A method of measuring actual performance.

- A means of comparing actual performance against the standard.- A method of feedback.

Systems that can adjust their activities to acceptable levels continue to function. Thosecan not eventually stop.

System boundary

System component

Input Output

Actual Standard

Means of comparison

Feedback of result of comparison

For example, if a business, produces as output products or services that are at high pricedand of low quality people will probably be not continue to buy them. Low sales figures

are feedback, telling managements, it needs to adjust the products and the way they are

produced to improve performance and bring it into the line with expectation.

Information System

Every business system depends on a more or less abstract entity called an information

system. This system is the means by which data flow from one person/department to

another. Information system helps all the system of business, linking the different

component in such a way that they effectively work towards the same purpose.

The purpose of information systems are to process input, maintain data and produces

information, reports and other output.

It consists of subsystems including hardware, software, and data storage for files and

database. The particular ser of subsystems used the specific equipment, programs, files

and procedures constitutes information systems applications.

Categories of information systems:

Information system can be categories as follow

(i) Transaction processing system (TPS): The aim of this system is to improve the

routine business activity on which organization depends. A transactions any event

or activity that affects the organization. i.e. placing orders, billing customers,hiring employees, deposit checks. Transaction processing involves :

- Calculation


3/39

- Classification

- Sorting

- Storing & retrieval- Summarization

Characteristics of transactions

- There is a high volume of transactions

- Each transaction is similar.

- The procedures for processing the transaction are well defined and can be

described in detail.- Few exceptions to the normal procedures occur.

Using these characteristics the routines will be established, which describes theprocess and what to do if exception occurs. Some time it is called standard

operating procedures.

TPS provides speed and accuracy and can be programmed to follow routines

without any variance.

(ii) Management Information system (MIS): TPS are operation oriented. In contras

MIS assist managers in decision making and problem solving. They work on thedata stored as a result of transaction processing, but they may also use other

information.

In any organization, decision must be made on many issues that recur regularly

and require certain ser of information to make the decision. Because the decision

process is well understood, one can identify the information that will be needed toformulate decisions. The information system can be developed so that reports are

prepared reg7ularly to support this recurring decisions. Each time information is

needed, it is prepared in a pre designed form presented in a predetermined format.

The decision supported by these system are structured decisions. It means

manager knows what factors to consider in making the decision and which

variables most significantly influence whether the decisions will be good or bad.System analyst in turn develop well structured reports containing information that

is needed for the decisions or that tells the status of important variables.

In the banking example, the information reported is often combined with other

external information, such as details about economic trends, demand for loans,

rate of consumer spending, and cost of borrowing. Bank officers can makeinformed decision about the level of interest. The need to make each of these

decisions frequently, and the information needed to formulate the decisions is also

prepared regularly.

(iii) Decision support system (DSS): All decisions are of not a recurring nature.

Some occurs only once or recur infrequently. DSS assists managers who must


4/39

make decisions that are not highly structured, often called unstructured or semi-

structured decisions. A decision is consider unstructured if there are no clear

procedures for making the decision.

A key factor in the use of decision support system is determining what

information is needed. I well structured situation it is possible to identifyinformation needs in advance, but in unstructured environment, it is difficult to do

so. As information is acquired the manager may realize that additional

information is required.

Consider the banking example, where manager must decide whether to begin cash

management accounts or install an automatic teller machine. Both are the new

services, management has to think about so many different questions such as

- What will each service cost?

- How many teller locations are needed?

- How will the competition respond to this?- What limits should be placed on with drawls at any one time?

- Can a charge be imposed for this service?

In such cases, it is impossible to pre design system report formats and contents.

Thus a decision support system must have greater flexibility than otherinformation system. The data needed to develop the information may originate

from many different files or database, rather than form a single master file.

Manger judgment plays a vital role in decision making where the problem is notstructured. The decision support system supports, but does not replace,

management judgment.

System analysis and design

It refers to the process of examining a business situation with the intent of improving it

through better procedures and methods.

System development process can be thought of having two major components (i) System

analysis and (ii) System design

System analysis: It is the process of gathering and interpreting facts, diagnosing

problems and using the information to recommend improvements to the system.

System design: It is the process of planning a new business system or one to replace or

complement an existing system. The system design is like the blue print for a building, it

specified all the features that are to be in the finished products.

Analysis specifies what the system should do. Design states how to accomplish the

objectives.

Methods and Tools:


5/39

An engineering approach to building systems requires certain methods and tools to be

used to ensure that systems are built in the most effective way.

System Development Methodology: A predefined set of steps, together with a collectionof tools used to design a system. It too provides a variety of supporting methods and

tools.

Modeling methods: A method used to construct a model of a system. This methodproduce models which help us to understand the system and its requirements and then to

develop system specifications. These methods are primarily used in the analysis.

Productivity tools: software systems that assist analysts and designers to buildcomputer-based information systems.

Functions of System Analyst

A system analysts primary responsibility is to identify information needs of an

organization and obtain a logical design of an information system which will meet these

needs.

Three groups of people are involved in developing information systems for organizationmanagers, users of the systems and computer programmers. The efforts of the system

analyst is to co-ordinates all these group, to effectively develop and operate computer

based information system, some important function of system analyst can be expressed asfollow

(i) Defining requirement

(ii) Categorized the requirements and determines the priority.(iii) Gathering data, facts and opinions of facts.

(iv) Analysis and evaluation

(v) Solving up specifications(vi) Designing system

(vii) Evaluating system

Users and User Types

The term end user is widely used by system analysts to refer t people who are not

professional information system specialist but who use computers to perform their job.

The end users can be categorized into following four categories

(i) Hands on user: This user actually interacts with the system. They feed in data or

receive outputs. I.e. airline reservation agents, use terminals to query the systemabout passenger, flight and ticket information.

(ii) Indirect users: This is the users who do not interact with the hardware orsoftware, but they take the benefit from the results or reports produced by these

system. These types of users are not alike. Some may have never used a

computer, others are intermittent users, and others may interact daily with an

information system. The some of the users may be a competitor, not an employeeof the firm.


6/39

(iii) User manager: Such type users have management responsibility for application

software. These users may be upper level managers. These users may not actuallyuse the system directly or indirectly, they retain authority to approve or

disapprove investment in the development of applications and have organizational

responsibility for the effectiveness of the system.

(iv) Senior management: They take the increased responsibility for the development

of information systems.

All four types of users are important. Each has essential information about how the

organization functions and where it is going.

Chapter 2

System Coordination

The Changing OrganizationThere are two ways of viewing the organization. One is as traditional hierarchical structure andthe other is the flatter structure with people working in task- oriented teams. Most organizations

are usually a mix of the two with a trend toward the flatter structures. This trend places more

emphasis on teamwork, with people working in task teams towards well-defined objectives.People in teams may include those employed by the organization and those outside the

organization.

A hierarchical view

This view sees the organization in the three levels as in the following figure.

Strategic

Management

Operational

Set Goals

Carry out tasks

Arrange Resources

Fig: Organizational Levels


7/39

Strategic LevelThis level is involved in the identification of the strategic objectives for the operational level.

They make the decision on the board objective of an organization. They may make adecision on the particular kind of products, marketing strategy, funds to be invested etc.

Management LevelThe people at the management level determine the tasks needed to be carried out at the

next level and delegate these tasks to lower levels. In this level, focus must be given to theacquisition of the resources and arrange the resources to meet the goals. Hiring staff,

making the promotions arrangements and even arranging the production if necessary.

Operational LevelThe detailed tasks set by the aforesaid level are carried out by the people at the operationallevel. Preparing vouchers, distributing products and sending out invoices of the products are

the tasks performed in this level.

Note: the communication and coordination between people at the operational levels isthrough the management level. Hence the resources available and used must be informed

to the people at the management level before being forwarded to thestrategic level

Flatter Structures

This is more adaptive and effective structure to bring people from different parts of theorganization together and to arrange their activities as customer needs change. Suchrearrangement is often difficult if it is to proceed through a number of hierarchical

organizational levels, each with its own priorities. As a result, there has been a tendency toreduce the number of levels and to encourage change by supporting coordination at the

operational levels.This structure in concerned with the formation of the workgroups to accomplish some

specific and often limited tasks.Those workgroups are empowered to make decision the user of resources without

references to management.

Types of GroupsGroups can be categorized into many ways:

- Open Groups: This group allows members to be freely added or deleted fromthe group. The open group may be loosely coupled (allows the group members to

act independently of each other) or tightly coupled (group imposes therestrictions on interactions).

- Closed Groups: The group does not allow members to be added or deleted

freely.

Information ExchangeThis is the most fundamental support tools for people to interchange message and data.Information exchange occurs through interaction in the organization. Interaction may be

through:

- Telephone Calls

- Meeting in corridors

- Messages scratched on piece of papers etc.The benefit of information exchange is that it allows people to develop a perception of what

is going on and what possible problems can influence their decisions.

Supporting information exchange:The development of computer system and networks have greatly changed the mode ofinformation exchange. The simplest support for message exchange is electronic mail, or e-

mail, where users simply send messages to each other.The e-mail system is supported in turn by the computer networks which can be local to an

organization or they can be interorganizational networks as Internet.


8/39

Eachuser on internet has their own unique electronic address, and all messages with thataddress are directed to the user. The real danger with the email is that the people may

suddenly find themselves flooded with messages, in much the same may as letterboxes areoften flooded with advertising brochures.

The internet too includes following information to be exchanged beside electronic mails:

- Attaching files to messages

- Broadcasting a message to a whole group or collecting information from a group- Setting up bulletin boards and news services and

- Setting up file libraries

Internet connects millions of people to its services as well as storing a myriad ofinformation either as files on FTP (File Transfer Protocol) sites or as part of the World Wide

Web (WWW).Internet gives the ability to send e-mails,connect to different news group on specialist

topics, access the resources via search engines etc.

Intranet on the other hand supports communication across the whole organization. It uses

the same technology as the internet but the access is restricted to the people within the

organization.

Bulletin Board: A space that stores messages accessible to all members by a cooperating

group instead of sending those to the individuals mail. The members of the board may lookup their bulletin board at their convenience.

Supporting personal RelationshipsSupport for personal relationships provides people with the services needed to communicate

effectively and to maintain productive and satisfying relationships.

WorkThe task which has to be performed to accomplish some goals is called work. There aredifferent types of works:

a. Planned Work: The work where the sequence of tasks can be predefined. Theprocess is predefined as a sequence of steps, and each step is usually carried out by

one person. The planned work starts with the request for a part. The request is

approved, purchases and arranged and a delivery is made. The following diagramshows the planned work flow:

b. Situated Work: the work is often unstructured. It often requires closer coordinationthan structured or preplanned work in a number of ways. First, the situation tends to

change more rapidly, requiring team members to quickly adapt to the change and tocoordinate their activities at a much more detailed level. Second, this closer

Initiaterequest

Approverequest

ArrangePurchase

Accept

Delivery

Step 1 Step 2Step 3 Step 4

Order FileRequestFile


9/39

coordination requires more face-to-face interaction. Planned work on the other handcan be carried out with less face-to-face interaction.

Chapter 3

Concept FormationProblem

Problem is the situation which needed to be handled by developing a system which more or less

addresses the issues concerning to it. Problems can be identified in many different ways which

might be formal of informal. We can hear people saying about the problem, compare wiat ishappening now to what we think should be happeining etc.

We can compare our operations against some accepted benchmark (standard) or by looking at

what other competitors are doing.The external factors might also include changes in government policy, client preferences or

simply new ideas that are reported in the literature.Finding Problems Using External Considerations

Some of the ways of finding problems externally are: Using normative models, which describe an accepted or conventional way of doing

something.

Using historic models of the ways in which organization develop. This is particularlyuseful in information systems design because of the development of technology.

Comparing our activities against a competitors activities and

Analyzing changes to government policy and community attitudes.Finding Problems Using Internal considerations

Organization sets a goal within the practical bounds. This is done by breaking down the projectgoal into more details subgoals that considers organizations constraints. These subgoals are

latter used to guide the detailed analysis and design. One way to set goals is to identify

deficiencies in the existing system. The project goal will then be used to remove suchdeficiencies. Deficiencies are often found in the course of interviews or by examining documents

about system performance. The following internal considerations are checked to find problems:

Missing functions

Unsatisfactory performance

Excessively costly operationsSolution

The remedy to the problem is solution. Solutions should not be unrealizable that aresubsequently ignored. They must be developed within the practical bounds of the organization.After the problem is found we need to come up with an idea to identify conceptual solutionsand justify these solution in turn. Feasibility analysis determines whether the alternatives

provided as solution to the problem is effective and the best.Feasibility studies also provides multiple alternatives for the same problem from which the

most effective solution is considered. It is advisable to investigate as many alternatives aspossible to ensure that the best solution is chosen. Certain amount of skill is needed to

propose good alternatives and choose the right direction.

Feasibility AnalysisFeasibility analysis commences once the project goal is set. The first feasibility analysis stepproposes a set of solutions that can realize the project goal. These solutions are usually


10/39

descriptions of what the new system should look like. The next step evaluates the feasibilityof such solutions. Such evaluation often indicates shortcomings in the initial goals.

There are three major types of feasibilities carried out for a system studies:

Technical Feasibility: It is an evaluation to determine whether a system ca betechically built. We need to check if the organization have the technology and skills

necessary to carry out the project and if not, how should the required technology

and skills be obtained? The technical feasibility must also assess whether the existingsystems can be upgraded to use the new technology and whether the organization

has the expertise to use it.

Operational Feasibility: It is an evaluation to determine whether a system is

operationally acceptable. It covers two aspects. One is a technical performanceaspect and the other is acceptance within the organization.Technical performance

includes issues such as determining whether the system can provide the rightinformation for the organizations personnel, and whether the system can be

organized so that it always delivers this information at the right place and on time.Operational feasibility must determine how the proposed system will fit in with the

current operations and what must determine how the proposed system will fit in withthe current operations and what, if any, job restructuring and restructuring and

retraining may be needed to implement the system. The evaluation must thendetermine the general attitudes and skills of the existing personnel and whether any

such restructuring of jobs will be acceptable to the current users.

Economic Feasibility: It is an evaluation to determine whether a system iseconomically acceptable. This evaluation looks at the financial aspects of the project.

It determines whether the investment needed to implement the system will berecoverred.

Economic feasibilityEconomic feasibility concerns returns from investments in a project. It determines whether

it is worthwhile to invest the money in the proposed project or whether something elseshould be done with it. Some organizations especially those with large projects, place great

emphasis on economic analysis. It is not worthwhile spending a lot of money on a projectfor no returns, especially if there are may other things which could be done with that

money.To carry out an economic feasibility study, it is necessary to place actual money values

against any purchase or activities needed to implement the project. The calculations whichdescribes the economic aspects of the project is discuss under cost benefit analysis.

Cost-benefit AnalysisThis analysis usually includes two steps:

- Producing the estimates of costs and benefits: The goal is to produce a list of what isrequired to implement the system and a list of the new systems benefits.Cost-benefit analysis is always clouded by both tangible and intangible items.

Tangible items are those to which direct values can be attached (e.g. thepurchase of equipment, time spent by people writing programs, or items such as

insurance cost or the cost of borrowing money). Some of the tangible costincludes:

o Equipment cost for the new system

o Personnel costs

o Material costs

o Conversion costs

o Training costs

o Other costs


11/39

Intangible items, on the other hand, are those whose values cannot be preciselydetermined and are the result of subjective judgment. For instance, how much is

saved by completing a project earlier or providing new information to decisionmakers?

The sum value of cost of items needed to implement the system is known as the

costof the system. The sum value of the savings made is known as the benefitof

the new system. Whether the project is economically viable is determined by theagreement on the cost and benefits of the project.

- Determining whether the project is worthwhile once these costs are ascertained: Thecosts and benefits are used to determine whether a project is economicallyfeasible. There are two ways to do this:

o The Payback Method:The payback method defines the time required to

recover the money spent on a project. The project starting cost is

estimated and the cost benefits for each succeeding year is evaluated. Thedifference between the cost and the benefit for each year will be the

saving or the net benefit for the year. And the total number of yearsneeded to recover the costs is determined. Suppose a project costing

$100,000 is implemented in year0. The benefits for each successive yearsare as follows

Year 1 $20,000

Year 2 $40,000

Year 3 $60,000

Year 4 $30,000

Year 5 $10,000

The list of benefit above shows that the total cost of the project isrecovered in near about year 3. Hence, the payback period is 2.9

(Approx).o Present Value Method: There are some drawbacks in the payback method

in determining the economic feasibility. It does not seem to make much

sense to put, say, $10,000 into a project and recover $12,000 in Year 5.

We will better put the $10,000 into an investment account at 10% interest

and get $16,105 in that time. The idea of present value method is todetermine how much money it is worthwhile investing now in order toreceive a given return in some years time. The present value depends on

the interest rate. Thus the present value of $16,105 in Year 5 is $10,000today at 10% rate of interest. If the project pays back $16,105 in year 5

cost $11,000 today, the project is not worthwhile. On the other hand, it isworthwhile if it only costs $9,000 today.

The formula to calculate present balue of the benefit at each year is:Present Value x (1+1/100)n=Benefit at Year n

Thus, the present value of the $40,000 benefit at year 2 is computet asPresent value=40,000/ (1+10/100)2

=33,057The cumulative sum of the present value for each year is calculated and

compared to the initial investment. If the sum of the present value isgreater than the initial investment, the project is worthwhile.


12/39

What Is a Good Meeting?

A meeting is a gathering of people to present or exchange information, plan joint activities, make

decisions, or carry out actions already agreed upon. Almost every group activity or projectrequires a meeting, or meetings, of some sort.

Knowing how to hold efficient and effective meetings can help make projects successful. In a

good meeting, participants' ideas are heard, decisions are made through group discussion and

with reasonable speed, and activities are focused on desired results. Good meetings help generateenthusiasm for a project, build skills for future projects, and provide participants with techniques

that may benefit them in their future careers.

Good meetings require good leaders and good participants. A good leader understands thepurpose of a meeting, makes sure that all participants understand this purpose, helps keep the

discussion on track, works with participants to carry out the business of the meeting in the time

allotted, and tries to ensure that everyone is involved appropriately in discussions. These

responsibilities often require a leader to distribute an agenda and other written materials prior toa meeting.

Good participants come to a meeting prepared for the business at handwith reports ready,concerns over key issues thought out, and questions about key issues organized. They also bring

to the table their best listening skills and group manners. These participants, for example, taketurns talking, stay on the point of discussion, and help to move decisions forward.

Characteristics of a good meeting

A successful meeting has four characteristics:

1. The meeting must have a clear purpose and should stick to the agenda

2. The meeting must start and end on time

3. Participants must be properly prepared

4. Minutes must be taken

5. Quorum (minimum number of the persons to run meeting) of meeting should be

maintained.


13/39

What Does It Take To Plan and Run a Productive Meeting?

Any successful meeting has a structure. Each part may be more or less developed; sometimes

(especially in informal meetings) parts are barely visible. Here are eight setup tasks for thosewho wish to lead successful meetings.

Set a Time That Works

Choose a time of day when people are not likely to be tired, hungry, or otherwise distracted. Let

people know that you will begin the meeting on time and take attendance with a sign-up sheet.Also let them know that minutes of the meeting will be taken. Before the meeting, ask a member

of the group to take minutes. This way, the person will be prepared with a notebook, pen or

pencil, and agenda.

Set a realistic time limit for meetings (for example, a 2-hour meeting that will begin at 1 p.m.and end at 3 p.m.). Try to stick to the time limit. Make sure the meeting room is free of

distractions. Holding a meeting in the main room of a busy restaurant may sound like fun, but the

likelihood of accomplishing anything meaningful there is slim.

Set an Agenda

An agenda helps spell out the items and issues to be discussed and the results that everyone

expects. For some groups, reports from officers, approval of minutes from a previous meeting,

and reports from subcommittees are routine for general meetings. There may be specific old andnew business. In other situations, a meeting may focus on making decisions or recommendations

on a series of issues.

An agenda should help participants see what will be expected of them. You may want to leave

time for suggestions from the group about any new subjects that participants want to discuss.Don't forget to review the agenda as you start the meeting to let participants know what to expect

and to find out whether additional items need to be addressed.

Distribute Available Written Materials in Advance of the Meeting

Sending out a draft agenda and any available proposals or reports a week or two ahead of the

meeting helps participants think through issues, prepare for discussions, and feel more

comfortable making decisions.

Set Up Tasks and Divide Chores

You may be very energetic, but you are only one person. Dividing the choresasking specific

group members to report on specific topics, establishing a subcommittee to investigate a majorissue, or getting someone to help with finding resourceshelps strengthen the group and makes

for more productive meetings in two ways. First, more work gets done. Second, the more your


14/39

committee members are involved, and the more active and productive they are, the more

committed they will be to the group's goals. Don't be afraid to delegate tasks!

Planning a Successful Project

For more information on how to plan asuccessful project, see the NationalYouth Network's Planning a SuccessfulCrime Prevention Project. This 28-pageworkbook explains the five steps of theSuccess Cycle:

Assessing Your Community'sNeeds.

Planning a Successful Project.

Lining Up Resources. Acting on Your Plans. Nurturing, Monitoring, and

Evaluating.

The workbook includes six worksheets foryou to take notes on. You can get a copyof this planning workbook from theJuvenile Justice Clearinghouse, listed inthe Resources section. Good luck!

Set Up Discussions So That Everyone Gets a Say

Discussing topics sometimes takes more time than you would like. Although there are ways to

keep a discussion moving, it is essential that the person running the meeting preside impartially.

Make sure that people who disagree have a chance to state their cases. Your job in facilitatingdiscussions or debates is to be the referee, a person who does not show favor to people or their

ideas. As a referee, you will allow discussion to flow and provide participants a chance to discuss

differing opinions on issues. Your job is to bring opposing sides together by showing areas

where they agree and asking how they can "give a little" to come to a decision that will permit awin-win outcome for everyone.

Set Up a Structure That Keeps Discussion Orderly

Keeping discussions organized and moving forward is a major task and often the most difficult

one you will face. It is sometimes hard to remind participants to pay attention and stay on task.One way to head off these problems is to get your group to agree in advance on the operating

rules for meetings. Rules may be as simple as "one speaker or topic at a time" or "everybody gets

a chance to speak one time before anybody else speaks a second time on the same issue."


15/39

Agreeing on rules ahead of time and deciding what you'll do if people ignore the rules will make

it easier for you as chairperson to keep your group on task and your discussion on target. You'll

be enforcing the group's rules, not your own.

Set Up Ways To Stick to the Subjects

Too often, meetings run over their time limit because the group tries to do all the work through

discussion, when finding the right answer may require some research. The group may get tangled

in a conflict between two people who disagree on a topic that is not easily resolved.

A good way to deal with this problem is to move on to other business, agreeing to either leavethe subject for a future meeting or have a smaller group (a specific committee) look into the

issue. Bring up the idea of using a "parking lot"some place to acknowledge unresolved issues

or additional topics to ensure that they are brought up for later discussion.

Set Up Time To Summarize

Build in time at appropriate points during the meeting and especially at the end of the meeting to

very briefly review and summarize what has taken place. If your meeting has dealt with complex

or far-ranging topics, this is particularly important.

Building in time to summarize your meeting also affirms commitments others have made to thegroup and confirms everyone's understanding of decisions, next steps, and assignments of tasks

to be completed. For example, stating that "George will reserve the auditorium; Mimi will ask

the Mayor to speak; Larry will get approvals from the student council and the principal; andDave and Jenny will draw up a program and arrange for printing" is a good way to reconfirm

people's understanding of their tasks and the group's decisions.

How Can a Meeting Be Evaluated?

Evaluating meetings is a complex process. Evaluating your meetings can help you learn whetheryou have met your goals, but only if you decide up front what you want to evaluate and how you

will go about doing so. In general, the purpose of conducting an evaluation is "to answer

practical questions of decision-makers and program implementors who want to know whether tocontinue a program, extend it to other sites, modify it, or close it down."1 In this case, substitute

"meeting" for program.

If your group intends to hold meetings on a regular basis, you will want to evaluate the

effectiveness of the first few meetings. Consider whether the group accomplished its work,whether everyone understood the followup actions and the impact of decisions, whether all the

participants felt that they had an opportunity to be heard, and whether disagreements were settled

reasonably well. Once you've gained experience conducting meetings with your particular group,you will find that you can make many of these assessments automatically. Until then, this

checklist may be helpful:
http://www.ncjrs.gov/html/ojjdp/yb9909-1/mtg-5.html#note1http://www.ncjrs.gov/html/ojjdp/yb9909-1/mtg-5.html#note1


16/39

Take attendance. At the beginning of every meeting, make note of who is there, who came in

late, and who said they would be there but didn't show up. This can be done formally, as a

teacher records attendance in a notebook, or informally by passing around a sign-in sheet.Assess your records after a few meetings to see who comes regularly and who is always late.

These observations can tell you who is committed to your group and its mission and whether

the meeting time or location is inconvenient for some participants.

Did the meeting start and end on time? If not, why? Did the group have too much businessscheduled? Were discussions unfocused? What needs to happen at the next meeting to enable

you to begin and end as promised?

Was there an agenda that was understandable to all? Did people have the opportunity to add to

the agenda? Was the agenda followed? If not, was the agenda too ambitious, or was theresome other reason? If so, what helped you stay on track and reach decisions?

Were the logistics appropriate and helpful? Think about room temperature, physical setup,

refreshments, and the site's accessibility to members.

Did the discussion leading to a decision provide enough time for pros and cons to be aired?Were issues thoughtfully reviewed or was the decision rushed? Was too much time spenttalking about issues rather than making decisions?

What decisions were made at the meeting and whose work or interests do they affect? Do

these people know about and understand the implications and any new commitments or

responsibilities they have as a result?

Pay attention to the responsiveness of the participants. Did any one person dominate thediscussion? Were there people who should have spoken but did not?

Was the chair or president's facilitation of the meeting smooth and constructive? Do members

feel that everyone understood what was happening and what had happened? Do membersbelieve they had reasonable opportunities to state their views? Do they feel that everyone wastreated fairly?

What was the best thing about the meeting? What was the worst thing? What should be

repeated and what should be improved?

Each of these questions can help you spot problems and may suggest corrective action. The

checklist can also identify strengths of your meetings, which you can build on in future meetings.

In addition to these techniques, evaluation may include thoughtful discussions with individual

group members about your leadership style in meetings and how you can improve it. This can bea sensitive subject and one that may be hard on your ego. Consider carefully whether you are

comfortable inviting and receiving direct criticism. If you are, honest and constructive criticism

may help you improve your skills.


17/39

Implementation

Planning

Planning in organizations and public policy is both the organizational

process of creating and maintaining a plan; and the psychologicalprocess of thinking about the activities required to create a desiredgoal on some scale. As such, it is a fundamental property of intelligentbehavior. This thought process is essential to the creation andrefinement of a plan, or integration of it with other plans, that is, itcombines forecasting of developments with the preparation ofscenarios of how to react to them. An important, albeit often ignoredaspect of planning, is the relationship it holds with forecasting.Forecasting can be described as predicting what the future will look

like, whereas planning predicts what the future should look like.

The term is also used to describe the formal procedures used in suchan endeavor, such as the creation of documents, diagrams, ormeetings to discuss the important issues to be addressed, theobjectives to be met, and the strategy to be followed. Beyond this,planning has a different meaning depending on the political oreconomic context in which it is used.

Two attitudes to planning need to be held in tension: on the one hand

we need to be prepared for what may lie ahead, which may meancontingencies and flexible processes. On the other hand, our future isshaped by consequences of our own planning and actions.

What should a plan be?

A plan should be a realistic view of the expectations. Depending uponthe activities, a plan can be long range, intermediate range or shortrange. It is the framework within which it must operate. Formanagement seeking external support, the plan is the most importantdocument and key to growth. Preparation of a comprehensive plan will

not guarantee success, but lack of a sound plan will almost certainlyensure failure. Planning can be summarized in 3 easy steps:

1. choosing a destination,

2. evaluating alternative routes, and

3. Deciding the specific course of your plan.
http://en.wikipedia.org/wiki/Organizationshttp://en.wikipedia.org/wiki/Public_policyhttp://en.wikipedia.org/wiki/Planhttp://en.wikipedia.org/wiki/Thinkinghttp://en.wikipedia.org/wiki/Intelligencehttp://en.wikipedia.org/wiki/Intelligencehttp://en.wikipedia.org/wiki/Planhttp://en.wikipedia.org/wiki/Forecastinghttp://en.wikipedia.org/wiki/Forecastinghttp://en.wikipedia.org/wiki/Forecastinghttp://en.wikipedia.org/wiki/Organizationshttp://en.wikipedia.org/wiki/Public_policyhttp://en.wikipedia.org/wiki/Planhttp://en.wikipedia.org/wiki/Thinkinghttp://en.wikipedia.org/wiki/Intelligencehttp://en.wikipedia.org/wiki/Intelligencehttp://en.wikipedia.org/wiki/Planhttp://en.wikipedia.org/wiki/Forecastinghttp://en.wikipedia.org/wiki/Forecastinghttp://en.wikipedia.org/wiki/Forecasting


18/39

Purpose of a plan

Just as no two organizations are alike, so also their plans. It istherefore important to prepare a plan keeping in view the necessitiesof the enterprise. A plan is an important aspect of business. It serves

the following three critical functions:

Helps management to clarify, focus, and research their

businesses or project's development and prospects. Provides a considered and logical framework within which a

business can develop and pursue business strategies over thenext three to five years.

Offers a benchmark against which actual performance can be

measured and reviewed.

Importance of the planning process

A plan can play a vital role in helping to avoid mistakes or recognizehidden opportunities. Preparing a satisfactory plan of the organizationis essential. The planning know the business and that they havethought through its development in terms of products, management,finances, and most importantly, markets and competition.

Planning helps in forecasting the future, makes the future visible to

some extent. It bridges between where we are and where we want togo. Planning is looking ahead.

Acceptance test preparation

If you are a Product Manager or Business Analyst in charge ofmanaging users through User Acceptance Testing (UAT), here are thetop 10 things to do to prepare:

1. Formal scripts prepare formal scripts for the business users torun. If you can re-use any of QAs scripts, all the better. At aminimum, use your use cases to build test scripts. As an addedbonus, these scripts will serve as training to the business userson how to use the system after deployment. We suggest youhave scripts for testing both functionally and migrated data.

2. Informal scripts prepare informal, unstructured scripts for thebusiness users to run as well. I strongly encourage you to dothese in addition to formal scripts, in that these are the ones that


19/39

will pull out defects about how the system isnt intuitive to use.In addition, they may think to test things you didnt formallyscript. As an example, this type of script might simply say Loginto the system and take a training course. And you are hopingits intuitive to the user to figure out how to do that on their own.

3. Use a tool we strongly encourage you to put your scripts in atool and teach the business users how to use that tool. Forexample, Quality Center is a tool that works well for this.

4. Master data create master data that can be used for testing bythe business users. This includes logins and passwords and anydata they must look at and/or consume in the tool. A greatstarting place to determine what data you need is to look at yourBusiness Data Diagrams, and then of course look at your scripts.For example, if you have a training system, upload sampletraining courses for them to take during UAT. You should alsoorganize this master data into a format such as a spreadsheet bytest case, so they can quickly reference what data they shoulduse in each script.

5. UAT Kick-off deck Create a slide deck to kick the UAT windowoff with. This kick-off should include the scope of testing, areminder about the value of the system, a reminder that it is atesting phase and they will find defects in the system, andinstructions on how to perform UAT. You need to teach them

about using the tools, how to login, and even where to go toaccess the system.

6. UAT User Manual Create a manual for the users to quicklyreference to while they execute the UAT scripts. You canhopefully reuse some or all of your kick-off slides. You definitelymust include where to access the system (URLs), logins, andwhere to find master data.

7. Pre-run scripts Ideally you should pre-run the scripts before thebusiness users try to execute them. You are familiar with the

system, so your eyes on the scripts will be looking for things thatare not obvious or incorrect steps. This will help ensure a muchmore smoothly run UAT.

8. Teach them how to write a good defect If you want to avoid alot of manual labor yourself, teach the business users how toenter their own defects into a defect tracking system (and yes,


20/39

Im assuming you have one!). You need to teach them whatinformation to include (logins, urls, and steps to recreate) andhow to set severity and priority values if appropriate.

9. Coordinate build schedule with dev Make sure your dev team is

onboard with your UAT testing schedule so that they dont do abuild while users are trying to test. And more importantly, if theydo a build overnight that they dont take the system down with abroken build! In general you need to coordinate with your entireIT team; I just call this one out as they have an immediate wayto cripple testing by accident.

10. Work with a business owner so they truly own acceptance All of that said, you need to make sure there is someone in thebusiness who owns the UAT process. You are simply here tofacilitate it going well and do a lot of the prep work for them. Buttruly, they must be the ones who own acceptance of the systemor they will never actually adapt it for use. So every step of theway as you go through your prep tasks is sure you are gettingthe business UAT owners buy-in!

Quality

Quality Assurance

Quality assurance, or QA for short, refers to a program for thesystematic monitoring and evaluation of the various aspects of aproject, service, or facility to ensure that standards of quality arebeing met.

It is important to realize also that quality is determined by theprogram sponsor. QA cannot absolutely guarantee the production ofquality products, unfortunately, but makes this more likely.

Two key principles characterize QA: "fit for purpose" (the productshould be suitable for the intended purpose) and "right first time"(mistakes should be eliminated). QA includes regulation of the qualityof raw materials, assemblies, products and components; servicesrelated to production; and management, production and inspectionprocesses.
http://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Quality_(business)


21/39

It is important to realize also that quality is determined by theintended users, clients or customers, not by society in general: it isnot the same as 'expensive' or 'high quality'. Even goods with lowprices can be considered quality items if they meet a market need. QAis more than just testing the quality of aspects of a product, service orfacility, it analyzes the quality to make sure it conforms to specificrequirements and comply with established plans.

Steps for Quality Assurance Process

Test previous articles

Plan to improve

Design to include improvements and requirements

Manufacture with improvements

Review new item and improvements

Test new item

The process for Quality Assurance is very rigorous and requires a lot oftesting and planning. The team or firm has to comply with previousrequirements, implement new requirements and improve the old item.Other than following requirements, the team or firm has to complywith consumers needs.

Quality assurance versus quality control

Quality control emphasizes testing of products to uncover defects, andreporting to management who make the decision to allow or deny therelease, whereas quality assurance attempts to improve and stabilizeproduction, and associated processes, to avoid, or at least minimize,issues that led to the defects in the first place.[citation needed]. Onapplying Quality Assurance in Education the gross purpose of applyingquality assurance is served.

To prevent mistakes from arising, several QA methodologies are used.However, QA does not eliminate the need for QC: some product

parameters are so critical that testing is still essential. QC activities aretreated as one of the overall QA processes

Failure testing

A valuable process to perform on a whole consumer product is failuretesting or stress testing. In mechanical terms this is the operation of a
http://en.wikipedia.org/wiki/Quality_controlhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/w/index.php?title=Quality_Assurance_in_Education&action=edit&redlink=1http://en.wikipedia.org/wiki/Consumerhttp://en.wikipedia.org/wiki/Stress_testinghttp://en.wikipedia.org/wiki/Quality_controlhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/w/index.php?title=Quality_Assurance_in_Education&action=edit&redlink=1http://en.wikipedia.org/wiki/Consumerhttp://en.wikipedia.org/wiki/Stress_testing


22/39

product until it fails, often under stresses such as increasing vibration,temperature, and humidity. This exposes many unanticipatedweaknesses in a product, and the data are used to drive engineeringand manufacturing process improvements. Often quite simple changescan dramatically improve product service, such as changing to mold-resistant paint or adding lock-washer placement to the training for newassembly personnel.

Statistical control

Many organizations use statistical process control to bring theorganization to Six Sigma levels of quality, in other words, so that thelikelihood of an unexpected failure is confined to six standarddeviations on the normal distribution. This probability is less than fourone-millionths. Items controlled often include clerical tasks such asorder-entry as well as conventional manufacturing tasks. Traditionalstatistical process controls in manufacturing operations usuallyproceed by randomly sampling and testing a fraction of the output.Variances in critical tolerances are continuously tracked and wherenecessary corrected before bad parts are produced.

Total quality management

Invariably, the Quality of output is directly dependent upon that of theparticipating constituents, some of which are sustainably andeffectively controlled while others are [not]. The fluid state spells lackof Quality control, and the process(es) which are properly managed forQuality such that Quality is assured, pertain to Total QualityManagement.

Walkthrough

In software engineering, a walkthrough or walk-through is a form ofsoftware peer review "in which a designer or programmer leadsmembers of the development team and other interested partiesthrough a software product, and the participants ask questions andmake comments about possible errors, violation of developmentstandards, and other problems".
http://en.wikipedia.org/wiki/Vibrationhttp://en.wikipedia.org/wiki/Temperaturehttp://en.wikipedia.org/wiki/Humidityhttp://en.wikipedia.org/wiki/Weaknesshttp://en.wikipedia.org/wiki/Process_improvementhttp://en.wikipedia.org/wiki/Moldhttp://en.wikipedia.org/wiki/Painthttp://en.wikipedia.org/w/index.php?title=Lock-washer&action=edit&redlink=1http://en.wikipedia.org/wiki/Traininghttp://en.wikipedia.org/wiki/Statistical_process_controlhttp://en.wikipedia.org/wiki/Organizationhttp://en.wikipedia.org/wiki/Six_Sigmahttp://en.wikipedia.org/wiki/Standard_deviationhttp://en.wikipedia.org/wiki/Standard_deviationhttp://en.wikipedia.org/wiki/Normal_distributionhttp://en.wikipedia.org/wiki/1_E-6http://en.wikipedia.org/wiki/Clerical_taskhttp://en.wikipedia.org/wiki/Total_Quality_Managementhttp://en.wikipedia.org/wiki/Total_Quality_Managementhttp://www.answers.com/topic/software-engineeringhttp://www.answers.com/topic/software-peer-reviewhttp://en.wikipedia.org/wiki/Vibrationhttp://en.wikipedia.org/wiki/Temperaturehttp://en.wikipedia.org/wiki/Humidityhttp://en.wikipedia.org/wiki/Weaknesshttp://en.wikipedia.org/wiki/Process_improvementhttp://en.wikipedia.org/wiki/Moldhttp://en.wikipedia.org/wiki/Painthttp://en.wikipedia.org/w/index.php?title=Lock-washer&action=edit&redlink=1http://en.wikipedia.org/wiki/Traininghttp://en.wikipedia.org/wiki/Statistical_process_controlhttp://en.wikipedia.org/wiki/Organizationhttp://en.wikipedia.org/wiki/Six_Sigmahttp://en.wikipedia.org/wiki/Standard_deviationhttp://en.wikipedia.org/wiki/Standard_deviationhttp://en.wikipedia.org/wiki/Normal_distributionhttp://en.wikipedia.org/wiki/1_E-6http://en.wikipedia.org/wiki/Clerical_taskhttp://en.wikipedia.org/wiki/Total_Quality_Managementhttp://en.wikipedia.org/wiki/Total_Quality_Managementhttp://www.answers.com/topic/software-engineeringhttp://www.answers.com/topic/software-peer-review


23/39

"Software product" normally refers to some kind of technicaldocument. As indicated by the IEEE definition, this might be a softwaredesign document or program source code, but use cases, businessprocess definitions, test case specifications, and a variety of othertechnical documentation may also be walked through.

A walkthrough differs from software technical reviews in its opennessof structure and its objective of familiarization. It differs from softwareinspection in its ability to suggest direct alterations to the productreviewed its lack of a direct focus on training and processimprovement, and its omission of process and product measurement.

Walkthrough Documentation

The outcome of the walkthrough is always documented. Usually only

two documents are produced. One is a summary that describes the walkthrough outcomes;

Action list which shows all the issues rose during the walkthroughand more importantly, who is to be responsible for resolvingthese issues.

Walkthrough Team Composition

The optimized size for a walkthrough team is never and nowherementioned. The teams members should be selected in the way thatwill ensure the issues are adequately covered. The size of the team

thus depends on the material to be covered and upon the skills andreview experience of the potential participants. The people without theknowledge of the system must not be kept in the walkthrough team.The number of participants will be somewhere between three andseven.Specific tasks are allocated to some of the walkthrough teammembers. They are usually selected to take the roles of:

The walkthrough leader

The walkthrough secretary and

The walkthrough reader ( or producer)

The walkthrough leader

The job of the leader is to ensure a good walkthrough or to report the reasons why a godwalkthrough was not achieved. A good walkthrough produces an accurate assessment of the

product as it new stands. The major cause for the failure of the walkthrough may be that one or

more members of the team were unprepared.

Following are the roles of the leader in the walkthrough:
http://www.answers.com/topic/design-documenthttp://www.answers.com/topic/design-documenthttp://www.answers.com/topic/source-codehttp://www.answers.com/topic/use-casehttp://www.answers.com/topic/business-processhttp://www.answers.com/topic/business-processhttp://www.answers.com/topic/test-casehttp://www.answers.com/topic/software-technical-reviewhttp://www.answers.com/topic/software-inspectionhttp://www.answers.com/topic/software-inspectionhttp://www.answers.com/topic/design-documenthttp://www.answers.com/topic/design-documenthttp://www.answers.com/topic/source-codehttp://www.answers.com/topic/use-casehttp://www.answers.com/topic/business-processhttp://www.answers.com/topic/business-processhttp://www.answers.com/topic/test-casehttp://www.answers.com/topic/software-technical-reviewhttp://www.answers.com/topic/software-inspectionhttp://www.answers.com/topic/software-inspection


24/39

Ensure good walkthrough and report the reason for the failure

Understand the points raised in the walkthrough, before, during and after the function

Collect relevant material, select people who are to attend the walkthrough.

Distribute copies of the relevant materials to those people to ensure that they are well

prepared for the walkthrough process.

Ensure relevant topics and the contribution of the every individual in the meeting duringwalkthrough.

Make all the members of the team understand the agreement correctly and precisely.

Sees if the report produced is accurate as per the customers requirement.

The Secretary

The walkthrough leader chooses one of the participants to take on the role of secretary, whosefunctions are:

Record the result of the walkthrough

Meet all the other participants of the team and identify them by name

Must collect all the available materials necessary for keeping accurate record of thewalkthrough.

Record all issues accurately; state each outcome explicitly and unambiguously and

neutrally during the walkthrough.

Prepares all reports promptly and makes all the participants to sign them.

Distributes copies of the reports to all the relevant people.

The Reader (Producer)

The producer is responsible for describing the product under review. He plays the following

roles:

Prepares DFDs, Process descriptions and models.

Call meeting

Go through the documentation and bring before the meeting the topic which needed extra

focus by the team members

The Participant

Each members of the walkthrough team are the reviewer of the product being walkthrough and is

responsible for the good or bad happening on the outcome. Following are the responsibilities of

the participants:

Individual members must be well prepared before moving forward.

Should take neutral and constructive stands in all issues.

Must not grow aggressive and criticize the producers. Each participant must make at least one positive and one negative point to guarantee that

each participant will have an input.

Participants should raise issues rather than solving them and attempt to learn about the

unfamiliar terms and should not unnecessarily criticize the work.


25/39

Objectives and participants

In general, a walkthrough has one or two broad objectives: to gainfeedback about the technical quality or content of the document;and/or to familiarize the audience with the content.

A walkthrough is normally organized and directed by the author of thetechnical document. Any combination of interested or technicallyqualified personnel (from within or outside the project) may beincluded as seems appropriate.

IEEE 1028[1] recommends three specialist roles in a walkthrough:

The Author, who presents the software product in step-by-step

manner at the walk-through meeting, and is probably responsible

for completing most action items; The Walkthrough Leader, who conducts the walkthrough, handles

administrative tasks, and ensures orderly conduct (and who isoften the Author); and

The Recorder, who notes all anomalies (potential defects), decisions,and action items identified during the walkthrough meetings.

Structure Chart

Structure charts are one of the most commonly used methods for system design. In a structurechart each program module is represented by a rectangular box. Modules at the top level of the

structure chart call the modules at the lower lever. The connections between modules are

represented by lines between the rectangular boxes. The connection describes the data flowsbetween the called the calling modules. The following figure shows the four modules where the

top module is called COMPUTE-SALE-TOTAL. This module calls three lower lever program

modules to accomplish its task. It calls module READ-SALES-TRANSACTION to read

individual sales transactions. It then calls the module ADD-TO-TOTAL to sum the amount ineach transaction. Finally, it calls module OUTPUT-TOTAL to output the sum.

Fig: Structure Chart

COMPUTE-SALE-TOTAL

READ-SALE-TRANSACTION ADD-TO-TOTAL OUTPUT-TOTAL

Sales Transaction

Sales Transaction

Sales Total

Sales Total
http://www.answers.com/topic/software-walkthrough#cite_note-IEEE1028-0http://www.answers.com/topic/anomaly-in-softwarehttp://www.answers.com/topic/software-walkthrough#cite_note-IEEE1028-0http://www.answers.com/topic/anomaly-in-software


26/39

Structure Chart Conventions

Structure chart uses a number of conventions to describe system operation. The most important

conventions specify the execution sequence and parameter passing between modules.

Parameter Passing

The calling module passes a set of values to the called module and receives a set of values inreturn. These values are passed as parameter values. The parameters are shown in the structure

chart next to the connection. Thus, in the above figure, a value ofsales transaction is passedfrom module READ-SALES-TRANSACTION to module COMPUTE-SALES-TOTAL. Module

COMPUTE-SALES-TOTAL then passes the value ofSale Transaction to module ADD-TO-

TOTAL and gets a value ofSales Total in return. The value ofSale Total is then passed from

module COMPUTE-SALES-TOTAL to module OUTPUT-TOTAL.

Execution sequence

By convention, modules are executed from left to right. Thus, in the above figure, module

READ-SALES-TRANSACTION is called before module ADD-TO-TOTAL. Module OUTPUT-

TOTAL is the last module to be called.Certain conventions are also used to represent decisions and repetition. Decisions occur

whenever a calling module has to decide to call only one of a number of modules. Repetition, onthe other hand occurs when some module s are called repetitively by the calling module.

Repetition is modeled by a looping arrow. As an example, in the figure above, module

COMPUTE-SALES-TOTAL calls modules READ-SALES-TRANSACTION and ADD-TO-

TOTAL any number of timesDecisions are modeled by a diamond symbol. An example of decisions is given in the below

figure where module A:

Calls either module B or module C; and then

Executes a loop which calls module D, E and sometimes F.

A

B CD E F

Fig: Procedural Annotations


27/39

Structure Charts and Structured DesignStructure charts are developed by a process called structured design. The objective of structured

design is to produce structure charts with properties commensurate with good programmingpractice. A number of properties are used to judge how well structure charts satisfy these

objectives.

These properties are usually known as modulecouplingand Cohesion. Module cohesion is also

sometimes called module strength.

Coupling describes the nature, direction and quantity of parameters passed between modules,

while cohesion describes how system functions are coded into modules. A goal of structured

design is to minimize the complexity of coupling between modules. Structure charts with simplecoupling are said to have low coupling. Another goal of structured design is to represent a well-

defined system function by one module. When this happens, we have high strength. Structurecharts with low coupling and high strength result in greater independence between modules andeasier maintenance, as one module can be changed independently of other modules.

The proponents of structured design have devised measures of coupling and module strength. A

number of terms are used to describe coupling and cohesion. These terms are ordered into arange starting with the least desirable to the most desirable.

Module Coupling

Module coupling measures the quality of the connections between modules in the structure chart.

The objective is to design structure charts that only pass data and not control information

between program modules. However, a first-cut design may not meet this objective and the

structure chart may exhibit other kinds of coupling. There are a number of ways to describecoupling. The best coupling is data coupling, followed by control coupling, common coupling

and content coupling.

Content coupling

Two modules are content coupled if one module makes a direct reference to the contents of

another module. This kind of coupling allows the calling module to modify a program statementin the called module or to refer to an internally defined data element of the called module. It also

allows one module to branch into another module. Content coupling should be avoided at all

costs, and structure chart should ensure that the only way to pass information between modules isby parameter values passed during sub-routine calls.

Common-environment Coupling

Two modules are common-environment coupled if they refer to the same data structure or data

element in a common environment. Example of common-environment coupling is that modulesthat appear unrelated in a structure chart are coupled through their use of common data.

Control Coupling


28/39

Two modules are control coupled if one module passes a control element to the other module.

This control element affects the processing in the receiving module. Typical examples of control

coupling are flags, function codes and switches. Control coupling violets the principle ofinformation hiding. Passing a control element from a calling module to a called module implies

that the calling module must know the method of operation of the called module. Any changes

made to the called module can then require changes in the calling module.

Data Coupling

Two modules are data coupled if they are not content coupled, common-environment coupled or

control coupled. Only data elements are passed as parameters between two data coupledmodules. Data coupling is seen as the most desirable form of coupling. The calling module

passes data values by parameters to the called module and expects some computations to be

made on these values. The results of the computation are then returned as parameter values to thecalling module. The calling module need not be aware of how the program does the computation.

Module Strength

Module strength measures reasons why code appears in the same module. Many writers use thefollowing six levels of module strength (listed from the least to the most desirable):

Coincidental Strength

Coincidental strength exists if there is no meaningful relationship between the parts in a module.

It often occurs when existing code is modularized. Modularization often proceeds by searching

existing code for multiple occurrences of sequences of commands and replacing these sequencesby modules. Often such modules are not related to well-defined system functions, but result from

techniques that have been used to write the program.

Logical Strength

Logical strength occurs when all elements in a module perform similar tasks- for example,modules that include all editing, or modules that include all accesses to a file. Considerable

duplication can exist in the logical strength level. For example, more than one data item in aninput transaction may be a date. Separate code would be written to check that each such date is a

valid data. A better way is to construct a DATE-CHECK module and call this module whenever

a date check is necessary.

Temporal Strength

Temporal strength is very similar to logical strength. All functions related to time are grouped

into one module. Typical examples are INITIATION and TERMINATION modules. Temporal

strength is generally regarded as stronger than logical strength, but it still has some undesirablefeatures as far as change is concerned. For example, adding a new file to a system will result in

changes to both the INITIATION and TERMINATION modules, as well as to those modules

directly concerned with operations on the new file.

Procedural Strength

Procedural strength often results when a flowchart is divided into a number of sections and each

section is represented by one module. This division may not be ideal, as the flowchart can


29/39

represent one well-defined system function; division distributes this self-contained function

among a number of modules.

Communicational Strength

Communicational strength occurs when processes that communicate with each other are included

in the same module. Thus all actions concerned with a file may be included in the same module.This module will read the file, process it and write the output back to the file. The most quotedproblem with communicational strength is the interdependence of processes in the module. For

example, we may include code that uses the input from a file in the same module as the code that

reads the file. However, the file read ad the use of the information from the file may occur indifferent time frames and may share common buffers. A change that allows concurrent reads

and writes to the file may result in unexpected problem.

Functional Strength

A module that has functional strength carries out one well-defined function. This module doesnot have those properties that characterize coincidental, logical, temporal, procedural or

communicational strength.

Some common structures of Structure chart

Structure charts are often characterized by some constructs that tend to reappear in manyapplications. Two such important constructs are:

Transform-centered structures

Transform-centered structures receive an input which is transformed by a sequence ofoperations, with each operation being carried out by one module.

Fig: Transform Structure

Input Modules Transform Module Output Modules

COMPUTE-VI COMPUTE-B COMPUT - C PUT-C

GET-Y CHANGE-Y

C

C

BV2

BV1

Y

YX

MAIN

GET-X T1

T2 PUT- B

X X

A A

BB

V1

A


30/39

The figure above is a transform-centered structure where:

The MAIN module calls GET-X module to get input parameter, X. Module GET-X callsGET-Y module to read a value from the input device and pass it back to GET-X as a

value of parameter Y. GET-X then calls CHANGE-Y module to compute a value of X

from the value of Y.

The module T1 is then called to compute a value of A from the value of X.

Another module T2 is then called to compute a value of B from the value of A. To do

this, module T2 calls its subordinate modules, COMPUTE-VI and COMPUTE-B.

The MAIN module then calls PUT-B module to output the result of the computation.

PUT-B module first calls COMPUTE-C module to compute a value of C and then calls

PUT-C module to output that particular value of C.

Transaction-centered structuresA transaction-centered structure describes a system that processes a number of different types of

transactions. It is illustrated in the figure below. Here MAIN module controls systemsoperations. Its function is to:

Call the INPUT module to read a transaction

Determine the kind of transaction and select one of a number of transaction module to

process that transaction

Output the results of the process by calling OUTPUT module.

System World

In the system world we begin to talk more in general system ways which can be applied to any

problem. This area is often termed conceptual modelingin computer system design. It describesthe system in terms that are useful to computer systems designers in developing computer system

specifications. One set of terms comes under the general heading ofstructured system analysis.

MAIN

INPUT Transaction

Module 1

Transaction

Module 2Transaction

Module 3Output

Fig: Transaction Centered Structure


31/39

They include models such as data flow diagrams, entity relationship and process descriptions.

Another set of terms come from object oriented design

The subject World

The subject world focuses on business issues. Its goal is to identify the crucial measurement of

business success and propose ways to achieve them. The important factor in subject worldmodeling is to eliminate the problems found in the usage world and to clearly define the terms

that describe the user world. Definition of such terms is also recognized as in important step in

soft system methodologies. This approach is followed in object-oriented design by generalizingindividual scenarios into use cases, usually accompanied by a clear definition of subject terms.

Many systems are becoming increasingly complex. As a result, subject world models are one of

the least known in the conversion process. There are few criteria that can be used to evaluatesubject world models, although there is a tendency to define best practices in many industries.

Eventually these will become the guidelines used to evaluate the subject world. There is also a

trend for people to become subject world specialists-For example, the bank analysis specialist,whose main activity may be to develop models of the subject world and to express them as

conceptual schema in the system world. Soft system methodologies approach the subject worldby defining standard subject terms once the initial analysis is completed. These terms are then

used to create a subject world model.

Use Case Diagram

Use case diagrams overview the usage requirements for a system. They are useful forpresentations to management and/or project stakeholders, but for actual development you will

find that use casesprovide significantly more value because they describe "the meat" of the

actual requirements.

Use case diagrams depict

Use cases. A use case describes a sequence of actions that provide something of measurable

value to an actor and is drawn as a horizontal ellipse.

Actors. An actor is a person, organization, or external system that plays a role in one or more

interactions with your system. Actors are drawn as stick figures.

Associations. Associations between actors and use cases are indicated in use case diagrams

by solid lines. An association exists whenever an actor is involved with an interaction describedby a use case. Associations are modeled as lines connecting use cases and actors to oneanother, with an optional arrowhead on one end of the line. The arrowhead is often used toindicating the direction of the initial invocation of the relationship or to indicate the primary actorwithin the use case. The arrowheads are typically confused with data flow and as a result I avoid

their use. System boundary boxes (optional). You can draw a rectangle around the use cases, called the

system boundary box, to indicate the scope of your system. Anything within the box representsfunctionality that is in scope and anything outside the box is not. System boundary boxes arerarely used, although on occasion I have used them to identify which use cases will be delivered

in each major release of a system. Figure 2 shows how this could be done. Packages (optional). Packages are UML constructs that enable you to organize model

elements (such as use cases) into groups. Packages are depicted as file folders and can be usedon any of the UML diagrams, including both use case diagrams and class diagrams. I use
http://www.agilemodeling.com/artifacts/systemUseCase.htmhttp://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure2SystemBoundaryBoxeshttp://www.agilemodeling.com/artifacts/systemUseCase.htmhttp://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure2SystemBoundaryBoxes


32/39

packages only when my diagrams become unwieldy, which generally implies they cannot be

printed on a single page, to organize a large diagram into smallerones. Figure 3 depicts how

Figure 1 could be reorganized with packages.

In the example depicted in Figure 1 students are enrolling in courses with the potential

help of registrars. Professors input the marks students earn on assignments and registrars

authorize the distribution of transcripts (report cards) to students. Note how for some use

cases there is more than one actor involved. Moreover, note how some associations havearrowheads -Any given use case association will have a zero or one arrowhead. The

association between Student and Enroll in Seminar (in the version shown inFigure 4)

indicates this use case is initially invoked by a student and not by a registrar (theRegistrar actor is also involved with this use case). Understanding that associations dont

represent flows of information is important; they merely indicate an actor is somehow

involved with a use case. Information is flowing back and forth between the actor andthe use case, for example, students would need to indicate which seminars they want to

enroll in and the system would need to indicate to the students whether they have been

enrolled. However, use case diagrams dont model this sort of information. Information

flow can be modeled using UML activity diagrams. The line between the Enroll inSeminar use case and the Registrar actor has no arrowhead, indicating it is not clear how

the interaction between the system and registrars start. Perhaps a registrar may notice a

student needs help and offers assistance, whereas other times, the student may requesthelp from the registrar, important information that would be documented in the

description of the use case. Actors are always involved with at least one use case and are

always drawn on the outside edges of a use case diagram.

Figure 1. System use case diagram.
http://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure3Packageshttp://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure1http://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure1http://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure4Reusehttp://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure4Reusehttp://www.agilemodeling.com/artifacts/activityDiagram.htmhttp://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure3Packageshttp://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure1http://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure1http://www.agilemodeling.com/artifacts/useCaseDiagram.htm#Figure4Reusehttp://www.agilemodeling.com/artifacts/activityDiagram.htm


33/39

Figure 2. Using System boundary boxes to indicate releases.

Figure 3. Applying packages to simplify use case diagrams.


34/39

UML sequence diagram

UML sequence diagrams are used to represent or model the flow of messages, events and

actions between the objects or components of a system. Time is represented in the verticaldirection showing the sequence of interactions of the header elements, which are displayed

horizontally at the top of the diagram.

Sequence Diagrams are used primarily to design, document and validate the architecture,interfaces and logic of the system by describing the sequence of actions that need to be

performed to complete a task or scenario. UML sequence diagrams are useful design tools

because they provide a dynamic view of the system behavior which can be difficult toextract from static diagrams or specifications.

Although UML sequence diagrams are typically used to describe object-oriented softwaresystems, they are also extremely useful as system engineering tools to design system

architectures, in business process engineering as process flow diagrams, as messagesequence charts and call flows for telecom/wireless system design, and for protocol stack

design and analysis.

Sequence Diagram Drawing Elements

Sequence Diagram Header Elements

The header portion of the sequence diagram represents the components or objects of the

system being modeled and are laid out horizontally at the top of the diagram. See anexample sequence diagram here.


35/39

Actor

Represents an external person or entity that

interacts with the systemObject

Represents an object in the system or one of its

components

Unit

Represents a subsystem, component, unit, or other

logical entity in the system (may or may not beimplemented by objects)

Separator

Represents an interface or boundary between

subsystems, components or units (e.g., airinterface, Internet, network)

Group

Groups related header elements into subsystems orcomponents

Sequence Diagram Body Elements

Action

Represents an action taken by an actor, objector unit

AsynchronousMessage An asynchronous message between header

elements

Block

A block representing a loop or conditional for a

particular header element

Call Message

A call (procedure) message between header

elements

CreateMessageA "create" message that creates a header

element (represented by lifeline going from

dashed to solid pattern)DestroyElement Represents the destruction of a header element

Destroy

Message Represents the destruction of a header element

as a result of a call from another element


36/39

Diagram Link

Represents a portion of a diagram being treated

as a functional block. Similar to a procedure orfunction call that abstracts functionality or

details not shown at this level. Can optionally belinked to another diagram for elaboration.

Else Block Represents an "else" block portion of a diagramblock

Flow Note

Documentation note that is automatically

formatted to flow after previous elements

Free Note

Documentation note that is free-flowing and can

be placed anywhere in the diagram (can also beanchored relative to a flow element)

Message

A simple message between header elements

Page Break

A page break in the diagram

Return Message

A return m

system analysis and design-purbanchal university notes for bit/bca

Documents