CASAS: engineering software applications

CASAS: engineering software applications J Comer, T Nute and D Rodjak

('A S'A S is' a gem'ric computer-aided .slmh'nt adl'ising U'.stem that ira, de velolwd as a l ll'o-,',('lllCsl('r S(!]I II'(/r(' Cllgi l lwcri l fg pro/ect./br IIIIOWrt(rHJItHIU COIIIlHIIWI'-Yci('II('(' Ill((/or.s ~llld ,qZr¢ldllLiIu SllldCIllS enr,dh,d in the Maste#".s 0 / Solhrare Design and Development ( k l S D D ) iwogram at fuxas Christian U#fiver.vilv. The pmTose O! ( ' A S A S i.s to ax.sist college and university .[acuhy wilh it.s .s l l ld( ' l l l advising re.~ponxihilities. T h e pr({/('cl #Ha#ldg~'#llW#11 e.vper- iun~'ev gaim'd in co#ldttcli#l£, tile com'.~e during the 19X8 89 and

/9k,9 90 aca~h'mic vear.s am' described.

,w*/ , warn, en<Wm'erinj,,. /?rojccl tltdllag('mc#tl. .sQ/}'lt'd/'c c##gim'erin.k,

cdt~calio##

In recognition of industry's need for skilled software designers, Texas Christian University (TCU), in the Autumn of 1978, instituted a graduate degree in software ens,,ineering. Students accepted into this program l-ntist bc practising software professionals in that they are required to have a minimum of two years" industrial experience before admission. The intention of the pro- gr~ml is to examine prewllent software engineering prac- tices and methodologies that might be useful for further- inf the development, management, and maintenance of rehable systems software. Students are required to com- plete 12 courses (36 semester hours) to qualify for gra- duation ~. Of these, se~en courses serve as either pre- or co-requisites to a six-hour, two-semester software engi- ncuring project course that is intended to serve as a capstone lk)r students enrolled in the program ~. Tile pr~tject course requires that students work on an assigned prttiect under constraints closely paralleling those exist- ine in industry.

fh i s paper describes the project managenlent exper- ie~lces gained by supervising the course l\-w the last two tic: demic years. Inchided is a discussion of the assigned pr~,ject, a description of the team composition and pr~.ject lnanagenlent philosophy used in the course, les- sot~s learned, and recomlnendations for instructors who mi/ht be interested in organizing similar protects.

PROJECT IMPLEMENTATION COURSE

Current philosophy would indicate that a software engi- nec ring experience component is a critical element of any soltware engineering curriculum'. As such, from 1978 to 19Y, 1, TCU's Master's of Software Design and Develop-

('ol lpuicr Science I)epartmcnl, [ 'cxas ( 'hrisiian Univcrsilv. Fort W~wih, TX 76129, [ISA

ment (MSDD) curriculum required the completion of a single three-semester-hour project course as part of the overall 36-hour program requirement. This requirement was modified in 1981 when the curriculum was examined and revised to include courses that would provide a more thorough foundation in the technical aspects of software engineering. Many of the existing management-oriented courses were combined in tin effort to reduce the overlap existing from one course to another. These basic changes were intended to accomplish a balance between the tech- nical and management components of the program.

As a result of this revision, several new course subjects were considered and many were subsequently integrated into the curriculum m tin effort to introduce new soft- ware engineering topics. Courses were designed in such areas as software metrics, databases, Ada language, computer architecture, and security and privacy. Also included was the study of the various automated tools related to the software development life-cycle. During this revision, it was determined that the project imple- mentation course should be expanded in an effort to offer a laboratory experience that would encompass the complete software development life-cycle. As a result, the scope of the project course was broadened to encompass a two-semester course sequence (SoDe 7113 and SoDe 7123).

In the present curricuhim. Software hnplementation Project I (SoDe 7113) and Software Implementation Project II (Sol)e 7123) constitute a contiguous two- semester course sequence that attempts to apply the tech- niques of modern software development to actual problem sohitions. Students who enrol in these courses tire expected to participate in a team project and are required to use sound software engineering practices as taught throughout tile curriculum. The goal is to provide g,-aduating students with a development experience that attempts to combine many of the technical, managerial, and communication techniques that may be collectively applied to tile development of a software product.

A similar course, albeit much more limited in scope, is required of all undergraduate computer-science majors. This coursc , Senior Design Project (CoSc 4993), is a single-semester, three-credit-hour course encompassing many of the same goals as SoDe 7113 and SoDe 7123. Undergraduates typically enrol in CoSc 4993 during thcir senior year and have historically worked on indivi- dual projects. Projects are scaled to afford each student a realistic chance of completion, while at the same time requiring that they use sound software engineering tech- niques in their solution.

vo133no6july,august 1991 0950 5849z91/060443 08 ( 1991 Buttcrworth Hcinenmnn Ltd 443

CASAS PROJECT

CASAS (Computer Aided Student Advising System) was originally conceived as an undergraduate software engi- neering project for computer-science students enrolled at the University of Texas at Arlington (UTA). The original project, titled CESAR (COllege of Engineering Student AdvisoR) was developed as a tool to assist faculty members with their advising duties in the development of undergraduate degree plans. This early effort was deve- loped especially for the College of Engineering at UTA and, as such, had little application in other colleges or at other universities 4. CASAS evolved as an effort to inte- grate a 'real-world' software engineering experience into the SoDe 7113/7123 course sequence in an attempt to develop a generic advising system that would have wide application at any university.

The purpose of CASAS is to provide computer assist- ance to any college or university faculty member who is involved in advising students. This is accomplished by providing a faculty member with online access to infor- mation about degree requirements and student records, and by automating the checking of a student's progress against those requirements. Such assistance would reduce the need to refer to hard-copy documents, such as catalogues, schedules, and student files, thus reducing much of the overhead required to advise a student. In addition, the number of errors that arise in advising students could be substantially reduced.

As specified by its requirements document ~, CASAS includes features to determine whether a given student is making the expected progress towards a specific degree. In addition, courses and other requirements that are needed for a degree are identified along with those requirements that have been accomplished and those that remain to be completed. Course prerequisites are examined, GPA requirements verified, residency require- ments and time limits on course work confirmed, and nontraditional degree requirements such as professional program admission or certification checked. CASAS also provides a mechanism to handle exceptional cases such as transfer of credit, waivers, and substitutions for required courses. All of this information may be viewed from the computer's terminal or printed reports may be generated.

As mentioned, the requirements specification further states that CASAS be general enough to work in a wide variety of different academic environments with widely varying degree requirements. This requirement has been accommodated by designing CASAS as a data-driven system. As CASAS functions as a standalone system, it is the responsibility of the user to establish and maintain the data; however, CASAS must provide the means for the creation and updating of any necessary databases. Furthermore, the safeguarding of all data is the responsi- bility of the system user and is, consequently, not provided for within CASAS.

In addressing the hardware environment, the specifi- cation states that the system must be implemented and executed on an Apple Macintosh computer with a mini-

~ j ] SAS-Reouest S ~ Student-lnfo

"~ Advisement-lnfo .ib j ADVI5

De~lree-Plan

Student-lnf 9 l STUDENT FILE

!~. Subst-lnfo SUBSTITUTION FILE

. Catalog-lnfo ~r CATALOG FILE

Figure 1. Top-level CASAS data[tow design as produced by Anatool

mum of one megabyte of random access memory, a hard disc, and a Macintosh compatible printer. In addition, the system should execute as close to real time as the hardware will allow, with 80 per cent of the non-output- oriented transactions being able to complete within three seconds of the transaction request. CASAS must be cap- able of meeting all specified performance requirements with a student database of at least 10 000 students and a courses database of at least 1000 courses. Finally, it was agreed that CASAS must be capable of generating several different reports - - either for an individual stu- dent or summaries for sets of students, with the user having a limited ability to tailor the format and content of these various reports.

DEVELOPMENT ENVIRONMENT

The family of Apple Macintosh computers is well known for its ease of use and consistent interface ~' s. With this in mind, it was specified that CASAS provide a similar user interface with an online help capability and extensive error checking. In satisfying this goal, it was further determined that the system would be constructed using THINK's Lightspeed Pascal L~ and would conform to the standard Macintosh interface using menus, windows, dialog boxes, and mouse actions m.

In addition to TH IN K Pascal, a variety of other soft- ware design and development tools was provided to the students for use during the project. Included among these were:

• Design - - Anatool ~t, an Apple Macintosh-based computer-aided software engineering (CASE) tool developed by Advanced Logical Software. Anatool is a dataflow design tool that supports the Gane and Sardon dataflow design technique. It differs from the Yourdon and DeMarco methodology primarily in its design of symbols and consistency-checking rules. The software serves as a reasonable project decomposition tool and provides a convenient method of automating the development of a corresponding data dictionary. Figure 1 shows the top-level CASAS design as pro- duced by Anatool.

• Prototyping - - Prototypeff 2, a software design tool available from SmethersBarnes. This tool provides a convenient mechanism for automating the design of the Macintosh interface, including menu bars, dialog

444 information and software technology

Student Name: Smith, fl.B. Student I0 :456-23-7654

12204 Huntington Beach Blvd, Apt 9--'J~r'9876 Address:

Major:

Catalog:

Telephone:

SAT Verbal:

SAr Quant.:

Wichita KS 66666 SOOE-Software Design and Development

1988

81='~555-1212 630

760

( Next Screen ][ Previous Screen ] ~ Go to: [ Courses Taken ] ( De~lree Plan I [ Advisement ]

Figure 2. ( ' A S A S new student window as produced by Pr,~lot.l'per

SoDe 7 1 1 3 - F o i l , 1 9 0 0

CASAS Computer Aided Student

Advising System

Refine T L D & D e v e l o p L L D

5th Class (Present L L D )

Finalize L L D

Develop Sample Program

6th Class (FInal Design D u e )

14151 1 7 1 5 1 9 I 2425 7 8 II 3 5

I I I I I , l l [ , I , , , [ I , , l l , t l , , , , - ~ e - F F - , r - r - T - T - T - I - q - I - I - I - T T T - T __!~-l . -b-b-l-- l . -4.-4-- l--4-- i-- l-4-4-~- ' .4-' + 4

I I v l I I I I I I I .... ,-4-4-~--b-r--r-r-.~-,-,--~-4.-~-4-4--l--b-,--,--, I [ I I [ [ I I I I I I I / I !

-+

_4_ "__~ 4_ ,'.~_b_ b _,._'='gz:gzTzg~,_4_ 4_4 _ .L "_4.~, ~L4_ 4 --I-+-i-±+-LLi-:I-~-L.!-.ki--L-L-L2-LLi--i _L_ _A__L_L_ __LIS_',__,_Zi_.~_~_5_5_.L.L_~C~__LI

i / I I I / / I I / / / / / 1 / / I I I I . . . . 4-4-4--4--b- '-b-l-- " - ' - ' - ' - 4 -4 -4-4- -L4- -" 4 - J _J__L±_L-_L_L_L_L_ L'_" !_jgJ_j_j_j.L-_k_!

Fiyure 3. Earh' CA SA S design schedule as produced hv M, tcSchedule

,~oxes, and windows. Figure 2 shows one of the CASAS windows developed with Prototyper.

• Scheduling-- MacSchedule by Mainstay ~3, a program that automates the construction of production sche- Jules. Figure 3 shows an example of output derived from this product.

• Management - - Micro Planner Plus t4, a project man- agement tool that automates the creation of critical- path charts, project tracking, resource analysis, and report generation. Figure 4 shows an example of out- put derived from this product.

• Resource estimation ..... COnstructive COst MOdel ( C O C O M O ) : by Barry Boehm, a hierarchical soft- ware cost-estimating model.

• Other Microsoft Word ~', SuperPaint by Ann Arbor Software' 7.

M A N A G E M E N T P H I L O S O P H Y

During the 1988 89 academic year, graduate students in ScDe 7113 and 7123 were paired with undergraduate computer-science majors enrolled in the CoSc 4993 course. The goal was to define a development environ- ment that might closely approximate that existing in industry. For the Autumn semester, nine students (eight graduate and one undergraduate) participated in the project, while seven graduate students and six undergra- duates were involved the following Spring. Serving as customers for the project were four members of the

Computer Science Department faculty. The strategy was to develop the design specifications and a working proto- type demonstrating an acceptable user interface during the Autumn semester and to perform the actual project implementation during the Spring.

First semester

As previously indicated, the primary objectives during the Autumn semester was to develop a design for the overall system, to implement a prototype of the CASAS user interface, and to become familiar with the software tools that would be used for the project development scheduled for the Spring. During the first two weeks of the semester each student was asked to develop an infor- mal set of system requirements based on their individual advising experiences.

While the faculty had hoped to use the results of this effort as the basis for a formal set of CASAS require- ments, it was soon apparent that this approach was unreasonable. None of the students was especially effec- tive at developing a comprehensive set of requirements, in spite of the [act that most of them had professional experience in the development of software specifications as well as classroom instruction in their writing and use. As such, each student turned in a four- or five-page document that tended to focus on the type of advising they had received as a student, but that provided little in the way of concrete capabilities that a generic advising system would need to include. To a large extent the faculty was at fault for not stressing the importance of this initial assignment by indicating in greater detail what was expected of each student.

Due to the difficulty in obtaining a reasonable set of requirements from the students, it became necessary for the faculty to intervene in their development, The result was a 32-page document that required three iterations before its final form was agreed on s. Due to this delay, the final version of the requirements document was not delivered to the students until the sixth week of the 15- week semester. This lateness ultimately created some problems for the students in their final design effort.

In parallel, during the first four weeks of the semester, each student was required to become familiar with vari- ous aspects of the Apple Macintosh. Included were an understanding of the internals of the Macintosh system calls, the use of T H I N K ' s Lightspeed Pascal, and the CASE tools that were provided for the software develop- ment efl\)rt. As CASAS was to incorporate fully the Macintosh 'look and feel', including the use of icons, pull-down menus, windows, mouse actions, etc., it was necessary for the students to familiarize themselves with the system toolbox facilities that Apple provides with the Macintosh. Thus there was substantial work to be done, and students were able to be productive during this per- iod, in spite of the lateness of a forrnal set of require- merits.

Also during this time, the participating students were divided into three competing teams, each consisting of three members, with each team being instructed to deve-

vol 33 no 6 july/august 1991 445

16Jan89 23Jan89 30Jan89 6Feb89

m Pr'~l~'p'e/databaso hi level "~inlegration i = = " " " = = i

~ m l m m l m l

13Feb89 20Feb89 27Feb89 6Mar89

i {

i ~l~es ig n review i i / m j ~ • ~ m m mmmmm ~ m l { mllntegrate database & interface designs

~ mmmm jmmmm m m m

): |)NDevelop user's manual F))|~I[:":..~'J~|

)

Fi, gure 4. Prq/ect phm document as produced hy Micro Phmner Plus

lop a high-level design for CASAS. This was intended to be a "competitive" design process, with the best design ultimately being selected for implementation during the second semester. Each team's design was completed by mid-semester, at which time a preliminary design review was performed (all teams were in attendance). As it turned out, all three designs took a similar approach. Each was partitioned into an interface component and a database component. As instructed, each team's inter- face made heavy use of the Macintosh toolbox facilities and provided the means for the user to communicate with CASAS. The database was intended to contain information about courses, university requirements, and individual students. Each team's design required minor modifications, but all three teams were allowed to pro- ceed to the prototype development phase of the project. This last phase of the first semester's efforts was intended to demonstrate the viability of each team's user interface.

The final two weeks of the semester were devoted to demonstrations of each team's prototype. Each was eva- luated by the customers in early December and judge- ments made based on ease of use, adherence to stated requirements, and conformance with the Apple Macin- tosh human-- inter lace guidelines H'. The prototypes gave the faculty a "feel" for what the CASAS interface would be like with each of the three designs. All of the proto- types included menus, scrollable windows, dialog boxes, and mouse actions. Each was unique in many respects: however, none of the prototypes provided any functional capability in terms of updating their associated data- bases or providing any advising capability. One did, however, give the faculty a sense of the kind of error detection and response that would be supported by that particular design.

Various written documentation was required of each team during the course. This included a final design document and a preliminary user's guide, which were due at the time of the prototype demonstration. In addi- tion, each team was required to provide weekly status reports and written documentation describing their progress during the semester. The reports indicated

accomplishments for the previous reporting period, expected accomplishments for the next period, and areas of perceived difficulty. In spite of the wealth of infor- mation, it was still difficult for the faculty to determine the quality of the competing designs and prototypes. Furthermore, while there was significant involvement by each student, it was difficult to determine the total contri- bution made by each member of the team. As such, at the conclusion of the first semester all students were re- warded with a good or excellent grade.

It was originally intended that the best of the three CASAS designs would be implemented during the second semester of the two-semester project sequence. At the conclusion of the first semester, however, it was diffi- cult to determine the best overall product. Consequently, the best features of each were selected for integration into a final design. One team's interface was selected, one team's database design was selected, and one team's pro- posed system test and documentation method was selected. This approach worked reasonably well, though some additional effort was required to integrate the inter- face and database designs•

S e c o n d s e m e s t e r

Between semesters several changes occurred in the enrol- ment of the course. One graduate student was transferred by his employer and was thus unable to enrol f\~r the Spring semester. In addition, the undergraduate team member completed her degree requirements and gra- duated. Taking their places were six new undergraduate students who had enrolled in the CoSc 4993 course. While these students provided a source of additional help, they also created substantial overhead in that they had to be acquainted on both how to program the Macintosh and also the CASAS design. As Brooks and others have frequently noted, adding manpower to a late project is often self-defeating ~s.

Early in the semester the students were again divided into three teams• Each team, however, now consisted of two graduate students and two undergraduates. In addi-

446 information and software technology

tion, one graduate student from each team was selected to fill the role of team leader, while the one remaining graduate student was selected to serve as the overall project leader. One team was assigned responsibility for implementing the user-interface portion of the design, another for implementing the database, and the last for writing system documentation and performing inte- gration testing. The project leader was responsible for the development of work schedules and coordination of the activities of the other three teams. All teams now worked on a common implementation as there was no competition between teams as had occurred the preced- ing semester.

Weekly status reviews were more formal during the second semester. This was true for a variety of reasons:

• the class size was larger • ~norc communication was required between the co-

operating teams than was required when the teams were in competition with each other

• the faculty felt a need For more information about \vhat was being accomplished

The overall project leader had primary responsibility for the preparation and presentation of the majority of these status reports.

Orientation time for the undergraduates was approxi- mately Four weeks roughly twice as long as was expected. During this period, the other members of the project had begun working in earnest on the develop- ment of a complete high-level design. The first draft of this design was completed in early March and work on the detailed design was started. Seven weeks of the semester had now elapsed and the project was many weeks behind schedule. It soon became apparent that the project was overly ambitious (the initial detail design for the database alone required 115 code units). In addition, it was soon learned that the workload was unevenly di.,tributed. As time progressed, it became obvious that the database portion of the project would require more effort than the other areas. Consequently, it was necess- arx to shift lnanpower from other teams on to the data- ba,,e team. These team members were later shifted to the user-interface team and then ultimately to the inte- grution, test, and documentation portions of the project. The lhculty, in response to this problem, agreed to allow solne scaling back in the scope of the project. For exam- pie, it was determined that this version of CASAS would only have to accommodate the requirements of the TCU AddRan School of Arts and Science rather than the mere generic requirements of an arbitrary college or university.

Fhe detailed design, which was originally expected to be completed by mid-February, was further delayed due to the scaling back of the requirements. The result was that the tinal detailed design was not completed until mid-March three months late! Coding, which had been expected to begin in February and terminate by the end of March, was very much behind schedule. In spite of Ihis, development of the database code was essentially

completed by the end of the semester in May. However, development of the interface logic had not progressed nearly as far. Thus, by semester's end, little progress had been made in the integration of the database and user- interface code. As a result, students were offered the opportunity to continue the development of the project during the upcoming summer months. Approximately half the students elected to continue working, while the other half were assigned grades based on the status of the project at that time.

During the summer of 1989 most of the database code was completed and work was begun on the user-interface code. During this time a significant flaw in the design was uncovered (if a department was eliminated from the database then those students majoring in that discipline were left 'dangling'). By the conclusion of the summer a partially completed system was demonstrated to the faculty, which was reasonably satisfied with the results. Updated versions of the design documents, CASAS installation manual, system test procedures, and user's manuals were also delivered at that time.

ONGOING WORK

During the 1989 90 academic year a smaller group of graduate and undergraduate students has continued to work on CASAS as part of the project work required for their degrees. At the present time, there have been three graduate students and one undergraduate student parti- cipating during the Autumn semester and three graduate students and two undergraduates during the Spring. Alter their initial orientation, which required approxi- mately one month, these students have made excellent progress. Most of the work that remained from the sum- mer has been completed. In addition, many of the short- comings in the original design have been identified and corrected, and several suggestions for improvements have been incorporated into CASAS. At the time of this paper the only significant feature of the revised version of CASAS that remains unimplemented is the report gener- ator. The faculty anticipates having a preliminary version of CASAS available for use during the advising sessions scheduled t\~r April of this year.

S U C C E S S O F C A S A S A S P R O J E C T S COURSE

The intention of the project courses, both SoDe 7113/ 7123 and CoSc 4993, is to give students a chance to apply the techniques that have been presented in their various graduate and undergraduate programs. In particular, they offer students an opportunity to work on it software development task that requires the application of meth- ods applicable to programming-in-the-large as opposed to the programming-in-the-small approach typical of most classroom assignments. These programming-in- the-large methods include working in groups, perform- ing management functions (i.e., planning, coordinating, controlling, and allocating resources), and the use of appropriate development tools.

vol 33 no 6 july/august 1991 447

The CASAS project has proved to be a particularly effective means for achieving the goals of both of these project courses. A number of factors has contributed to this effectiveness. The most significant is that CASAS represents a useful end-product: thus the students were not left with the impression that an artificial problem had been selected in an attempt to illustrate some academic point. This realism has contributed to the student's sense that the methods that have been applicable to the CASAS development will also be appropriate for other large software projects.

Two other techniques have proved to be especially beneficial for CASAS. These are the use of rapid proto- typing and specialized tools to aid in the development of prototypes. In a highly interactive system it is frequently difficult to predict how the most effective (i.e., friendly) user interface will appear. By using the SmethersBarnes prototyping tool the students could construct prelimi- nary versions of the screens, menus, windows, dialog boxes, and mouse actions that a user would expect to encounter when running CASAS. Exercising the proto- type of the interface provided feedback that allowed the students to refine their proposed interface. Without these tools to automate the calls to the Macintosh system toolbox routines, the development of the prototype would have been more time-consuming and much more error-prone. A by-product of this effort was that the students were able to familiarize themselves with the internals of the Apple Macintosh: this also contributed to their sense of accomplishment and seemed to encour- age a greater degree of professionalism in their software.

Other development tools were also effectively used with CASAS, output examples of which were shown earlier. The most productive were the dataflow design tool Anatool, the project scheduling and management tools (MacSchedule and Micro Planner Plus), the cost- estimating model COCOMO, and the interactive debug- ger, which is part of T H I N K ' s Lightspeed Pascal deve- lopment environment. Frequently, the overhead of learn- ing and invoking such tools for a small problem is generally offset by any advantage that the tool might have provided. Thus students are often left with the impression that much of the talk about tool sets and their use is a lot o f ' sound and fury signifying nothing'. Not so for CASAS! The project was sufficiently large that the students were able to realise that the use of tools paid a significant dividend.

S O M E P A I N F U L L E S S O N S

In addition to its pedagogical value already described, the CASAS project provided the students with a number of 'real-world' lessons about software development. These lessons may well be of greater value than the use of tools, working in groups, use of rapid prototyping, etc. Some of the more significant lessons are now described.

The first lesson is concerned with the value of good system requirements specifications. As practitioners of software development, most of the students understood the need for good requirements; however, when asked to

develop a comprehensive set of requirements specifica- tions they were unable to do so. While this approach is the common one that prevails in industry, the authors feel that the project would have benefited had the requirements been generated by the faculty and given to the students at the outset. This was especially apparent when they attempted to develop their own design based only on their vague and informal understanding of CASAS.

Another painful lesson was learned as a consequence of having insufficient resources and the poor allocation of those resources. While the first semester proceeded fairly smoothly, the second semester was a scheduling nightmare. First, the students were required to work within an abbreviated schedule that was imposed by the time limits of the semester. Many of the students felt that such a schedule was rather artificial, but it was pointed out that schedules for many real projects are often dic- tated by forces beyond the control of the developers. Also, as might have been expected, the addition of more manpower to the project increased rather than reduced the workload, just as Brooks and others have noted ~s. Furthermore, scaling back on the project did not prove as beneficial as the students had initially anticipated, as much of the earlier design and specifications was made obsolete.

An associated problem was that the project and team managers were overly optimistic about their schedules. Each was reluctant to admit early in the second semester that they were in serious trouble. This was a classic case of using what Brooks refers to as "gutless estimates" and illustrated the fact that more software projects fail for a lack of sufficient calendar time than any other reason.

The scheduling problems were further compounded by a number of unanticipated hardware and software problems, such as a disc thilure on the Vax 11/780 computer system that was being used for some of the development work - - the Vax had run for several years with virtually no long-term failures until the Spring semester of 1989 and an insidious software bug in the Macintosh to Vax communications software (Paser- Share rg) that would occasionally destroy the student's source-code files. The communications problem was eventually traced to different versions of the software running on the Macintosh and Vax computers, a problem that the vendor originally assured the university was not possible! There was also a severe winter storm that shut down the university for several days during the Spring semester. Again, these setbacks demonstrated to the students the need to include slippage in a schedule to contend with the unexpected.

And, as is frequently the case, when the project fell behind the students attempted to make up time by cut- ting corners. For example, there was initially too little effort made to enforce the design standards that had been set down or to perform sufficient unit testing as code was being written. As a result the design often could not be understood; furthermore, the interface between units of code often broke down. Eventually much of the earliest developed software had to be redesigned and recoded.

448 information and software technology

Walk-throughs were finally implemented to improve the quality of the design, code, and unit testing. While all of the students should have been well aware of the potential danger of this short cut, the temptation proved too much and yet another lesson was learned the hard way.

While the students were able to make effective use of many of the available tools, they also paid the price of using inappropriate tools on an inadequate platform. E~t'n though kightspeed Pascal provides a means to pa, tition large projects, it is a rather awkward procedure duc to the nature of Pascal (Wirth designed Pascal so thai programs would be written as a monolithic units), As a result, it was difficult for several students to work simultaneously on different portions of the software, This problem was further compounded by limitations in the original versions of Prototyper and Lightspeed Pas- cal, which limited the size of any unit of code to 32K bytes (subsequent updates to these tools alleviated this restriction). Finally, the students frequently exceeded the amount of memory or disc space available on the Macin- tosh during the coding phase.

.Xnother painful lesson was the price of re-inventing the software wheel. A significant portion of the CASAS project involved dexeloping a customized database s~ tem, While the students felt that CASAS performance and size requirements necessitated this approach, the database system that was developed was neither efficient nor flexible nor robust (31 routines were invoked, includ- in1: opening and closing disc files, for each record accessed from the database). The entire project would undoubtedly have benefited from using a commercially av filable database system.

S T U D E N T C O N C E R N S

There was a number of factors that the students tbund unpleasant about this project. Many of these relate to the lessons described in the previous section that were le~rned the hard way. However, several issues were raised that are somewhat unique to a classroom situa- tion, and both students and instructors should be aware of these factors.

One concern was that the team and project leads had little authority over those who worked with them. During the semester, the leads were asked to evaluate the pcrtbrmance of each of their team members: however, t h s was not viewed as offering much leverage to the leads in getting work done. In addition, all of the students felt as if their grade depended to some extent on the efforts ( o lack of) of others in the class. While this was a valid ctmcern, these factors were taken into account at the end ol the semester. It wits also pointed out that supervisors and managers in industry often do not have as much authority when dealing with ineffective employees as m @ u be imagined.

Another area of student concern was the competitive nature of the tirst semester's design work. While they acknowledged that there is competition in the markel- place, they fell that it was somewhat unfair to pit one set of students against another. The situation was viewed as

a zero sum game where one team could only prosper at the expense of another. Once again, the faculty attempted to assure the students that this was not the case, but the feeling seemed to linger, Several students also suggested that more could have been accomplished in the first semester had they all worked on different aspects of a common design, thus reducing some of the pressures felt in the second semester.

R E C O M M E N D A T I O N S

In retrospect, the CASAS project was a valuable exper- ience for the students. The authors recommend more curricula adopt such an approach. Before doing so, how- ever, careful thought should be given to a number of issues. Paramount among these is the selection of an appropriately scaled project. Such a project needs to satisfy a variety of goals. It should require that students "program-in-the-large" without causing them to lose any hope of completing the project within the imposed time limits. A project that has an intrinsic value of its own also adds to the students" feeling of accomplishment and con- tributes to their motivation. In addition, thought should be given to the evaluation process that will be used to measure the quality of the finished product. Also, for the project to be successful, it is important that the students have a good understanding of the problem from the outset.

The authors also recommend that care be used in the selection of the team and project leaders. The success or failure of the overall project rests with the management skills of these individuals. The authors" experience is that the CASAS project benefited substantially by using graduate students to direct the development effort. How- ever, it should be pointed out that graduate students in TCU's MSDD program have had two or more years' experience in professional software development.

The final two points concern project resources. First, avoid using an untested hardware or software environ- ment. The inevitable problems that arise compound an already diflicuh task, and this detracts from the value of the project. Second, avoid the consequences of Brook's law - do not add excessive manpower in the middle of the project.

In summary, the CASAS project was a useful educa- tional experience for the students and it is the authors ' intention to continue with a similar management philo- sophy in future semesters. It is hoped that these observ- ations and recommendations are useful to anyone who may wish to undertake a similar project in the future.

R E F E R E N C E S

! Comer, J R and Rodjak, D "Adapting to changing needs: a new perspective on software engineering education at Texas Christian University" in Sq/hrare engineering education. the e~hwational needs o1" the sq/hcare communitr Springer-Ver- lag (1987) pp 149- 171

vol 33 no 6 july/august 1991 449

2 Comer, J R, Nute, C T and Rodjak, D 'Some observations on teaching a software project course' in Issues in s~/?ware engineering education Springer-Verlag (1989) pp 215-229

3 Ford, D and Gibbs, N 'A master of software engineering curriculum: recommendation from the Software Engineer- ing Institute' Computer Vol 22 No 9 (September 1989) pp 59 71

4 Rinewalt, J R and Banios, E W 'CESAR College of Engineering Student AdvisoR" in Proc. ASEE Annual Co/!/i Enghwering Focus on Ew'el/em'e Reno, NV, USA (21-25 June 1987) pp 641-647

5 Comer, J R, Nute, C T and Rodjak, D "System requirements • specifications for the Macintosh Computer Aided Student

Advising System (CASAS)" Technical report Texas Chris- tian University, Fort Worth, TX, USA (3 October 1988)

6 Tchao, M e t aL Approachh2g Macintosh Addison-Wesley (I 986)

7 Chernicoff, S Macintosh revealed (Vols 1 and 2, 2nd ed) Hayden, Hasbrouck Heights, N J, USA (1987)

8 Apple Computer, Inc. h~side Macintosh (Vols 1 IV) Addison-Wesley (1986)

9 Symantee Corp. THINK's Lightspeed Pascal Symantec Corp., Cupertino, CA. USA (1988)

I0 Apple Computer, Inc. AppA, human inte~Jitce guihh,/hws: l/w Apple desktop inteJJbce Addison-Wesley (I 987)

11 Advanced Logical Software Anatool structured sv,~tems amth'sA Jbr the Machltosh Adwmced Logical Software, Beverly Hills, CA, USA (1985)

12 SmethersBarnes Prototyper SmethersBarnes, Portland, OR, USA (1989)

13 Mainstay MacSche,hd: ,scheth&, ~h, velopment, th)CllDICll- ration and pre.s'entalioH Mainstay, Los Angeles, CA, USA (1988)

14 Micro Planning International Micro P]anner Micro Plan- ning International, San Francisco, CA, USA (1987)

15 Boehm, B W S~?[tware enghleerhlg eco/lomics Prcnticc Hall (1981)

16 Microsoft Corp. Micros~?/? Word user's guitk" Microsoft Corp., Redmond, WA, USA (1988)

17 Silicon Beach Software, Inc. SuperPaint user manual .[or Machttosh Silicon Beach Softwai'e, Inc., San Diego, CA, USA (1988)

18 Brooks, F P The mythical man-month, e.ssars on ,s't?/tware enghwering Addison-Wesley (reprinted 1982)

19 Pacer Software, Inc. PacerLink Pacer Software, Inc., West- borough, MA, USA (1989)

450 intbrmation and software technology