Webcast Series

"Providing Student Services to Distance Learners"

Transcript of The Bridging the Communications Gap Between Student Services and IT Staffs Webcast

Slide: WCET presents a Webcast Series: Providing Student Services to Distance Learners

PAT: Hello and welcome to the WCET webcast series, "Providing Student Services to Distance Learners." I am Pat Shea the Assistant Director for WCET and I'm coming to you today from our east coast office in Summit, New Jersey. Also joining us from WCET's headquarters in Boulder, Colorado, is my colleague Sue Armitage. Welcome, Sue.

SUE: Hello Pat, and everybody in the audience. I understand we have about eighty-four people registered for the webcast today and I'm glad to see so many people interested in the subject.

Slide: Bridging the Communications Gap between Student Services and IT Staffs

PAT: Great. Our special guest today is Burnie Blakeley and Burnie's coming to us from North Carolina. Hi, Burnie.

BURNIE: Good afternoon, Pat. I'm very glad to be here.

SUE: Just so we can get an idea about you in the audience, we'd like to ask if you are familiar with this webcast or HorizonLive environment. If you have participated in a webcast before, please go ahead and click the green "Yes" button sort of above my picture there in the bottom right hand corner. So click "Yes" if you have participated in a webcast before. If you have not, please click the "No" button. And that will help us know how much prompting we'll need to do regarding the environment as we go along.

PAT: And during today's session we invite you to make comments related to the presentation in the chat box. Some of you have been involved in projects to re-engineer your services and this is a good opportunity to share your knowledge and experiences with others in the audience here today. I see Mel Chastain is in the audience. Mel has been very involved with us on the LAAP project and with some of the work Burnie's doing. So, we'll be happy to have Mel's comments along the way. If you experience connectivity problems during this presentation, please click on the "Help" button to send an e-mail message to tech-support.

SUE: If you'd like to send a private message to someone that you see is participating in the session, click on the "Tell" icon in that black task bar. Only the person that you have selected will see your message. Otherwise, when you type a message into that "Send a Message" text field, everybody sees it.

I'd also like to mention a quirk of Internet technology. This webcast is not a television program where all the content, both the visuals and the voice, are broadcast in one stream. Instead, our voice and visuals are broken into separate packets that travel the Internet backbone and reassemble on your computer. So, if what you hear and see aren't matched up exactly, please be patient and know that, that is our intention.

Also, because some of the graphics may be small and, therefore, kind of hard to read on your screen, I encourage you to go to our WCET website and print off a set of the slide. You might like to make notes on them as you follow the presentation. I'll put our WCET website URL in the chat box now or else you can actually also see it in that HorizonLive screen at www.wcet.info and right on that page — it's the home page of the WCET site — you can access the PowerPoint slides.

PAT: Great. Thanks Sue. While we're giving the audience just a couple of minutes to do that, I want to mention that "Bridging the Communications Gap between Student Services and IT Staffs" is the tenth in our webcast series on providing student services to distance learners. This series is part of WCET's work on its Learning Anytime Anywhere Partnership Project which has been funded by the US Department of Education. The project involves three partner institutions and a corporate partner in creating web-based student services for online learners.

Do we have some results, Sue, on the number of people who've been involved in this environment before?

SUE: Yeah. It's easy to take a look because in that bottom grey bar you see there's an easy tally. And so we have nine "Yeses" and nine "Nos" and one question mark. So we've got half the people who are familiar with this environment and half who are not.

Slide: WCET: the Cooperative advancing the effective use of technology in higher education

PAT: Okay. So we'll keep that in mind. And for those of you who are not familiar with WCET, I just want to give you a little background. It's a cooperative of higher education institutions, agencies and non-profit organizations and corporations involved in distance learning. And our focus is on advancing the effective use of technology in higher education. You can see some information about us on the screen now and I hope you'll visit our website to learn more.

Slide: Bridging the Gap between Student Services and IT Staffs

And now it's time to tell you a little bit about Burnie Blakeley. Burnie has worked for IBM for thirty-six years. For the last decade or so he's been working with them as a Solution Architect, analyzing, documenting and visually modelling application and infrastructure software for computer systems. He gathers requirements and continues through architecture specifications to the beginnings of the software analysis and design. Welcome, Burnie.

BURNIE: Thanks, Pat. It's always a pleasure to be here with WCET people. I think of the WCET group as, almost my family, by now after about eight years of working with you off and on various virtual university-oriented projects, starting with the Western Governors University, way back in the middle '90's.

PAT: That's right. It's amazing it was that long ago.

BURNIE: That's a long time ago. But for the past three years I've worked real closely with Pat, off and on, again — not steadily but off and on with this LAAP Project. And I have attended and presented at the last several annual meetings and so I know the audience a little bit.

I currently work in the Life Sciences area in IBM in such things as genomics research, personalized medicine, clinical trials and regulatory compliance and all kinds of unusual things I've never seen before. But, at any rate, I always have a keen interest in what's happening and happening in academia.

PAT: Okay. So today, Burnie, we want to present to the audience some of what we and the LAAP members have learned about student services and the IT communities. And how these two groups of mostly unlike professionals can more easily work together. And I want to point out to the audience that Burnie's presentation is the first of six upcoming presentations that are all LAAP Project specific. Some of the ones that are coming up will demonstrate the actual models of student services that have been developed in this project.

BURNIE: Okay. The very first slide shows the title of the presentation. It's "Bridging the Gap between Students Services Staff and IT Staff." And as Pat said, sometimes these are thought to be, and maybe even are, unlike professional groups. They at least have different talents and skills and interests and approaches and everything.

