Developing a Distance Learning Software Engineering Program
(November 2000)
Ping-Herng Denny Lin, California State University Fullerton
Ehrmann proposes that educators develop effective plans based on an educational goal or outcome, identify an activity that helps to achieve the educational goal, and finally identify the technology used to carry out the activity [Ehr00]. For example, should the educational goal be "to graduate students with exceptionally good skills at working in teams and organizations", then the course design would "provide extensive collaborative learning activities", and the technology would "support online communication, and collaborative problem-solving".
The best strategy encourages interaction among students. Klemm suggests eight ways to get students involved in on-line conferences [Kle98]. These are: a) Require participation; b) Form learning teams; c) Make activity interesting; d) Insist on opinions supported by data and rational discourse; e) Structure the activity; f) Require a "Hand-In Assignment"; g) Know what kind of quality work teacher expects, and get involved to make this happen; h) Use Peer Grading.
University administrators may pressure faculty to enroll as many students as is feasible to optimize the return on investment. However, the return on investment depends on a large variety of issues such as faculty stipends, tuition rates, and number of online courses (see section 2.4.3).
It is not yet feasible to provide real-time interactive video and audio in distance learning, due to prohibitively high bandwidth requirements for a single user. For example, Touch reasoned that for an expected response time of 100 ms, the bandwidth requirement to transmit a 60 KB file for a single user easily exceeds 12 Mbps. [Tou95]
Even with a connection-oriented protocol such as ATM, some European students participating in a Web University project reported dissatisfaction with the jerky and fuzzy video reception and annoying thought interruptions due to small delays in audio transmission. [Owy97]. These students also reported that the camera range used for the presentation limited the presenter's actions.
Enforcing academic honesty has always been an important issue at brick-and-mortar universities; the problem is even more complex when course assignments (deliverables) are submitted over the Internet. Proving that an assignment did in fact originate from a student, and detecting instances of academic dishonesty, require some sophisticated authentication and security measures.
Rational Software has produced a variety of CASE tools that enables team communications, distributed software development, configuration management, and software testing. Implementing these tools in a distance learning class would ensure exposure to industry standard practices. For example, Rational ClearCase is a configuration management CASE tool that manages changes to software source code. ClearCase can detect intentional and non-intentional modifications and accesses to source code produced by team developers. Implemented correctly, this would effectively authenticate authorship of source code, and would detect acts of academic dishonesty.
Teams that mimic real-life software engineering teams can teach the dynamics of working in a distributed team environment. Meetings that use e-mail and net-meeting tools enables team activities in distance learning.
Distributed proctoring enhances interactivity by enabling students to grade another peer's progress, enhancing the level of interactivity. Schneier, Kelsey, and Walker developed a protocol for distributed proctoring that allows a network of graders to grade individual problems solved by a network of test takers. Using anonymous e-mail systems, mutual anonymity of test takers and graders are ensured, while an audit trail is provided in the event of a grading dispute [Skw96].
The protocol is not expected to scale linearly if every student in a class is required to grade every peer, because this results in a fully inter-connected graph of interactions [Lin00]. A solution to this is to distribute grading assignments in a manner that closely resembles the organization chart of the software development team (see section 2.3.3). An example would be for the Project Manager (teacher of the course) to grade work of Change Control Board (CCB) members; each of these members is responsible for grading work of their subordinate teams as represented in the organizational chart.
Week 1: Students are given e-mail assignments to introduce themselves to the rest of the "class", and to post resumes of work experience in the class website. Instructor informs students that based on the experiences and perceived strengths of their peers, the organizational structure of the software development team will be determined.
Week 2: Students vote for the following positions: Project Administrator, Test Specialist, Principal Architect, Configuration Management Lead, Quality Assurance Lead, Design Team Lead, Verification and Validation Lead, Implementation Chief, and coders. Instructor automatically assumes role of Project Manager, gathers votes, assigns positions if any are left unfilled, and announces the software development team via e-mail. Instructor makes documents relevant to the software development effort available on a class web site, and includes requirements documents, design documents, test documents, configuration management documents, source code, change requests, discrepancy reports, and progress report templates; these documents may be generated by students from a previous semester. Starting from week 2, every member in the team turns in a weekly progress report to its leader. Each leader in turn summarizes its team's progress into a document e-mailed to the Project Administrator. The Project Administrator turns in a weekly report to the Project Manager.
Weeks 3 and 4: The software development team is put to work on a specific aspect of the software lifecycle for this project (in this example, the maintenance phase). These weeks are generally a "getting to know the software product" period for most team members. A high volume of interaction is expected as students interact with their "superiors", and those on the Change Control Board (comprised of the Project Administrator, Principal Architect, Test Specialist, and Configuration Manager) will be monitoring activities of the team.
Weeks 4 through 12: The Change Control Board reviews Discrepancy Reports (DR) and Change Requests (CR). When DRs and CRs are approved, these forms are e-mailed to the Design team for changes. Design Team will review and produce designs to execute CRs. Configuration Management is responsible for releasing the source code to implementation team. The implementation team processes a CR by implementing changes to the source code. The Verification and Validation team is responsible for ensuring that the changes meet the requirements defined by the software requirements document.
Every two weeks, software reviews (of software changes) are conducted to discuss changes made to the software product. Students use class chat rooms or NetMeeting to conduct these reviews. Quality Assurance team members ensure that the interchange is conducted according to procedures, and signs off review forms.
Once all changes have satisfied the review process, the Configuration Manager checks in the changed code, and establishes a new baseline. Change Control Board closes all CRs and DRs.
Week 13 through 16: Students work collaboratively to develop the project report which includes all progress report forms, all CR and DR forms, design documents, specification documents, and modified source code. All finished documents are posted on the class web site.
Week 17: 60% of the student's grade in the class is based on their performance during the lab exercises, and the team project report. 40% of the grade is based on an open-book final exam given on this last week.
1) Students, whose primary role is to learn. 2) Faculty, whose roles are to understand the needs of distant students with little first-hand experience and limited face-to-face contact; adapt teaching methods to suit the needs and expectations of multiple and often diverse audiences; develop a working understanding of the delivery technology while remaining focused on teaching; function as facilitator and content provider. 3) Facilitators, whose role is to collect assignments, proctor exams, and help set up equipment; they are the on-site eyes and ears for the teacher, even in situations where the facilitator has little or no content expertise. 4) Support staff, whose role is to ensure that logistics, technical, and administrative details are taken care of; support staff's duties include ordering textbooks, scheduling facilities, securing copyright clearances, and performing student registration. 5) Administrators, whose role it is to maintain an academic focus to ensure that technological resources are effectively deployed to meet the instructional needs of students; administrators go beyond visioning to build consensus within the team, help make decisions, and referee disagreements [Wil95].
1. Academic: Academic calendar, course integrity, transferability, transcripts, evaluation process, admission standards, curriculum approval process, and accreditation.
2. Fiscal: Tuition rate, technology fee, FTE's, consortia contracts, and state fiscal regulations.
3. Geographic: Service Area Regional limitations, local versus out-of-state tuition, and consortia agreements.
4. Governance: Single versus multiple board oversight, staffing, and existing structure versus shadow colleges or enclaves.
5. Labor-Management: Compensation and workload, development incentives, intellectual property, faculty training, and congruence with existing union contracts.
6. Legal: Fair use, copyright, faculty, student and institutional liability.
7. Student Support Services: Advisement, counseling, library access, materials delivery, student training, test proctoring.
A recent study performed at Marshall University produced a web based cost and revenue analysis tool that can project costs and revenues throughout seven years. Users can input variables such as tuition rates, class size, technology fees, and institution-specific information. Morgan claims that the estimates come within 5 percent of real costs [Mor00]. The study suggests that identifying the development and teaching costs, and developing an institutional plan to fund and train faculty and students, are key to a successful distance-learning program.
The cost centers identified are: 1) Technology Specific costs; 2) Support Personnel costs; 3) Faculty Development costs (teacher training); 4) Hidden (office space, increased network traffic, evaluation process) costs; 5) Course development costs; 6) Teaching online costs (faculty stipends) [Mor00].
The following is a sample analysis of return on investment given the following variables: Online courses: 5; Students per class: 13; Faculty stipend per course: $2000 for 4 units; Tuition rate: $250/unit; No technology fee; IT Support available; Server Available; Estimated Growth Rate: 15%.
Faculty recruited to teach distance learning courses need to be capable of structuring and designing courses so that students have a high degree of interactivity.
Class sizes should be determined on the basis of learning outcomes and practical limitations such as network bandwidth and computers available. It is important to optimize the bandwidth available by using the appropriate tools to enable team communications, distribute software development, perform software testing, and ensure configuration management.
Some commercial configuration management tools can enforce academic honesty by authenticating authorship of source code and homework.
A sample distance learning activity plan used for a Software Engineering lab was outlined. The activities are intensely interactive and collaborative in nature; they expose students to the practice of software engineering, and exposes students to team work.
An academic institution that develops and maintains sound software engineering curricula will be poised to meet the demand for competent software engineering professionals. Moreover, such institutions will enjoy the prestige afforded by accreditation bodies.
Key support structures need to be in place, and policies need to be developed. Cost centers need to be identified and funded; decisions about potential sources of revenue need to be made so that the return on investment is worth the effort. A web tool to perform such an analysis was presented, along with a sample return on investment analysis.
[Eis91] M. E. Eisley, "Guidelines for Conducting Instructional Discussions on a Computer Conference", International Symposium on Computer Conferencing, Ohio State University, Columbus, Ohio, 1991.
[Gfe97] B. Gellman-Danley, M. J. Fetzner, "Asking the Really Tough Questions: Policy Issues for Distance Learning".
[Kle98] W. Klemm, "Eight Ways To Get Students More Engaged In On-Line Conferences".
[Lin00] P. D. Lin, "Distributed Proctoring in Distance Education Courses". California State University, Fullerton, November 2000.
[Mor00] B. Morgan, "Is Distance Learning Worth It? Helping to Determine the Costs of Online Courses"
[Owy97] K. Ostonen, H. Wang, S. Yang, "Distance Learning: Analysis of the ATM-Videoconferencing Project at CERN".
[Prt99] I. Pritchard, "Reducing Class Size: What Do We Know?"
[Sch95] L. Schmier, "Random Thoughts. The Humanity of Teaching", Madison, WI: Magna Publications, 1991.
[Sch96] J. G. Schutte, "Virtual Teaching in Higher Education: The New Intellectual Superhighway or Just Another Traffic Jam?"
[Skw96] B. Schneier, J. Kelsey, J. Walker, "Distributed Proctoring", ESORICS 96 Proceedings, Springer-Verlag, P. 172-182, September 1996.
[Tou95] J. D. Touch, "Defining High-Speed Protocols: Five Challenges and an Example That Survives the Challenges".
[Wil95] B. Willis, "Distance Education at a Glance Guide #1" Engineering Outreach, University of Idaho, October 1995.
You are visitor number