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 many national 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 purpose or 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 and so 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

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. Those can not eventually stop. System boundary System component Input 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 priced and 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 Output

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 the process 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. Management Information system (MIS): TPS are operation oriented. In contras MIS assist managers in decision making and problem solving. They work on the data 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 to formulate 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 make informed 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

(ii)

make decisions that are not highly structured, often called unstructured or semistructured 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 identify information 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 other information 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 not structured. 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:

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 collection of 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 method produce 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 build computer-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 organization managers, 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 as follow (i) (ii) (iii) (iv) (v) (vi) (vii) Defining requirement Categorized the requirements and determines the priority. Gathering data, facts and opinions of facts. Analysis and evaluation Solving up specifications Designing system 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 system about passenger, flight and ticket information. Indirect users: This is the users who do not interact with the hardware or software, 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 employee of the firm.

(ii)

(iii)

User manager: Such type users have management responsibility for application software. These users may be upper level managers. These users may not actually use 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. Senior management: They take the increased responsibility for the development of information systems.

(iv)

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 Organization

There are two ways of viewing the organization. One is as traditional hierarchical structure and the 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.
Set Goals Strategic Arrange Resources

Management

Operational

Carry out tasks

Fig: Organizational Levels

Strategic Level

This 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 a decision on the particular kind of products, marketing strategy, funds to be invested etc.

Management Level

The 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 the acquisition 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 Level

The detailed tasks set by the aforesaid level are carried out by the people at the operational level. 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 is through the management level. Hence the resources available and used must be informed to the people at the management level before being forwarded to the strategic level

Flatter Structures

This is more adaptive and effective structure to bring people from different parts of the organization together and to arrange their activities as customer needs change. Such rearrangement 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 to reduce 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 Groups

Groups can be categorized into many ways: - Open Groups: This group allows members to be freely added or deleted from the group. The open group may be loosely coupled (allows the group members to act independently of each other) or tightly coupled (group imposes the restrictions on interactions). - Closed Groups: The group does not allow members to be added or deleted freely.

Information Exchange

This 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 of information exchange. The simplest support for message exchange is electronic mail, or email, 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.

Each user on internet has their own unique electronic address, and all messages with that address 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 are often 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 of information 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 look up their bulletin board at their convenience.

Supporting personal Relationships

Support for personal relationships provides people with the services needed to communicate effectively and to maintain productive and satisfying relationships.

Work
The task which has to be performed to accomplish some goals is called work. There are different types of works: a. Planned Work: The work where the sequence of tasks can be predefined. The process 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 diagram shows the planned work flow:

Request File

Order File

Initiate request Step 1

Approve request Step 2

Arrange Purchase

Accept Delivery

Step 3

Step 4

b. Situated Work: the work is often unstructured. It often requires closer coordination than 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 to coordinate their activities at a much more detailed level. Second, this closer

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

Chapter 3 Concept Formation

Problem

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 is happening 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 particularly useful 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 project goal 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 such deficiencies. 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 operations
Solution

The remedy to the problem is solution. Solutions should not be unrealizable that are subsequently 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 solutions and 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 as possible to ensure that the best solution is chosen. Certain amount of skill is needed to propose good alternatives and choose the right direction.

Feasibility Analysis

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

descriptions of what the new system should look like. The next step evaluates the feasibility of 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 be techically 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 existing systems 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 performance aspect and the other is acceptance within the organization.Technical performance includes issues such as determining whether the system can provide the right information 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 with the current operations and what, if any, job restructuring and restructuring and retraining may be needed to implement the system. The evaluation must then determine 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 is economically acceptable. This evaluation looks at the financial aspects of the project. It determines whether the investment needed to implement the system will be recoverred. Economic feasibility Economic 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 else should 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 project for 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 which describes the economic aspects of the project is discuss under cost benefit analysis. Cost-benefit Analysis This analysis usually includes two steps: - Producing the estimates of costs and benefits: The goal is to produce a list of what is required 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. the purchase of equipment, time spent by people writing programs, or items such as insurance cost or the cost of borrowing money). Some of the tangible cost includes: o Equipment cost for the new system o Personnel costs o Material costs o Conversion costs o Training costs o Other costs