Before we get started, I'd like to point out, and you can barely see it perhaps, at the bottom of the screen, my e-mail address if you'd like to contact me after the presentation is over I'll be glad to do that. It's blakeley@us.ibm.com

Question: What is your area of responsibility?

PAT: Okay. And since those of you that are in the audience are education professionals and representing student services in some cases and perhaps some computer professionals, we'd like to take a quick survey just to find out who's in the audience. Sue I see you've already put a multiple choice question up and we'd like to ask you to respond to that question. What is your area of responsibility primarily? Are you on the student services staff, the IT staff, or other? And if you can click the button that matches your role now, we'll give you just a moment to respond to that question. And while those results are coming in, I'll tell you a little bit more about the LAAP Project. The title of the LAAP Project is Beyond the Administrative Core: Creating Web Based Student Services for Online Learners. And, as I mentioned previously, there are four partners. Kansas State University is a large land grant university with more than twenty thousand students. Kapi'olani Community College has about seven thousand students, and is one of seven community colleges in the University of Hawaii system. Regis University is a private Jesuit institution located in Denver, Colorado and it has about ten thousand enrolments in its School for Professional Studies, which was the target audience for this project. Our corporate partner is SCT. So these schools are very different in their size, their mission and the types of students they serve. In addition, each of them had a different student information system and none of them, at least at the beginning of this project, were using an SCT system. So our big challenge then, was to find a way to help one another through this process of creating services when we had so many factors that were not many commonalities.

There are four deliverables for this three-year project which ends in December. The first is a set of commercial solutions for student services developed by SCT; some home-grown solutions for student services developed by each of the institutional partners; a set of guidelines for other campuses developing student services; and case studies tracking the changes that occur as a result of implementing new web-based services.

Sue, do we have some results of our survey?

Results: What is your area of responsibility?

SUE: We do. I'm going to go ahead and publish them now because it looks like most of the audience has voted. So what we see is this is a nice mix of participants, I think. What we have here are 46% of our audience indicated they're in the student services field; 33% in IT; and 21% in other. So I think that the nice presentation that you and Burnie have put together will probably meet just about everybody's needs.

PAT: Great.

BURNIE: Well, this is an excellent mixture. I was surprised that there is this quite this much mixture. But this is great. So I see that almost half are student services and the other are on the other side of the boundary, sometimes called, in the IT world.

Slide: Topics

So what I'd like to have happen today is, the information that I'm giving you would make it easier for everyone to communicate across these so-called boundaries when they're really not boundaries. So that everyone can communicate with one another and you can get your projects started and get them flowing smoothly and completed on time. And the LAAP team, itself, I'm sure, including Mel, would be glad to share their experiences with you as far as what we're talking about this day.

Because we're limited to just thirty minutes today, we'd like to concentrate on these six topics which are the six that you see on the top of the screen that's labelled Topics. The bottom says, "Further Reading." The top six are what we would like to concentrate upon.

The format for today's presentation will be, largely, a conversation of sorts among myself, Pat and Sue. And we'd like to pass along a lot of information. So we're going to move through a lot of slides very quickly. We will reserve a small amount of time at the end of the hour to entertain a few questions. So please record your questions in the chat box at the bottom of the screen as we go along. And Sue will, perhaps, even intersperse a few of those along the way. But at least we'll have some room reserved at the end for questions.

The six topics for today include two important things: the WHAT and the HOW, that's number two on the list. This is the foundation principle for everything we did in the LAAP project and it's served us very well. It's the most important single suggestion that we should give you today and that you should take away. That is separating the "what do you want to do" from the "how do you want to do it." You'll notice two underlined words: "Scenario" in the middle of the page, and "UML," which stands for Unified Modelling Language — that's at the southeast corner of the slide there. These are very important. Scenarios are basically the kinds of things that education professionals themselves should concentrate upon and are most familiar with. Unified Modelling Language, or UML, is what, some but not all, but many, computer professionals are familiar with. If it's not a Unified Modelling Language it's some sort of picture language very much like UML. So the scenarios record the requirements in ordinary English and the UML re-expresses or transforms the expression of the requirements into a picture language. And we'll explain that as we go through here.

Slide: Diagram: Student Service for Online Learners

So to get started I'd like to recap some of the early days of the LAAP Project — the very first things that we did. The very first steps we were trying to figure out what are student services. What are the services that are being offered to students? And here you see a slide that is the result of our efforts to define student services. The very first thing that we got as a work product was a glossary of terms that were, hopefully, common across the three unlike universities, or the three unlike institutions. So the glossary of terms has a lot of aka — also known as — terms in each of the terms that we did adopt. So you might see one term and three or four alternate versions for the same thing. So this glossary of terms is something that we all worked very hard to put together and it was essentially the foundation to get started.

You'll notice that, on this web, there are five suites of services. In the southeast corner you'll see the Administrative Core and it's separated by the dark lines. The Administrative Core essentially is what most institutions already do have. And everything else that's there listed as the Communications Suite of Services, listed as Academic Services, Personal Services and Student Communities. So those are the way we divided up the services into logical suites.

We at least now could converse among the education professionals in our exercises in the LAAP Project. So from this web icon, we got to the point where we would actually know what the student services were and could speak of them with the right labels.

PAT: And Burnie was our artist here in helping draw this nice graphic. This graphic provided a quick reference to the scope of student services that online learners need. It also recognized, by the dotted lines at the edges, that there may be other services that campuses offer or that services will be added from time to time. It also pointed out that newly designed services should be student-centered. And it called our attention to the need for customizable services personalized for the single student.

