00491364

8/10/2019 00491364

http://slidepdf.com/reader/full/00491364 1/7

78

Balancing Process and Product

Donald J. Bagert

Department of Computer Science

Texas

Tech University

[email protected]

Lubbock

TX

79409-3 104

Abstract

The following research question vas posed: an large-team projects with in-house

customers be used

to

eflectively teach the software engmeering development process, while

stillproducing completed an d usefil products within a set time period?

This

paper describes undergraduate and

graduate

software engineering courses taught

at

Texas Tech University which have large-team projects. In those courses, there is a balance

achieved

so

neither the process nor the product aspects of software development are overly

emphasized. In other

words,

having a completedor nearly-completed project at the end

of

the

semester

is

essential.

Equal

parts

of

the

grades

in those

courses

is given

to

the process and

product

aspects of

the large-team software development project.

A number of

successful

projects have been developed using

t h l s

method. the grades in the process and product

phases of the course

being

approximately the same.

Interaction with industry

has

provided input

which h s

resulted

in

some im provements

in

the software process used in these courses.

A

self-study

of

the software process maturity at

Texas Tech found the process to be level 2; materials have been developed using the self-stud y

team’s

recommendations,

wth

the goal being to improve the process maturity t o level

3 .

1 Introduction

There

has

been a sipfica nt initiative

in

last several years to improve the software

engineering development process, usmg such tools as the Capability Maturity Model (CMM )