Intangible items, on the other hand, are those whose values cannot be precisely determined and are the result of subjective judgment. For instance, how much is saved by completing a project earlier or providing new information to decision makers? The sum value of cost of items needed to implement the system is known as the cost of the system. The sum value of the savings made is known as the benefit of the new system. Whether the project is economically viable is determined by the agreement on the cost and benefits of the project. Determining whether the project is worthwhile once these costs are ascertained: The costs and benefits are used to determine whether a project is economically feasible. 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. The difference 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 years needed to recover the costs is determined. Suppose a project costing $100,000 is implemented in year0. The benefits for each successive years are 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 is recovered 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 to determine how much money it is worthwhile investing now in order to receive 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,000 today 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 is worthwhile 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 as Present value=40,000/ (1+10/100)2 =33,057 The cumulative sum of the present value for each year is calculated and compared to the initial investment. If the sum of the present value is greater than the initial investment, the project is worthwhile.

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 project requires 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 generate enthusiasm 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 the purpose 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 to a 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, take turns 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.

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 those who 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 and new 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 major issue, 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

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 a successful project, see the National Youth Network's Planning a Successful Crime Prevention Project. This 28-page workbook explains the five steps of the Success Cycle:

Assessing Your Community's Needs. Planning a Successful Project. Lining Up Resources. Acting on Your Plans. Nurturing, Monitoring, and Evaluating.

The workbook includes six worksheets for you to take notes on. You can get a copy of this planning workbook from the Juvenile Justice Clearinghouse, listed in the 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 facilitating discussions 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 a win-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."

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 leave the 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 the group 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; and Dave 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 whether you 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 to continue 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:

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 business scheduled? 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 there some 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 spent talking 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 the discussion? 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 members believe they had reasonable opportunities to state their views? Do they feel that everyone was treated 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 be a 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.

Implementation

Planning
Planning in organizations and public policy is both the organizational process of creating and maintaining a plan; and the psychological process of thinking about the activities required to create a desired goal on some scale. As such, it is a fundamental property of intelligent behavior. This thought process is essential to the creation and refinement of a plan, or integration of it with other plans, that is, it combines forecasting of developments with the preparation of scenarios of how to react to them. An important, albeit often ignored aspect 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 such an endeavor, such as the creation of documents, diagrams, or meetings to discuss the important issues to be addressed, the objectives to be met, and the strategy to be followed. Beyond this, planning has a different meaning depending on the political or economic 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 mean contingencies and flexible processes. On the other hand, our future is shaped by consequences of our own planning and actions.

What should a plan be?

A plan should be a realistic view of the expectations. Depending upon the activities, a plan can be long range, intermediate range or short range. It is the framework within which it must operate. For management seeking external support, the plan is the most important document and key to growth. Preparation of a comprehensive plan will not guarantee success, but lack of a sound plan will almost certainly ensure 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.

Purpose of a plan
Just as no two organizations are alike, so also their plans. It is therefore important to prepare a plan keeping in view the necessities of 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 the next 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 recognize hidden opportunities. Preparing a satisfactory plan of the organization is essential. The planning know the business and that they have thought 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 to go. Planning is looking ahead.

Acceptance test preparation

If you are a Product Manager or Business Analyst in charge of managing users through User Acceptance Testing (UAT), here are the top 10 things to do to prepare: 1. Formal scripts prepare formal scripts for the business users to run. If you can re-use any of QAs scripts, all the better. At a minimum, use your use cases to build test scripts. As an added bonus, these scripts will serve as training to the business users on how to use the system after deployment. We suggest you have scripts for testing both functionally and migrated data. 2. Informal scripts prepare informal, unstructured scripts for the business users to run as well. I strongly encourage you to do these in addition to formal scripts, in that these are the ones that