BURNIE: This is very important, what Pat just said, that it is student-centered. This is very hard to keep remembering, especially when it's not the students who are doing the specifications of the requirements, but it's the institution. Or, for the most part, institutions. There was, of course, some sampling of student population to get opinions from them about what they needed in the way of services. And this is very important in any requirements-gathering exercise.

Slide: The Professional Communities

BURNIE: Yes, it is often overlooked. So the first thing we did was start in the project with a definite commitment — promise to ourselves of separating out the "what do we want to do" from the "how do we want to do it." If you look in the middle of the slide that's entitled "The Professional Communities," the left side — the left two-thirds, in fact — shows the WHAT and the right third shows the HOW. We promised ourselves to think of what's desirable, not just what exists now but what's desirable to have in the future. That is, we conditioned ourselves to think out of the box a little bit. Well, in fact not just a little bit, we thought out of the box a lot. The left side shows — if you look at the very top — the subject matter "Experts," or SMEs as they're often referred to. And the right side are the computer software experts. Sometimes the left side is referred to as the "Smees" and the right side is the "Geeks." So it's not really a contest between the Smees and the Geeks but sometimes those are the labels that are given to these two groups. The idea is not to make two competitive groups but to make two cooperative and collaborative groups out of the professionals that are involved. So, left side is the WHAT. The right side is the HOW. The left side has to do with, "What are the user requirements?" Because these are the people who know what the user requirements are because they are the users or represent the users. The right side has to do with the applications that are going to satisfy the requirements. So, in the southeast corner you see the application architecture that is either revised by the software experts or invented by the software experts. So the Smees do the requirements and the Geeks do the application architecture, if you want to be very colloquial about it.

PAT: I think one point we want to make here, Burnie, is that the WHAT side of the page is maybe two-thirds of the work and the left one third is dedicated to the HOW. If you know what it is you want to do, it's much easier and much faster to get the how part of the project done.

In the LAAP Project we worked with a variety of subject matter experts on each campus, including academic advisers and counsellors, orientation specialists, registrars and marketing experts. And then, of course, the IT staff in the HOW portion of the project.

Slide: What = Requirements

BURNIE: So what I'd like to do to start is, let's concentrate on the WHAT series. The WHAT series dealing, of course, with the requirements side of the picture that you just saw. The WHAT series is the series that are involved with SMEs, the subject matter experts. The idea is that the WHAT is completed before the HOW begins. And, as Pat said, really, even though we represent it as two-thirds of the time and effort is on the WHAT side, that's the idealistic case. And you have to force yourself to do that. You have to force yourself to have a very elaborate exercise to complete the WHAT before the HOW begins. Because the impulse is to do the HOW. Especially when you're looking at technology and technology-driven things. You've got to use the technology — it's obligatory. The scenarios are an exact and precise way to document what you want to the system to do. And I'll explain that as we go through these slides.

Perhaps a good thing to do now is to just take a poll of the audience, Sue, and find out how many people have been involved on the WHAT side, including the IT people. The WHAT side is specifying the requirements. That is, purposefully specifying WHAT and ignoring the HOW.

SUE: "So what would you like your new academic advising system to be like?," would be an example. Is that right, Burnie?

BURNIE: Yes.

SUE: I think the number we have, we had about 21% of our audience tell us that they are listed in the other category. So they might be in corporations or other types of work environments. So, they too, might have participated in this process of defining the WHAT side. So, if people will go ahead and click on the "yes" button if you have participated in defining the WHAT of a new process. And click "no" if you have not participated in this type of activity before. And if you're not sure, go ahead and click the yellow question mark button. The buttons are above the picture of Burnie in the lower right hand corner.

PAT: Now, I think spending adequate time on the WHAT phase may have been the most important lesson you taught us, Burnie. It's so easy to get caught up talking about solutions with new technologies before you really even understand the problem. It's hard to focus on defining the problem, I think, because it's so nebulous and it really takes a lot of time, as you pointed out, to do it well. There's a lot of pressure on project directors, in particular, I think, to keep everyone motivated and keep everyone focussing on what it is you really want to do. And, as you pointed out too, sometimes there's a lot of pressure to use a particular technology, even if you don't know how to use it or you just feel like, "Well, we've got it so we've got to use it." So I think by ignoring the HOW from the beginning, you're much better likely to end up with a kind of service that you want. And I know that Gary Kleeman's in the audience today and Mel is in the audience — both who were very involved in the WHAT phases of the projects. So they may want to indicate some of their experiences as we move along.

SUE: It's an interesting comment you guys see in the chat box. From the IT perspective, John McLaren says, "I frequently find my clients don't know what they want. It's like, 'I'll know it when I see it, but I don't know right now.'"

PAT: And I think that's probably very true. Burnie, have you had experience with that?

BURNIE: Yes in fact, what often happens that the IT people postulate what could be a need and then the SME side then decides if that makes sense. So it's one of these offer a straw man type statement about what could be required and then it helps shape the opinion of the SMEs. So it's very good to have IT people mixed with SME people from the very start in the WHAT series. Very important.

PAT: Okay, Sue, do we have some results?

SUE: Yeah. Looking down at the tabulation looks like seventeen people have reported that they have participated in defining the WHAT side of the issue. Twelve say "no." And two, are not sure.

BURNIE: So if we look carefully at that it, hopefully, is not the case that the seventeen who have participated are on the SME side and the seventeen who have not are on the IT side. I'd like to think it's more mixed up than that. And that seventeen people who responded "yes" includes both SMEs and IT people. And, likewise, the ones who haven't, that just haven't had the chance to do that.

Slide: Story, Scenario, Use Case