[CMU/SEI 19951 and the P ersonal S oftware Process [Humphrey 19951. This has led software

engineering educato rs

to

examine and improve the software process techniques

that

are taught

and

used in

their

own project

(

for

instance

n

[Coyle

et

al

19941,

[Werth 19941, and [M oore and

Brennan

19951).

However. several educators,

such as Petex Denning in I s k ey no te address at the

Conjkrence on Software Engineering Education

in

1994, have

of

overemphasizing

the

process

at

the expense of

the

product (the latter being the primary concern

of

the customer).

Therefore,

it is

important that when software engineering is taught,

th t

there

is

some type of

balance achieved so neither the process nor the product aspects of

software

development are

overly emphasized.

So,

in project

courses,

such

as

the large-team course de he d by T om yk o

[1987], having

a

completed or nearly-completed project at the end

of

the semester

(or

quarter)

is

eSSential.

0 8186 7249 8/96 05.00 0 1996

IEEE

mailto:[email protected]

mailto:[email protected]

8/10/2019 00491364


79

The literature is

also

filled with examples of the importarice of having industry involved in

software engineering education, such as being the customer ion class projects (e.g. [Tomayko

19911; [Moore and

Potts

19941).

In

this manner, tudents have the experience of dealing with a

“real world” customer in creating

a

“real world” project h i c h will1 actually be put into use.

However, it becomes more difficult to have the project be of a s8izewhich can actually be

completed in a single semester when a n “ou tside” customer is

used.

Therefore, other alternatives

should be considered.

At Texas Tech University, the alternative proposed

in

1991 was

to

have the projects

generated inside of the computer science department, while having those projects be ones that are

actually used upon comp ktion. (Oth er courses could have inlduStriid custom ers; see Section

5

for how

this

occurs at Texas Tech.) In other words, the following research question was posed:

Can large-team projects with in-house customers be used fo efictively teach the sofiware

engineering development proc ess. while still producing completed and usefkl products within a

set time period?

Over the last five years a t Texas Tech, the answer

has

been found to be

yes .

This paper describes the introductory undergraduate and

graduate

s o h e engineering

courses at Texas Tech which have been implementing successful large-team projects with

in-

house customers since the spring of 1991.

Section 2 provid’es and overview of these courses,

while Section 3 shows how the process and product aspects

of

software development are

b a l a n d during project implementation. Section 4 describes current work being implemented to

improve the maturity of

the software

process used in courses at Texas Tech, including some

interaction with industry. Section

5

describe s how

maintenance

and cdmncement of the software

developed in these courses are performed, and how “outside“ customers are used in follow-up

courses. Finally, Section

6

provides a summary.

2. Overview o f the lntroductory Courses

at

Texas

Tech

Computer Science 3365 (Software Engineering) and 5363 (softw are Engineering Systems)

are the introductory undergraduate and undergraduate sofimre engineering courses,

respectively, a t Texas Tech University.

C

S 3365 is

the first course

of

a required three-semester

software engineering sequence (the other

courses

will be di jcussetl

in Section 5),

and uses a

variatiodrefin emen t of the T omayko model for large-team project courses [Tomayko 19871.

Most of the students n this course a re computer science majors. C S 5363 assumes that the

students have

a

basic intrcduction to software engineering concepts from either a previous

course or work experience, while s t i l l using the same large-team model as the undergraduate

course.

Several of the students in 5363 are non-majors (usually from

some

other engineering

disciplie); it is one of the most popu lar grad uate courses at the iuniversity (usually about 20

students are tumed away du e to lackof space).

The projects are chosen a re cho sen using several criteria, the most important of which are:

1)

the probability of completion of the pro ject during the semester, 2) the ability to put into

practice software engineering skills during the development of the project, and

3)

the potential

usefulness of the project afte r completion.

There are two type of projects that are usually

given

in these courses.

One is the

development of a software tool which

can used in

later semesters of this course’. Examples of

’

The class

also uses educational versions of

commercial

CASE

tools:during the course.

8/10/2019 00491364


80

such projects have been a Configuration Management Tool 0.Testing aNd Evaluation

Tool (TNET), and a software defect tracking mechanism (inspired by w er th 19941). The other

t p e of project is the development

of

some software that

wll

be used at Texas Tech, such as a

Student Tracking And Recruiting Tool

(START),

for prospective

students;

a degree plan

maintenance system (DPLAN), and a Graphical Orientation Advising Tool (GOAT’), which

is

used to help formulate schedules during summer new student orientations at Te xas Te ch.

Virtually all of the products developed

in

the large-project

courses

were delivered on time,

in complete or near-complete form, and are currently being (or have previously been) used

successfully at Texas Tech. The projects are maintained and en h a n d by students who have

previously taken this course (see

Section 5 .

In two cases, an unusable product was delivered. Both times, the cause was due to severe

personnel problems at key positions. Usually, however. serious personnel problems have been

overcome using standard conflict resolution t ec hq ue s.

3. BalancingProcess and Product

Currently 30 of a student’s grade from their performance in the software development

process and

30%

comes

from

the evaluation of the delivered product. (The remainder of the

grade comes from the course exam inations, peer evaluations, and the fi n

oral

presentation

of

the project). The.grade for the final product is same for each student in the class. The 30

“process” grade is broken down

as

25%

for the

six

project

assignments

(modified and retined

from

those defined by T omayko), and

5 comes a

re-evaluation of those assignm ents after the

project is completed. Since he amou nt of work

is

differentat

a

particular

phase

of the project,

depending on the student’s duties (e.g. Configuration Manager), the percmtage for

each

assignment

s different for each individual and group

within

the project team Table

1

contains

the percentage breakdown that \vas

most

recently used.

Assignmcnt

1

2

3 4 5

Principal Architect 12

Project Adm inistrator I Yo

Quality Assurance Manager 5

Design Group

2

Implementation Group 2%

Documentation Specialist

2

Test

&

Evaluation

Engineering

Group

2

V & V Engineering Group 2

Configuration Manager 6

5yo

3

yo

3%

4%

11%

2%

3%

4

4

2

3

4%

1

2Yo

4

4%

3yo

4

2

3yo

3

4

o

3

%

4

4 o

4%

4

2

3

4

1Yo

6%

6%

6%

6

3yo

Table

1.

The process assignment percentage breakd own s

for each g roup within

a

team.

’

Okay,

so he project team

doesn’t always choose

the

best of

acronyms

6

2%

6%

7

4

o

9

6%

5?o

5

8/10/2019 00491364


81

There are two main criteria used to assess whether promss

and

project has been balanced

sufficiently. One

is

the amount of effort required for fine-tuning (tiefore release), maintenance

and enhancement of the system in future semesters.

In

general, ihe software

has

been very

maintainable, with only a small fraction of the original project cmts required. (The main

problem in maintenance

has

been for the students

to

keep the :same l'evel of process management

as

in

the

original

project;

this

s discussed further in Section

5 .

The other criteria used is to compare the average of the 30% of the grade assigned to

process issues with the grade given to the final delivered prodiuct. Although the process average

is

g e n d y higher th nthe delivered product grad e,

it

not significclnt& higher (usually around

3%))".

The satisfaction level of the course has been high with both students, the inshu ctor (i.e. the

author), faculty who have t ught the later courses

in

the wndergr,aduatesoftware engineering

sequence, and employers of gradu ates

who

took

his

course.

'The

students found a

great amount

of sa ti sW o n and sense of personal achievement by being able

to

deliver a completed. usable

project at the end of the semester.

4. Current Process Improvement Initiatives

During most summers, the author teaches

a

software enginexring course as part of the

Masters of Systems En gin ee hg degree program

at

Texas Tech. The students n

this

course are

practicing

system

engineers

from

arge companies. Due

to

the short physical length ofthe class

(four weeks of contact), a large-team project

is

not assigned.

However, the Capability Maturity Model is covered in tlhe software engineering course4.

In

the summer of 1994 the systems engineers were asked to do

a

brief evaluation of the prmess

maturity (as dethed using the CMM) of the s0-e engineering large-team projects at Texas

Tech, using coursematerials and a recent project supplied to them. The students, n teams, were

required to give both

oral and written

reports of their findings.

All of the te m concluded that the software process currently used in those courses

was

either at a level

I

or a level 2, although all of the teams were impressed with the quality of the

process for an academic environment. Several reC0 "end ;ltions were made on mproving the

standards and policies guidelines, and in formalizing the process in places to better reflect

industrial practices. Many of these recommendations were snccesr;fully implemented during the

1994-95 School

YW.

In the summer of

1995

two students who had taken the undergraduate sofhvare engineering

course

during the previous spring were assigned

to

do a formal self-study of the software

engineering process used at Texas Tech, using the Capability Maturity Model, and materials

supplied by the SoftwareEngineering Institute [Zubrow

et

a1 19941. The two students used the

&jhvare ProcessImprovementGame (§PIG)' [AST 19931 o help them leam about level 2

of

The author also believes that he

gr des

the

project

assignments

a

little

easier

than the

final

delivered

product.

Perhaps e

needs o leam

a lit tle more

balancing ..

Since

he studentsrecognizedtheapplicabilityof the CMM to

system

engineering, they were

not

surprised o

learn that

a System EngineeringCapability Maturity Model

(SE-C")

was b5ng developed

The SoftwareProcess mprovement Game is

993

by

Bob

and

Vicky Holanan.

8/10/2019 00491364


a2

the CMM.

So

as not to bias their findmgs, these students were not given access to the previous

reports written by the various system engineering

eams.

The

evaluators gave a detailed report which classified the

Texas

Tech software

process as

level 2, with a number of recommendations on how to make improvements in order to progress

to

level

3.

The author accepted these recommendations, and for the rest of the

summer,

these

same

students to developed materials based on their report findings. The new

materials,

including updated and expanded standards and policies, will

be

implemented at Texas Tech

starting in the spring of 1996, and will also be used in the later courses of the undergraduate

software engineering sequence.

5. Follow-up Coursework

5.1 Software Maintenance and Enhancement

Due to the limited time frame of

a

one-semester software engineering

course.

there is no

opportunity for

a

maintenance cycle. Therefore, fine-tuning (before actual

use).

maintenance

and enhancement of the projects have been performed using the undergraduate and graduate

Special Topics classes. Students in these courses work either as individuals or in small teams.

Virtually every project developed by

C S

3365 and

5363 has

gone through at least one such

maintenance cycle. s with most

successful

software products,

various

enhancements have been

made for future releases.

In

several cases, this has included porting the software from DOS@ o

Mi cros ob WindowsW.

The only problem

that

the students have

had

with this approach is the lack of separate

Testing & Evaluation and V& V

groups

to test and inspect, respectively. their work, as

is

done

in the introductory software engineering

courses.

However, this deficiency will be

corrected

through the use of students from the year-long senior project class (described in Section 5.2

below).

5.2 Using Industrial Customers

As

was

mentioned in the introduction, there have

b e n

many

cases

described

in

the literature

of

successful projects developed

for

industry w ithin software engineering courses. There has

been

two

ways that

this has

been accomp lished in the past at Texas Tech in the undergraduate

sequence. One is through the Sp ecial Topics classes, and the other is through the two-semester

senior project

sequence (Computer Science 4411 and 4412). Several successful software

development projects have developed for local companies using this format.

However,

although h e

year-long

senior

project

class

has

h d

as

one

of its

prerequisites the

introductory software engineering course

for

several years,

the

three-semester sequence has not

been tightly

coupled. However, this will change during

the

1996-97 school year;

starting in

the

fall of 1996, the senior project courses will be using the same set of software development

standards discussed in Section 4.

The

benefits of

this are

obvious: not only is training time

reduced, but by

giving

the students

a

single department standard for doing their software

engineering projects. it will give the students the same experience as they would for

working

in

various departmentsof the same company.

8/10/2019 00491364


83

The primary focus

of

the revised senior project courses swill be the development,

maintenance and enhancement of software for “outside” customers. Some students will work on

several different projects. and all will be exposed to dilTerent aspects

of

the software

development process th nthey were

in

the introductory course.

Also, as

previously mentioned in

Section 5.1, testing and inspection support will be given to shidents performing maintenance of

the in-house projects developed within the introductory courses

In summary while the first undergraduate software engineering course provides the student

a very neat and compact project where there is a sense

of

completion and closure, the senior

project courses introduces them to more of the open+nded complexities

of

real-world software

engineering. The overall experience

is

intended to g ive the stuidents

a

well-rounded background

to take with them into the workplace. (Unfortunately , however, thexe no equivalent to

“studio”

equivalent to senior projects at this time in the graduate program, although one has

been

discussed for many years, and its eventual implementation

is

envisioned.)

6.

Conclusions

The following research question was posed:

Can Imge-team projects with in-house

customers be used to efectiveiy teach the sofrware engmeering deveIopment process, while

still producing completed and usefil products within a set time period? Since

199

1

at Texas

Tech University, the answer has been found

to

be in the aflimative.

This paper described the introductory undergraduate and graduate sofhvare engineering

courses taught at Texas Tech. In those

courses.

there

is

a balance achieved

so

neither the

process nor the product aspects of software development are overly em phasized. In other words.

having a completed or nearly-completed project at the end O the semester is essential. Equal

parts

of

the grades in th ose courses is given to the process andl product aspects of the large-team

software development project. A number of succ ess ll projects have

been

developed using this

method, with the grades in the process and product p hases of ihe course being approximately the

same.

Interaction with ind ustry has provided input which allowed for some improvements

in

the

s o h e process used in these cou~ses .

A

subsequent self-study of the software process

maturity at Texas Tech found the process to

be

level

2.

Materials have been developed using the

recommendations of the self-study te mwith the goal being 10 improve the process maturity

to

level 3.

Follow-up courses give the student further software engineering background

through

pdonning soffware maintenance and enhancement on projects developed in the introductory

courses. and by having students work on projects with industrial custom ers.

In

summary

the Texas Tech Department of Computer Scienwe intend to continue to teach

their large-team introductory undergaduate and

graduate

software engineering courses in their

current format. The satisfaction level of these courses

has

been hi with students. faculty, and

employers.

8/10/2019 00491364


84

References

[AST 19931

Advanced Sys tem

Technology,

Inc., Lawton OK, 1993. ( ba rd game)

c Software Process Improvemenf Game?

[Coyle et a119941

m ed Systems Te

Coyle,

Frank

P.; Forest, Edward; Tanik,

Murat,

M ;nd Frailey, Dennis. Meeting the needs of industry:

SMU's master 's

degree

program

in sohare

engineering.

Proceedings of the 7th Conference

on

Software

Engineering Education Lecture Notes in Computer Science

750),

5-7 January 1994, San Antonio TX

(Published by Springer-Verlag, Berlin, Germany, Jorge L. Diaz-Herrera, ed.), pp. 543-554.

[CMU/SEI 19951

Camegie Mellon University, SoftwareEngineering Institute. The C a p b i l i ry Maturity Model: Guidelines

for Improving the Sofhvare Process. Addison-Wesley Publishing Company

(SEI

Series in Software

Engineering),

Raiding

MA; Mark C. Paulk, Charles V. W e b k , Bill Curtis and Ma q Beth Chrissis,

principal conhibulrors

and

editors.

[Ilumpiuey 19951

Humphrey, Watts S.

A

Discipline fo r S o f t r e Engineenng. Addison-Wesley Publishing Company

( S a

Series in Sofhvare

Engineering),

ReadingMA.

pfoore and Brennan 19351

Moore, Melody

hl .

and Brennan,

Terence.

Proceedings of the

8ih

Conference

on

Sofwore Engineering

Education Lecture Notes in Computer Science 895), 29 March-1 A p r i l 1995, New Orleans LA (Published by

Springer-Valag, IMin, Germany, RosalindL.

Ibrahim,

ed.),pp. 123-130.

pfwre and Potts 19941

Moore, MelodyM. nd Potts, Colin.

Proceedings ofth e 71h Conferenceon

Sofrwore

Engineering Education

Leciure Notes in Computer Science 750), 5-7 January 1994,SanAntonioTX (Published by

Springer-Verlag,

Berlin,Germany, .forgeL. Diaz-Herr-

ed ,

p. 151-164.

uomayko 1987

Tomayko, ames E. Teaching a Project-lniensive Introduction io

Sofrwore

Engineering. Special Report

CMUBEI-87-SR-11, Soflware Engineering Institute, Carnegie-MeUon University, Pittsburgh PA, March

1987.

[Tomyko 19911

Tomayko, James I . Teaching

sofhvaredevelopment in

a

studio environment. Proceedings of the

Tweniy-

Second SIGCSE Technical Symposium

on

Compuier Science Education (Published by ACM Press, New

York, B a r b Botcher Owens, ed.), held in anAntonio TX, 7-8 March 1991,pp. 300-303.

[wath

19941

W a t h , Laurie

Honor.

An adventure n software

process

improvement. Proceedings of the 7th Confirence on

Sofiware Engineering Education Lecture Notes in Computer Science 750),

5-7 J a n w 1994, San Antonio

TX Publishedby :Springer-Verlag, Berlin, Germany, Jorge

L.

Diaz-Herr- ed.), pp. 191-210.

[Zubrow et all 9941

Zubrow, David; Hayes, William; Siegel, Janq and Guldenson, Dennis.Maturity

Questionnaire.

Special

Report CMU/SEI- )4-SR-7, Software

Engineering

nstitute, Cmegie-Mellon University, Pittsburgh PA, June

1994.

00491364

Documents

Transcript of 00491364