will pull out defects about how the system isnt intuitive to use. In addition, they may think to test things you didnt formally script. As an example, this type of script might simply say Login to the system and take a training course. And you are hoping its 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 a tool and teach the business users how to use that tool. For example, Quality Center is a tool that works well for this. 4. Master data create master data that can be used for testing by the business users. This includes logins and passwords and any data they must look at and/or consume in the tool. A great starting place to determine what data you need is to look at your Business Data Diagrams, and then of course look at your scripts. For example, if you have a training system, upload sample training courses for them to take during UAT. You should also organize this master data into a format such as a spreadsheet by test case, so they can quickly reference what data they should use in each script. 5. UAT Kick-off deck Create a slide deck to kick the UAT window off with. This kick-off should include the scope of testing, a reminder about the value of the system, a reminder that it is a testing phase and they will find defects in the system, and instructions on how to perform UAT. You need to teach them about using the tools, how to login, and even where to go to access the system. 6. UAT User Manual Create a manual for the users to quickly reference to while they execute the UAT scripts. You can hopefully reuse some or all of your kick-off slides. You definitely must include where to access the system (URLs), logins, and where to find master data. 7. Pre-run scripts Ideally you should pre-run the scripts before the business users try to execute them. You are familiar with the system, so your eyes on the scripts will be looking for things that are not obvious or incorrect steps. This will help ensure a much more smoothly run UAT. 8. Teach them how to write a good defect If you want to avoid a lot of manual labor yourself, teach the business users how to enter their own defects into a defect tracking system (and yes,

Im assuming you have one!). You need to teach them what information to include (logins, urls, and steps to recreate) and how 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 a build while users are trying to test. And more importantly, if they do a build overnight that they dont take the system down with a broken build! In general you need to coordinate with your entire IT team; I just call this one out as they have an immediate way to 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 the business who owns the UAT process. You are simply here to facilitate it going well and do a lot of the prep work for them. But truly, they must be the ones who own acceptance of the system or they will never actually adapt it for use. So every step of the way as you go through your prep tasks is sure you are getting the business UAT owners buy-in!

Quality
Quality Assurance
Quality assurance, or QA for short, refers to a program for the systematic monitoring and evaluation of the various aspects of a project, service, or facility to ensure that standards of quality are being met. It is important to realize also that quality is determined by the program sponsor. QA cannot absolutely guarantee the production of quality products, unfortunately, but makes this more likely. Two key principles characterize QA: "fit for purpose" (the product should be suitable for the intended purpose) and "right first time" (mistakes should be eliminated). QA includes regulation of the quality of raw materials, assemblies, products and components; services related to production; and management, production and inspection processes.

It is important to realize also that quality is determined by the intended users, clients or customers, not by society in general: it is not the same as 'expensive' or 'high quality'. Even goods with low prices can be considered quality items if they meet a market need. QA is more than just testing the quality of aspects of a product, service or facility, it analyzes the quality to make sure it conforms to specific requirements 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 of testing and planning. The team or firm has to comply with previous requirements, implement new requirements and improve the old item. Other than following requirements, the team or firm has to comply with consumers needs.

Quality assurance versus quality control

Quality control emphasizes testing of products to uncover defects, and reporting to management who make the decision to allow or deny the release, whereas quality assurance attempts to improve and stabilize production, and associated processes, to avoid, or at least minimize, issues that led to the defects in the first place.[citation needed]. On applying Quality Assurance in Education the gross purpose of applying quality 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 are treated as one of the overall QA processes Failure testing A valuable process to perform on a whole consumer product is failure testing or stress testing. In mechanical terms this is the operation of a

product until it fails, often under stresses such as increasing vibration, temperature, and humidity. This exposes many unanticipated weaknesses in a product, and the data are used to drive engineering and manufacturing process improvements. Often quite simple changes can dramatically improve product service, such as changing to moldresistant paint or adding lock-washer placement to the training for new assembly personnel. Statistical control Many organizations use statistical process control to bring the organization to Six Sigma levels of quality, in other words, so that the likelihood of an unexpected failure is confined to six standard deviations on the normal distribution. This probability is less than four one-millionths. Items controlled often include clerical tasks such as order-entry as well as conventional manufacturing tasks. Traditional statistical process controls in manufacturing operations usually proceed by randomly sampling and testing a fraction of the output. Variances in critical tolerances are continuously tracked and where necessary corrected before bad parts are produced. Total quality management Invariably, the Quality of output is directly dependent upon that of the participating constituents, some of which are sustainably and effectively controlled while others are [not]. The fluid state spells lack of Quality control, and the process(es) which are properly managed for Quality such that Quality is assured, pertain to Total Quality Management.

Walkthrough
In software engineering, a walkthrough or walk-through is a form of software peer review "in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems".

"Software product" normally refers to some kind of technical document. As indicated by the IEEE definition, this might be a software design document or program source code, but use cases, business process definitions, test case specifications, and a variety of other technical documentation may also be walked through. A walkthrough differs from software technical reviews in its openness of structure and its objective of familiarization. It differs from software inspection in its ability to suggest direct alterations to the product reviewed its lack of a direct focus on training and process improvement, 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 walkthrough and more importantly, who is to be responsible for resolving these issues. Walkthrough Team Composition The optimized size for a walkthrough team is never and nowhere mentioned. The teams members should be selected in the way that will ensure the issues are adequately covered. The size of the team thus depends on the material to be covered and upon the skills and review experience of the potential participants. The people without the knowledge of the system must not be kept in the walkthrough team. The number of participants will be somewhere between three and seven. Specific tasks are allocated to some of the walkthrough team members. 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 god walkthrough 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:

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 during walkthrough. 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, whose functions 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 the walkthrough. 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.