The first thing I'd like to start with in describing scenarios is to give you three terms — "A Story, a Scenario and a Use Case." There's a lot of discussion in the computer world, especially, about the words "scenario" and "use case." And "story" is sort of an all-purpose word. The term "scenario" actually was borrowed from the theater. For example in a play, a scene plays out some type of scenario. And in a collection of all the scenes of the play, and all the acts of the play, complete the entire story of the play. For requirements-gathering and requirements analysis later on, a scenario is really a short duration part of a longer story. Or it's a small scene or a short scene of interactions between users of the system and the system itself, which we will show you in just a few minutes. In general, the shorter the scenario, the more acted it can be and the more exacting it can be.

The LAAP team, for example, used as a guideline nothing that would take more than ten minutes to accomplish between a person and the student services system itself. So that's a very good guideline. It could be just a few minutes or it could be longer but it's at least a short duration so that you can make an exacting description of what has to happen.

The scenario is essentially an SME term and a use case is essentially an IT term. So if you look at the bottom that's essentially IT territory, and the top is SME territory. But the fact is that the use case is a collection of scenarios. Use case is a case of using the system. If you look at the extreme right hand side, the case of using the software functions of an automated system. So every time you use the system, in IT terms, you have a use case. If you're not using an IT system — what we show on the left hand side, the case of using human procedures — that counts as well. So what you're doing on the left hand side is a use case that doesn't involve any computers but it still involves scenarios of various sorts. For example, interactions among people — that's still a scenario. And that's important to document those things as well, because it takes both human procedures and software functions, mixed together, to make something work, especially in academia, as I've certainly seen.

But there's a common belief in the computer domain, that scenarios and use cases are not that well defined, and that is very true. The most common view point is that use cases are a collection of scenarios and the whole collection of all the scenarios make a story of some sort. And what we did with the LAAP Project is to say, that we have a story of a student and what happens during the student's life and what's needed in the way of services. So it's a story of students and the services that they need. And that's essentially how we came up with this collection of scenarios.

PAT: I think that it's often easier, Burnie, for people to maybe write a narrative and then have someone work on chopping that narrative, that story, up into scenarios that can be either told or written in plain English and then put into a template as the scenario as you'll show us, I'm sure, a little later. I think that by using this method of writing scenarios for the processes that we were working on at each of the institutions, that it created a methodology that makes it possible to share the information, the thinking, about what it is you want to accomplish in a service among institutions, even though the technology that you might use to enable that WHAT to happen may be different. But, I'm hoping that we've done on this project will help other institutions with designing their own services.

SUE: Our partners, while working on these new services, focussed on academic advising, orientation to academic advising, excuse me, and tutoring. The scenarios envisioned by these services are on our web site at wcet.info and follow the link to the LAAP Project. So, we hope that if you take a look at this, it might help jump start you and your institution in working on these services.

BURNIE: The idea of a scenario, actually, is very well expressed in a really nice book called The Art of the Long View, which you'll see in the next slide.

Slide:Excerpts on Scenarios: The Art of the Long View

It's a book that is the first item in the list of further reading which is the last slide in our presentation. So you'll see it again and get the ISBN number and so forth, if you're interested. But it's an extremely good book about scenarios. It's entitled The Art of the Long View. First of all it's an art for scenario writing and building. And it's one way to write a scenario is to take the long view, which means to look way into the future. The author, Peter Schwartz, is a world-renown authority on scenarios. Probably the pastor of all the scenario writers and educators. So, if you look way far into the future, you're looking at things like business cycles. If you take short views of things that happen, you're looking at, for example, an ATM transaction. It might take you two minutes to get money out of an ATM machine. So that's a short duration scenario of your executing a cash withdrawal from an ATM machine. A long view would be what happens to a business or even an academic institution over a three-year period. So that's, again, a scenario but a long view of a scenario. So that's the purpose of his book.

There are a lot of excerpts that I have taken out of here. There are many good ones. These are the ones I particularly like. The one I'd like to point out is the one at the top. The second one down that says, "Scenarios are memories of the future." Memories of the future seems to be an oxymoron. And how can you have a memory of the future? But actually a memory is a recording of sorts that you've made in your mind. And so, if you're stepping into the future and recording something, like a memory, then that's really what scenarios are all about. Making recordings of what could and should happen in the future.

The next excerpt I'd like to point is the one that says, "Mutual understanding is the natural result of scenarios." And I think Gary and Mel and all of us discovered that it does help for mutual understanding. The scenarios are written in simple English and they describe a continuum of interactions between the system users — people — and the system itself. Or, in fact, scenarios can be between two human beings. But the ones that we're most interested in, in this project, are scenarios between a human user and, in this case, a student services system.

Slide: From The Art of the Long View continued

So, let's look at a few more excerpts from this very nice book. I've actually read this book about three times and have it highlighted and marked up with magic highlighter pens and read it occasionally over and over. One of my all-time favorites — the best one and the one I like to quote quite often — is the one that's actually three down from the top that says, "Scenario writers train themselves to look at the world as horses do." And you should think in your mind about what a horse sees. Horses cannot see straight ahead they can only see side to side. So as they make progress they have to turn their head from side to side. Humans are sort of the opposite. We look straight ahead and seldom look to the side. So when you're writing scenarios it's nice to think often about looking at the world as horses do — from side to side. And you can see what's in the periphery and what you would, ordinarily, overlook.

Another interesting and helpful excerpt is the one that says, "Storytelling is to arrange facts." And if you look at the way novels are written — historical novels in particular — they really are arranging facts. And storytelling — or writing scenarios is another way to say that — is arranging the facts. The facts about what you would like to happen in the interactions between a user, the human, and the system itself. Now the actors that we're most interest in, of course, are students for these student services.

