This project is due on Wednesday, February 3, at 10 PM, including all source code files, documentation, and the final ProjectPlan/SRS/SDS. Follow the submission instructions. Groups will present a preliminary overview of their ProjectPlan/SRS/SDS in class on January 14.
IVR (interactive voice response) and touch-tone phone "tree" systems used by an increasing number of companies often make it difficult for a person to call a store or company and talk to a real human being who works at that establishment. The systems often require a caller to spend a long time listening to slow voice prompts (“Press or say ‘1’ for store hours, press or say ‘2’ for the store location...,”) just to ask a simple question such as “When will you close on New Year’s Eve?” or “Is that train usually on time”, often a question that is not easily answered by the voice prompt system.
IVR systems are arguably dehumanizing and insulting in that they imply that the caller’s time is less important than that of the person being called, and that the caller is, at least for a long initial screening process, only worthy of talking to a computer, and not to a real person. One bypass that is sometimes installed to let callers to get to a real person more easily is to permit the caller to just press “0” or say “agent.” Quite often, though, such bypasses are specifically not made available. Sometimes, pressing “0” restarts the entire voice prompt menu system back at the very start, effectively training its customers to not try to talk to a real person, presumably generating more profits for the company while lessening the customer’s experience. The systems are an example of computers being used to degrade a human experience.
The solution is to use the power of computers to combat the power of computers. The same way that IVR systems are used to prevent a customer from getting to a human, an anti-IVR system could be used by a customer to get through an IVR system to a real human being. The anti-IVR system would run on a laptop, desktop, or smart phone; call a company; navigate through the IVR or phone tree system; respond to prompts as needed, all internally to the computer or phone and silently to the customer, up until the point that the system reached a real human; and then the system would come alive and connect the customer to the company’s representative who picked up the phone
A super intelligent anti-IVR system could navigate through multiple menus and phone trees, listening to prompts, parsing phrases, and providing responses as needed. A less sophisticated system could be periodically trained up on the most recent sets of prompts for each company’s phone tree (stored in a database of voice prompts). A base-level preliminary system might simply be turned on by the user at any point that the user is on a phone call and put on hold; the system would just prompt, over and over, with “Hello? Are you a real person?” <pause> “Are you really there, yes or no?” <pause> and wait until the system parses a good “yes” in one of the pauses before alerting the user.
The basic system requirements are as follows. Note that functional and non-functional requirements are mixed together here.
1. The user can make a phone call (such as to a landline) using the system as if it were just phone, to just call and talk to whomever or whatever system picks up the phone on the other end. [Skype can be used to call land lines if you create an account and add a small amount of money to the account.]
2. The user, such as if put on hold, can switch the phone into a prompting mode that runs a loop that prompts the called party with a pre-recorded question or message. The message should be prerecorded in a sound file using a common file format such as gsm (used by the Asterisk IVR system), mp3, wav, or aif. If compression is used, it should be a common compression algorithm.
3. The system will repeatedly play that prompt message, pausing afterwards for a fixed amount of time, listening for and recording the response of the party called. The user can mute and unmute this back and forth dialog as is proceeds.
4. The called party’s response to each prompt will be analyzed within a fixed amount of time (that will not exceed the duration of the response recording, plus one second). First-level analysis (required) will include determining if a particular touch tone was played. Second-level analysis (optional) will count the number of discrete words or sounds that were played, so that the system could potentially determine simply if a single word was uttered. Third-level analysis (optional) will use voice recognition to determine the words that were spoken.
5. The response analysis will decide if a person is on the other line. If it decides “no,” it will continue looping until one of the following occurs: (a) a preset amount of time has elapsed, (b) the call is disconnected, such as by the other party, or (c) the user terminates the call, such as with a “hang up” button.
6. An audio recording of every phone call will be saved, starting from the moment that the other party picks up or, if the system is invoked by the user switching over to the system, as soon as the switchover is made. As soon as this recording starts, the A-IVR system will state “Your call may be recorded for quality purposes” (taken from the United Airlines reservation IVR system). It seems appropriate to have this stated up front so that the party you are calling has the option of hanging up if they do not want their phone call to be recorded. (It would also seem useful to record the entire phone conversation in the event that the other party gives up-front permission for the A-IVR system to record the conversation, as seems implied by a statement such as “Your call may be recorded for quality purposes.”)
7. All remote party responses, and the results of the analysis of each response, will be saved to disk in a unique, separate file that is not to be overwritten in subsequent runs. (This will help with system validation and verification.) [The obvious technical solution here is to date and timestamp (including seconds) each recording, and to put these all into a separate subdirectory, perhaps with a new subdirectory created for each phone call.]
8. The system events and system decisions of every phone call will be saved, including with a timestamp of what occurred at what time, such that each system event can be lined up with what was happening in the audio recording of the phone call at that time. For example, if the system decides that a particular called-party response results in a decision that “yes” a human is on the line, it should be possible to link that decision with the sound file used to make that decision.
9. When the system determines that a human being is on the other end, a visual and audio alert is played, and the user’s system immediately goes into a mode in which the user can talk with the called party, regardless of whether the sound was muted during the ‘are you a human’ prompting.
10. The user can modify the pre-recorded on-hold prompt, such as by replacing a sound file in the operating system. Though the A-IVR system does not need to provide any facilities for creating such files.
11. Installation instructions should be provided, along with all source code and instructions for compilation, that could be followed by a computer programmer with an undergraduate degree in computer science, and used to install the system on a “fresh” machine within 30 minutes. No assistance should be necessary from a member of the project team to install the software.
12. A task-based “Quickstart” document should be provided that uses screenshots and examples to walk the user through the common tasks that the system would be used to accomplish. On a computer where the system is installed and started up, a user who is sufficiently technology savvy to use email and make web purchases but has no special training in computer science, should be able to study the quickstart and use the system to: (a) Call a company, (b) have the system prompt the called party with the ‘Are you a real person?’ prompt, (c) put the system into silent mode, (d) talk to the called party when a person finally picks up the phone, and (e) explain to someone else what the system is doing (in terms of the basic functionality, not the deeper explanation of signal processing and such).
CVS--concurrent versions system--and SVN--Subversion--are useful programming tools for sharing files among group members. They may useful to you in your development. CVS and SVN are already loaded on the departmental Unix machines. Macintosh and Windows freeware versions are available for CVS, and probably for SVN as well. For CVS, you will still need to use the Unix version for some functions, such as removing files from the repository.
You must assign responsibilities to team members. It is not a good strategy to simply share all responsibilities. Although all team members should contribute to some extent to every aspect of the project, and everyone should do at least some programming, it is essential to have one person with central responsibility for each major part of the task. Among the responsibilities to be assigned include:
The mapping of people to roles is not necessarily one-to-one. For example, it is common in small teams for the user documentation and user interface roles to be combined. You may wish to identify additional roles. You may also want to spell out responsibilities more clearly, e.g., shall the user documentation or technical documentation person be in charge of the final presentation?
The person with ultimate responsibility for one of these functions does not have to do the whole job alone. For example, the system architect does not design the whole system alone, and the product build manager does not do all the implementation; they are managers of different aspects of the project.
Risk control is an important part of project management. One of the largest risks to any software project is the loss of a key person. Therefore, while it is important that a single person be ultimately responsible for each role, it is a very good idea to assign a "backup" for each role also. The backup person assigns the main person responsible for a role, and should be knowledgeable enough about that role to take over responsibility if the primary person is lost or unable to fulfill his responsibility. The backup role is also an opportunity for "cross-training" in preparation to take a lead role in a later project.
The SRS is the Software Requirements Specification. The SDS is the Software Design Specification. The Mini Project Plan / SRS / SDS document is a small combination of elements that might appear in several different documents in a larger project: A proposal, a feasibility study, a project plan, a requirements statement, a specification and/or external design, and an architectural design overview. This document should convince management, a client, or an investor that this project is worth funding. The quality and content of the document will communicate the likelihood of success of the project if it were to be approved.
Your Mini Project Plan / SRS / SDS should include at least the following:
The group should keep a record of meetings. This record should briefly note the agenda of the meeting, the date and time, who showed up (and who showed up on time), and what was accomplished during the meeting. Set ending times for meetings to help you get through the agenda items.
The group should also keep a record of each of the tasks that are assigned to each group member. This should be in the form of a spreadsheet or table with the following columns: The task, assigned to whom, when assigned, when due, when completed, who did it, who signed off on it.
The cheapest, most dependable and least risky software components are those you don't build. You can find test case management, automation frameworks, and other nifty things freely available on the web. I strongly suggest you take advantage of them. On the other hand, you must do so in a way that is legal and ethical, and while I won't set an upper bound on how much of your project code can be reused, you must certainly provide some "value added" and not merely repackage software available elsewhere.
You may not, however, consult with students or re-use code written for previous 422/522s.
To be legal, you must obey all copyright restrictions in software you use. Beware that a document or file need not contain an explicit copyright statement to be protected by copyright law; you have a right to copy or reuse something only if the author has specifically granted you that right. I am absolutely firm on this, and will not hesitate to fail an individual or a whole team for unethical conduct as regards intellectual property. If you have any questions about what you may or may not do, ask me.
Your product must be freely distributable under the Gnu copyleft agreement. In some cases this may mean that you cannot make use of some software which is otherwise perfect. In other cases it may mean that your product will depend on other software packages that you cannot directly distribute. (Be careful of such dependencies, especially on commercial software, as they can make your product more difficult to install and use.)
To be ethical, you must clearly document the original source of all software and other documents. Every source file must contain header comments clearly identifying its author(s). Derivative work (e.g., code written by you but adapted from a book) must clearly cite each source used in its creation. Falsely identifying yourself as the author of something that is someone else's work, or failing to properly cite a reference on which you based part of your work, is plagiarism and will be dealt with very severely.
It is entirely possible to follow these guidelines, making only legal and ethical use of other people's work, and still to avoid a lot of design and coding that would be required if you built this project "from scratch." Sometimes you will find that, even if you cannot directly reuse code (e.g., because it is written in a different programming language), you can still reuse design. You should properly cite the sources of reused design as well as reused code.
Following the lead of professor Michal Young, who wrote the remainder of this paragraph, I strongly prefer projects provided under an OSI-approved open source license, generally either GPL (which does not allow commercial reuse) or Berkeley (which does). You must in any case use a license consistent with software components you incorporate (so, e.g., a project that uses GPL components must itself be licensed under the GPL). If you have strong reasons for not wishing to use an open source license, please discuss it with me within the first two weeks of class.
Week 1
Before you are assigned your team, start working on the project on your own. Design work and brainstorms are usually more productive if group members first do some thinking on their own, without the inertia of groupthink to pull everyone down one or two paths. Work on the issues that will be in your product concept document due at the end of week 2. Browse the web looking for products (freeware, shareware, and commercial) that do something related to automated testing. What is the competition? Are there "market niches" for your product? Look also for useful components that you can reuse.
Week 2
You are going to need at least a couple of intense team meetings to agree on your product concept, in addition to more individual research. Think seriously about the feasibility issues: How is your team going to divide up the work and tackle the problems? Produce the product concept document and present it to the class on Friday.
Week 3
Delivery is less than two weeks away, and deadlines that looked easy before are starting to get scary. Don't panic. Do make a plan that includes early production of a running prototype (no matter how lame, it just needs to work) and frequent revisions. Make contingency plans for the failure of anything that isn't already running. You really, really want a running prototype so that you are ready to discuss any remaining problems.
Week 4
It's crunch time. You're on a daily build-and-smoke schedule now. You have an agreed meeting time each day for putting together everyone's pieces and testing the current system version. The build-master is sweating bullets, but she has it under control so that, if it all blows up on due date, the build from the previous day is still good to go. You schedule intense reviews of documents and outstanding design issues. On the due date you declare victory and turn in your project.
Week 5
There's still one more chore. You need to present and/or demonstrate your project in class. You will also participate in the class discussion. How did your approach to the project differ from that of other groups? Did you encounter some of the same problems? What seemed to work, and what didn't?
The guidance at the end of the project is provided in part by Dr. Michal Young.