Objectives and participants

In general, a walkthrough has one or two broad objectives: to gain feedback 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 the technical document. Any combination of interested or technically qualified personnel (from within or outside the project) may be included 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 is often 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 structure chart 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 flows between 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 in each transaction. Finally, it calls module OUTPUT-TOTAL to output the sum. COMPUTE-SALE-TOTAL
Sales Total Sales Transaction Sales Transaction Sales Total

READ-SALE-TRANSACTION

ADD-TO-TOTAL

OUTPUT-TOTAL

Fig: Structure Chart

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 in return. 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 of sales transaction is passed from module READ-SALES-TRANSACTION to module COMPUTE-SALES-TOTAL. Module COMPUTE-SALES-TOTAL then passes the value of Sale Transaction to module ADD-TOTOTAL and gets a value of Sales Total in return. The value of Sale 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 OUTPUTTOTAL 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, on the 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-TOTOTAL any number of times Decisions 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

Fig: Procedural Annotations

Structure Charts and Structured Design

Structure charts are developed by a process called structured design. The objective of structured design is to produce structure charts with properties commensurate with good programming practice. A number of properties are used to judge how well structure charts satisfy these objectives. These properties are usually known as module coupling and 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 simple coupling are said to have low coupling. Another goal of structured design is to represent a welldefined system function by one module. When this happens, we have high strength. Structure charts with low coupling and high strength result in greater independence between modules and easier 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 a range 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 describe coupling. 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 statement in 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 is by 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 modules that appear unrelated in a structure chart are coupled through their use of common data.

Control Coupling

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 of information 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 coupled modules. 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 the calling 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 the following 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 sequences by 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 an input 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 undesirable features 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

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 quoted problem 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 in different 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 does not 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 many applications. Two such important constructs are:

Transform-centered structures
Transform-centered structures receive an input which is transformed by a sequence of operations, with each operation being carried out by one module.
MAIN X X A GET-X Y Y X A GET-Y CHANGE-Y V1
COMPUTE-VI

B A

T1 T2 V2 V1 B B C COMPUT - C PUT-C PUT- B C

COMPUTE-B

Input Modules Fig: Transform Structure

Transform Module

Output Modules

The figure above is a transform-centered structure where: The MAIN module calls GET-X module to get input parameter, X. Module GET-X calls GET-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 structures
A 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 systems operations. 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. MAIN

INPUT

Transaction Module 1

Transaction Module 2

Transaction Module 3

Output

Fig: Transaction Centered Structure

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 modeling in computer system design. It describes the system in terms that are useful to computer systems designers in developing computer system specifications. One set of terms comes under the general heading of structured system analysis.

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 world modeling 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 generalizing individual 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 evaluate subject 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 world by 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 for presentations to management and/or project stakeholders, but for actual development you will find that use cases provide 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 described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within 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 represents functionality that is in scope and anything outside the box is not. System boundary boxes are rarely 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 used on any of the UML diagrams, including both use case diagrams and class diagrams. I use

packages only when my diagrams become unwieldy, which generally implies they cannot be printed on a single page, to organize a large diagram into smaller ones. 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 have arrowheads -Any given use case association will have a zero or one arrowhead. The association between Student and Enroll in Seminar (in the version shown in Figure 4) indicates this use case is initially invoked by a student and not by a registrar (the Registrar 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 and the 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 in Seminar 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 request help 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.

Figure 2. Using System boundary boxes to indicate releases.

Figure 3. Applying packages to simplify use case diagrams.

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 vertical direction 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 to extract from static diagrams or specifications. Although UML sequence diagrams are typically used to describe object-oriented software systems, they are also extremely useful as system engineering tools to design system architectures, in business process engineering as process flow diagrams, as message sequence 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 an example sequence diagram here.

Actor Represents an external person or entity that interacts with the system Object 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 be implemented by objects) Separator Represents an interface or boundary between subsystems, components or units (e.g., air interface, Internet, network) Group Groups related header elements into subsystems or components

Sequence Diagram Body Elements

Action Represents an action taken by an actor, object or unit Asynchronous Message Block A block representing a loop or conditional for a particular header element An asynchronous message between header elements