Slide: Student Life Cycle

And so what we have here shown is entitled at the top "Student Life Cycle." And a student takes many forms as they progress in this student life cycle. They first can be a prospect as you see at the southwest corner. They can be a beginner, a freshman, transfer student and, as they progress through the life cycle, they eventually become alumni of some sort.

So the scenarios do vary about the type of student that is involved. The institutions, by the way — and this is shown across from left to right - they must first attract students. Then they serve students — hopefully well. And then they retain students. Again, hopefully well. So this is the progression that we put together to represent the actors and the different types of a single actor — a student in this case.

PAT: This chart is one we used at K State and I think it was very helpful because by giving students names at different points in their relationship with the institution, it was easy to talk about these people and keep them all straight in everyone's minds. And Gary Kleeman, who's from Arizona State and is in the audience today, worked with us at Kapi'olani, and he used a very interesting approach along the same line in the planning process with Kapi'olani. He asked Mike Tagawa, who is the Project Director, to provide profiles for fictitious, but typical, students at KCC and to assign one to each member of the Vision Team. And we then went through a role-playing exercise for about a two day retreat on students needs across the life cycle of a student's involvement with the institution. And this was a great process in that it levelled the playing field of the staff involved, and helped the team think about how they could work together to respond to student needs. And it forced them to think about designing student services from the student's point of view. And it was a lot of fun too, as people really got into their student's character.

BURNIE: The first thing that we did after we got these cute names assigned to the actors — Ben the Beginner, Pearl the Prospect and so forth — the first thing we did was to build a context diagram.

Slide: Context Diagram

A context diagram is essentially the context within which a system exists and operates. And you'll see in the center of this particular diagram, which has in the very middle, "Academic Advising System," a system boundary. And you'll notice that in the middle, there is no definition. And we purposely, because we were in WHAT series, do not define anything that's inside of the system, because that's the HOW part. So we have an empty box — empty rectangle in this case — with the system boundary and arrows that lead from the actors, who are actually inter-actors, that is entities who interact with the system. And we typically call them actors instead of inter-actors because it's a lot easier to do. So that's how the term "actor" has been applied. In this case, if you look at the bottom, some of the actors aren't really people at all, they're other academic systems. So if you look at the very bottom, at the bottom, you'll see what's shown is a stick figure but it actually represents an entire system. An entire system can interact with the advising system. And that's very vital because it's not only people that have to interact with systems, but systems have to interact with systems. In both cases, traditionally denoted by a stick figure and that stick figure, in this case, is not a person but a system.

PAT: But I think it's important to remember that sometimes it's necessary to interact with systems supporting other services, which you note down there in the little green area, Burnie. Because oftentimes as campuses are structured today there are many different databases representing different student services. For example, it might be helpful to a student to access his financial aid information when he's trying to make an academic advising decision. So, creating an interface that will pool information from both the academic advising system and the financial aid system might be more helpful to the student.

Slide: Scenario/Student Services

BURNIE: Pat used the word interface and that's very important to recognize that interfaces are essentially the way that scenarios are executed. The interfaces live on the system boundary that we saw in the previous rectangle. The edge of the rectangle is the system boundary. There's nothing defined inside. The system boundary has solid interfaces the way you'd get into and out of a system. And the information flowing between the actors and the system has to cross that system boundary through the interfaces. The hardware and software details of what's inside a system will be supplied in the HOW step later on by the IT experts.

The collection could be one interface or, more than likely, it's a collection of interfaces of various types. If you're talking about a web-based interface, it could be one or more interfaces as well. So systems — as you see on the right hand side of the diagram here, labelled "Student Services" — that system actually is supporting the interface and the interface is supporting the scenario. So it's sort of a chain reaction that, first of all, there's the actor who executes the scenario, a series of — in this case — ten exchanges with the system. So the series of ten exchanges constitutes the scenario. The scenario you see in the middle is supported by user interfaces — one or more — that live on the system boundary. And the system itself has to be able to receive one of the arrows and send it back to the actor, essentially. And whatever it takes to complete the sequence, a serial progression through the scenario. So a very common type of scenario would be, as I mentioned earlier, an ATM transaction in which the actor is you and the system is the ATM machine. And what you're doing is push a button at the top, the arrow goes across, the button is red, the system decides what to do with that button. For example, you just entered your account number then it sends back a menu that says, "What do you want to do? Withdraw cash?" or whatever. So there's a little progression that goes back and forth and back and forth in a very dialogue manner between you and the ATM machine. It's the same sort of thing between a student and the Student Services system. Back and forth and back and forth — whoever's using the system.

PAT: I think you have two lessons learned about interfaces in the LAAP Project, Burnie. Sometimes I think an interface fools us because it makes us think putting student services on the web is really simpler than it is. If a student can apply on the web, it may look like the college is automated its admission system reducing the staff workload. But in too many cases, the application process only appears to be automated. The student is filling out the application using the web interface but that data is becoming an e-mail message to staff that must then enter that data into the database and into forms for manual processing. This is because the interface is not integrated with the back end admissions database — something institutions, I know, are working hard to do. But in the interim, the staff workload increases. I think another lesson we learned is that, if the web is going to be the user interface, creating a mock web site can be a very useful way to insure that everyone is thinking about the service in the same way. It doesn't have to work. It just has to appear to work, for discussion purposes so that those people involved on the WHAT team and the HOW team are, for sure, talking about the same thing.

BURNIE: What Pat just said reminds me of some of the towns I've seen — the ghost towns, particularly in the Midwest — where there are a lot of store fronts that are very high, like, two, three stories high, and there's nothing behind them. That's very much like an interface. There may be nothing behind the interface. And this is what happens, of course, in a mock web site or a prototype.

PAT: That's a great example.

BURNIE: So there's lot to the interface but nothing to the support of the interface. But basically the system has to support the interface or interfaces. That's the basic principle for the IT work.

Slide: Happy Scenario

Here, in the next slide, we see what's labelled at the top as a happy scenario. There are really two kinds of scenarios and if you think about an ATM machine, a happy scenario would be when we'd go to get cash from an ATM, you'd get your cash. A sad scenario was, you don't get your cash. For example, it doesn't accept your card. That would be a sad scenario. Or it doesn't accept your PIN number after you've put the card in. Or if it refuses to give you money and you know you have money inside the bank.

PAT: Or it keeps your card.

BURNIE: Or it keeps your card. So, lots of sad scenarios. In fact, what happens is the IT people have to spend more time and effort designing in the support for sad scenarios than they do for happy scenarios. In fact, it's like 70 or 80% of the code is usually for sad scenarios. The happy scenario takes the least amount of effort because everything goes well and there's no extra processing to be involved. That's another story. But here's a simple format for a scenario. And this is the one that we used with the LAAP Project. It's a simple format in the sense that you have everything you need to describe the progression. And in this case there's six steps in the middle going one through six. The exercise is Ben wants to schedule an appointment with his advisor. So, in this case, there's a label at the very top on the first line. There's a label for the scenario and there's a name for the scenario. And a very good way to use a name to adopt the pattern for making a name is to put a noun, verb, noun. Ben is a noun. Schedule's a verb. Appointment is noun. And this is a very systematic and rigorous way to keep yourself in the right vein when you're making scenarios. I know Mel and other people weren't too happy with this particular constriction or restriction. But it did turn out to work quite well for everyone.

The next thing that you have to recognize is every scenario must end somewhere. So it has a single goal of something that has to be accomplished. So you should specify what the goal is for that scenario. It can't go on forever and ever. It has to end. There has to be some definite criterion for the end of the scenario. So there's some pre-conditions — things that exist before the scenario starts. And some post-conditions — hopefully different from the pre-conditions — that are a direct result of the execution of the scenario. And the steps alternate between the actor — if you'll see steps one, three and five — it's something the actor does. And the even numbered steps are something that the system does. In this case it's simple: back and forth and back and forth. So scenario writing is a sampling mechanism, by the way. It's not that you have to write every single possible interchange that you could ever make. Because there are hundreds, or even, thousands of such scenarios. So what we used is the common rule of thumb — the good rule of thumb, in fact — is that you should write scenarios for the most common cases of using the system, or most common scenarios, and the most critical of the user system interactions. Not every one, but the most critical ones and the ones that get used the most often because you want those to work for sure. For example, a couple of dozen scenarios would suffice to define the behaviour of the advising partition of student services. It's a good sample. And it's a sampling mechanism but it works. And you'll find in that anybody who does scenario work, does it on a sampling basis.

PAT: I think this process was particularly successful at Regis, Burnie. The IT staff found it easy to work with and they've actually recommended that others at the university use it to describe new technology-enabled services that they would like to have. Kansas State used it. Developed about forty-five different scenarios that support academic advising. Kapi'olani also used it to work with vendors on services outside the LAAP Project.

BURNIE: Well, that's good and I was very pleased that this did get used and became productive.

Slide: Assumptions, Requirements, Issues

There are some byproducts of scenarios. While you're recording all these details about scenarios there are lots of things that you stumble across: data that you recognize that would be needed to support the scenario; things that you should assume about the scenario; people that you might depend upon, or, even systems that you might depend upon; some dangers; some things that you see that might not work; and, generally, some risk that might be recognized. So one of the habits that we developed right away was, what is commonly called "A-R-I." If you look at the bottom — assumptions, the "A." "R" is the requirements. "I" is at the top. The idea is to have lots and lots of assumptions recorded as byproducts of the scenario writing. And have a small number of issues. Hopefully you can get all those issues to be erased and solved. So the idea is that you should, in the assumptions category, record in a very orderly way — all of the assumptions that you have made. The givens that you are working with and any of the driving forces, reasons that you're doing this scenario. And we'll explain that in just a minute.

The issues are sort of things that get in your way. Things that make it, maybe not possible for the scenario to execute properly. And what is a very good practice is to assign a single person, by name, to each assumption that you record and, likewise, for each issue you record, assign a single person, by name to resolve that issue. And, also, in the assumptions case, you want to validate the assumption and re-validate the assumption. In the case of the issues, you want to solve the issue. If you can't solve it, it becomes a risk of some sort. So scenarios are actually a much better expression of requirements than just a simple list of one-sentence statements of requirements.

PAT: Now, I think it's important to keep a record of these assumptions and issues because they help your project to stay on track. But they are also useful to inform others, who may join the staff later, why you made certain decisions. And an example of an assumption that all the institutions made three years ago, which has certainly turned out to be true, is that distance students and campus-based students would increasingly become one in the same. An issue, for example, at Kansas State was that the students had to register for online courses in the division of continuing ed and pay a separate tuition, even though those students were full-time campus-based students. So the issue became, how could these systems — the campus registration system and the division of continuing ed's registration system — be integrated. And that, of course, raised policy, budget and job responsibility issues.