Call Message A call (procedure) message between header elements Create Message A "create" message that creates a header element (represented by lifeline going from dashed to solid pattern) Destroy Element Destroy Message Represents the destruction of a header element

Represents the destruction of a header element as a result of a call from another element

Diagram Link Represents a portion of a diagram being treated as a functional block. Similar to a procedure or function call that abstracts functionality or details not shown at this level. Can optionally be linked to another diagram for elaboration. Represents an "else" block portion of a diagram block

Else Block

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 be anchored relative to a flow element) Message A simple message between header elements Page Break A page break in the diagram Return Message A return message between header elements Scenario Start Start of a scenario (set of alternatives) Scenario Case Start of an alternative or case in a scenario Scenario End State End of a scenario A state change for a header element

Steady State

A steady state in the system

Timer Start Start of a timer for a particular header element Timer Stop Stop of a timer for a particular header element

Timer Expiration

Expiration of a timer for a particular header element

What can be modeled using sequence diagrams?

Sequence diagrams are particularly useful for modeling: Complex interactions between components. Sequence diagrams are often used to design the interactions between components of a system that need to work together to accomplish a task. They are particularly useful when the components are being developed in parallel by different teams (typical in wireless and telephony systems) because they support the design of robust interfaces that cover multiple scenarios and special cases. Use case elaboration. Usage scenarios describe a way the system may be used by its actors. The UML sequence diagram can be used to flesh out the details of one or more use cases by illustrating visually how the system will behave in a particular scenario. The use cases along with their corresponding sequence diagrams describe the expected behavior of the system and form a strong foundation for the development of system architectures with robust interfaces. Distributed & web-based systems. When a system consists of distributed components (such as a client communicating with one or more servers over the Internet), sequence diagrams can be used to document and validate the architecture, interfaces and logic of each of these components for a set of usage scenarios. Complex logic. UML sequence diagrams are often used to model the logic of a complex feature by showing the interactions between the various objects that collaborate to implement each scenario. Modeling multiple scenarios showing different aspects of the feature helps developers take into account special cases during implementation.

State machines. Telecom, wireless and embedded systems make extensive use of state machine based designs where one or more state machines communicate with each other and with external entities to perform their work. For example, each task in the protocol stack of a cellular phone goes through a series of states to perform actions such as setup a call or register with a new base station. Similarly the call processing components of a Mobile Switching Center use state machines to control the registration and transfer of calls to roaming subscribers. Sequence diagrams (or call flows as they are commonly referred to in the telecom and wireless industry) are useful for these types of applications because they can visually depict the messages being exchanged between the components and their associated state transitions.

Benefits of using UML sequence diagrams

These are some of the main benefits of using UML sequence diagrams. 1. Help you discover architectural, interface and logic problems early. Because they allow you to flesh out details before having to implement anything, sequence diagrams are useful tools to find architectural, interface and logic problems early on in the design process.

You can validate your architecture, interfaces, state machine and logic by seeing how the system architecture would handle different basic scenarios and special cases. This is particularly true for systems involving the interaction of components that are being implemented in parallel by different teams. In the cell phone example, each task would typically be implemented by a separate team. Having a set of sequence diagrams describing how the interfaces are actually used and what messages/actions are expected at different times gives each team a consistent and robust implementation plan. You can also document how special cases should be handled across the entire system. The very act of creating the sequence diagrams and making them work with your architecture is valuable because it forces you to think about details such as interfaces, states, message order, assignment of responsibilities, timers/timeouts and special/error cases ahead of time. 2. Collaboration tool. Sequence diagrams are valuable collaboration tools during design meetings because they allow you to discuss the design in concrete terms. You can see the interactions between entities, various proposed state transitions and alternate courses/special cases on paper as you discuss the design. In our experience, having a concrete design proposal during design meetings greatly enhances the productivity of these meetings even if the proposed design has problems. You can narrow down the problems and then make corrections to solve them. The proposal serves as a concrete starting point for the discussion and as a place to capture proposed changes. Sequence diagram editor makes it so easy to edit your sequence diagrams that you could even make the corrections in real time during the meeting and instantly see the result of the changes as you make them. 3. Documentation. Sequence diagrams can be used to document the dynamic view of the system design at various levels of abstraction, which is often difficult to extract from static diagrams or even the complete source code. The diagrams can abstract much of the implementation detail and provide a high level view of system behavior.

The following example demonstrates the use of sequence diagram