SUE: Yeah. Sometimes the driving forces may be part of the assumption, such as this project where the partners agreed that students wanted personalized, customizable and just-in-time services. Our project partners went through and created a whole list of these driving forces and assumptions. So if you'd like to see more about what our project partners did, please go to our web site, www.wcet.info, and follow the links to projects in the student services. You can see we have a list of all of those.

BURNIE: Yeah, On the web site that Sue just mentioned, you will see real live examples from this project of all of the things that we've talked about so far. The kinds of things that the subject matter experts have done in the process of recording scenarios and getting them to the point where the scenarios would be useful, not only to themselves, but also to the IT people.

Slide: How = Functions

So, it's about time to talk about the HOW part. Because, by the time you get through recording all the scenarios, you have to decide what is the value of the scenarios. What do you do with those scenarios? So let's go into the How series of our slides and discuss that for a little bit. How do we bridge the WHAT into the HOW? How do we suddenly engage with IT people? And, hopefully the IT people have had the privilege and time to have spent in the SME exercise of building scenarios. If they participate together, it's all the better, because the IT people already know the scenarios and you do not have to explain the scenarios to the IT people. They already know what they are because they participated. But there's not always that luxury.

So there's a fair amount of detail that has been accumulated by the SMEs and we have to decide what happens with the scenarios now. A very good thing to happen with the scenarios is for them to be transformed or translated or converted into a picture language so that it's more evident what must happen. And scenarios essentially define the behavior of the system. What is a system supposed to do? At least from the external view — outside in. What's supposed to be happening? UML, on the other hand, defines a structure of the system. So one is the behavior of the system from an external view; the other is the structure of a system from an internal view — the innards of the system. So the IT staff deals with the innards of the system. So the HOW is, ideally, to be started only after the WHAT ends. But that can never always be the case. But what we want to be sure is we don't put too much emphasis upon technology too early. And, in fact, we should purposefully never talk about technology during the WHAT series.

PAT: And, although I think, Burnie, we show these as discreet phases, you've pointed out that we should have some members of the team in the WHAT phase being IT people. And, clearly, we need members of the WHAT team being involved in the HOW phase of the project so that there is some transition. But, also, there will be a need for additional information and additional clarification as the HOW team begins to try to create the solutions that will support the vision of the WHAT team.

Slide: Modelling "Picture" Language

BURNIE: Okay, that's good. That's very good to have WHAT team members on the HOW series of events and HOW people on the other team, the other exercise. Cross the teams and the exercises so that you mix it up. Once you do get to the point where you have scenarios which educators are familiar with, or in this particular diagram, you see that the left side shows the education community who are speaking one language — educator-ese. Software community's tending to speak in a strange language — computer-ese. And almost ne'er the twain shall meet, except that scenarios and UML help to bridge that gap between the two. And that's the purpose of this afternoon's discussion. So in the next few slides, which I'll go through rather quickly, I'd like to show you what typically happens with scenarios as they are transformed into UML show you some examples of UML. And in the further reading list, there are some very good books — one in particular that happens to be with the Rational Rose tool, that has an education example. It's a very good book to go through and you can look at that a little bit later.

Slide: Actual UML for Scenarios Model

So, in this case, we're looking at scenarios being translated into UML. The pictures summarize the scenarios — that is, the behavior of the system. And they actually expand on the behavior of the system to postulate the structure of the system itself, internally. Now here we see a scenario model — an actual UML. It's all picture language with ovals, straight lines, stick figures and so forth that are the common tools of UML. That's the characters of the picture language. So a collection of scenarios that are related together are called a scenario model. And the scenario model itself helps to put together what scenarios are related to each other and what actors are, hence, related to each other. And I should also say that the collection of all the scenarios that you write — say, you've written sixty, which hopefully you aren't writing any more than that — would represent what the entire system does. So you might have a series of models. Not just one model but a series of scenario models that constitute what a system is supposed to do.

Slide: Actual UML for Interaction Diagram

So now that you know that the IT persons can see what scenarios are, then it's time to postulate the internal structure of the system and decide how can the system, itself, support the scenarios through the interfaces. So the structure and behavior which are two object-oriented terms, which all the IT people would recognize, are actually used to determine what could be the structure of the inside of the system. You'll see on this slide here which is entitled, "Actual UML for Interaction Diagram" some more of the picture symbols there introduced. There are arrows that go straight across or backward. They're dotted or solid. There are rectangles at the top that represent essentially chunks of code that are inside of the system, according to the definition of the IT person. And the structuring consists of the messages received from the actor, or the information that's received from the actor into the first chunk of code. The first chunk of code sends the information to a second chunk, which sends it to a third chunk. For example, a database retrieval that sends it back to a second chunk, who sends it back to the first chunk which happens to be, for example, a web interface. A code that supports a web interface sends you a response back over the web. So this structuring of the system is what the IT people spend their time doing and what they really enjoy doing. Having come from the IT world, I know that, that's a fun thing to do.

PAT: So we really have a lot to think about. And I'm sure the more specific, again, people are in the WHAT phase, the easier it will be for them to get it right as they have to move through all of these different structures.

Slide: Push and Pull Models

BURNIE: That's very true. A system — and by the way, we should say — a system supports the scenarios through the interfaces. And the education users see only the interfaces. They rarely ever see the system. Now we have something labelled "Push and Pull." And this is related to push and pull models. Institutions pushing information to the students, or, more traditionally in the past, students had to go to the institution and pull information out of the institution's files. The obligation was on the students to pull rather than on the institution to push. So these are some observations and conclusions that the IT staff can make. And in looking over the entire collection of scenarios, the IT staff usually are perceptive enough to detect some work flow patterns, so-called work flow patterns. So the scenarios have been built by the SMEs and the UML has been built by the SMEs and the IT people together because the IT people want to be sure that they transform the scenarios into UML language in the proper way. But eventually a system will be architected by the IT people and, of course, by the users as well. And designed in an integrated manner to make each and every scenario possible.

Slide: Student Services for Online Learners

So now we come back to the story that we started with. We now have a web of all of the services and we have scenarios to support some of those services. In the LAAP Project we actually were able to take three of the services that are shown on this web and to write scenarios for those. And Pat identified those earlier.

PAT: Right. It was academic advising, orientation in academic advising and tutoring. So we still have quite a bit to do at these different institutions.

Slide: Further Reading

BURNIE: Okay. Let's go to the page we've covered a lot of territory here but on the last page you'll see that the very first reference is The Art of the Long View — art of the scenario and the long view of the scenario. I'd recommend that book for sure. The last one is an article that Pat and I wrote together for the SCUP which you can find at scup.org. It's an article very much like what you heard and saw today. Everything in between has to do with use cases, scenarios, converting scenarios into UML and using UML itself. So this is a good variety for both the IT people and the SME people. And remember, you can always contact me at the address that's on the first page if you have more comments to make or want more discussion. I'll be glad to do that.

Slide: This series is brought to you as part of WCET's work on its Learning Anytime Anywhere Partnership Project

PAT: Burnie, on behalf of WCET and all of our attendees today, I really want to tell you how much we appreciate your help. Not just today but, throughout this three-year project in helping us communicate among one another and, even among institutions. I'm sure the audience also enjoyed learning a little bit about scenario writing and UML and I encourage them to visit our web site where they can get more information.

BURNIE: Thanks, Pat. I've always enjoyed being associated with the LAAP Project. All the people are very nice and the work is very interesting. I think technology — and scenarios and UML included — have a great potential in all of these areas of higher education. So I hope that everybody today has benefited from this information and we didn't have a lot of discussion between ourselves but at least I hope we can participate in that in the near future by e-mails.

Slide: WCET - LAAP web site

SUE: Well, I want to let everybody know that I am launching our LAAP web site that I've thought so much about today. I'm launching it now in a new browser window. And I would encourage you to go ahead and bookmark it for further exploration. There you can access all the information about our project. And you can check into the Project Partners section of the web site to find out, individually, how they use scenario building and UML and I hope it's helpful. You can also check out all the webcasts to review our archive and our upcoming presentations.

This webcast was recorded and probably will be available in a day or two for review and be there, approximately, for one year. Now once you've book marked this site, please minimize or close it out while I return your attention to the webcast window. We have a few more things to show you.

PAT: Thanks, Sue. The next webcast will be on Wednesday, August 21, with Mike Tagawa who is the Project Director at Kapi'olani Community College. And he will be demonstrating his learning support services that they have built during this project. Some of you may have participated in the May webcast when Mike talked about the thinking behind the design. And now you have to opportunity to see how that thinking plays out.

Slide: WCET Evaluation

I'd also like to ask you to take just a moment to provide us some feedback about today's presentation. If you would like to pose a question to Burnie in the chat room you can do that. We'll be here for just maybe another minute or two. So, if you fill out the evaluation first, we'd appreciate that very much. I think Sue has it on the screen. And I see it now. You have to minimize the LAAP web site screen in order to see the evaluation.

SUE: And while people are filling out the evaluation, Burnie and Pat, I can sort of recap some questions that were in the chat box earlier. And let's start with a question about a program — some software — for creating UMLs, to create those cute little stick figures and all that. Is there some software that people can use?

BURNIE: Yeah, there's a lot of software. I would recommend the Visio product. It's very easy to use. It comes from Microsoft. It's a graphics tool. It comes in various varieties. I'd recommend the professional edition of Visio. Rational Rose, which is a much more expensive and a much more sophisticated tool — graphics tool — that actually deals with not only creating UML but transforming the UML statements into real code. So you can start with Microsoft Visio and there'll be three editions — a standard version, a professional version and then there's an enterprise edition. And you can look at the descriptions. But I would recommend, if you just want to play around with it a little bit, then the standard edition is fine. If you really want to get serious about it try the professional edition of Microsoft Visio. If you really want to — and you're an IT person — want to get into the transformation of UML, from scenarios to UML to actual code, then I'd go with the Rational Rose product. Or some other similar product.

SUE: Good. And we had a question, early on, about applying this kind of technology to K-12 education. Makes me think of the question in reverse. Is there any scenario you can consider, Burnie, that this type of process would not apply to? Would it apply to just about anything you can possibly think of?

BURNIE: Scenario writing has been applied to not only computerized systems but non-computerized systems. It even has been applied to social interactions, like by sociologists. So the actual scenario process is sort of a universal tool that anybody can use. It doesn't have to even involve computers. And the specific question: I think that there are no cases where some scenario — depending on how you wrote it and how long it was — you don't want to write it too long because it becomes less useful. You want a short duration scenario.

PAT: Sue, do you have one last question?

SUE: I think those the most important. I think we had a question about whether scenarios are cumulative. I think the answer is yes. You demonstrated how that worked. But I just think this was a terrific presentation, Burnie, and I thank you very much.

Slide: Thank you for joining us

BURNIE: Thanks to all of you. And I hope it has been of value to everyone and please contact me if you wish.

PAT: I think, in terms of a cumulative one, I just would encourage whoever asks that question to go look at the Kansas State ones on our web site because it's a good example of that.

So, thank you, Sue. And thank you, Burnie. We appreciate this very much. And we'll meet again on the 21st of August for a discussion about Kapi'olani's project.

BURNIE: Good bye. Thank you.