Spring 2004



Dr. Peggy Brouse


WebCT Instructions

Work Phone:

(703) 993-1502 (with voice mail)


(703) 993-1706



GMU:  Science and Technology II - Room 317

Office Hours:

Thursday 3:00 to 4:00

Course Description:

Intensive study of the systems engineering lifecycle for information technology and software intensive systems.  Analysis and design processes for information systems engineering.  Configuration Management.  Lifecycle models for the development of systems.  Technical direction and systems management of organizational processes.

Course Hours:

Thursdays 4:30 to 7:10 p.m.  Robinson A106


1.       Chapters 1, 2, 18, 19  System Engineering and Analysis, 3rd Edition (1998); Ben Blanchard  ISBN: 0131350471 Prentice Hall


2.       CMMI Distilled, Dennis Ahern, (2004) 2d edition Addison-Wesley ISBN: 0321186133


15% - Refereed journal articles (5% for each unit)


25% - Group presentation


30% - Exams (15% for each exam)


30% - Final Paper


Refereed Journal Articles

Information for article review is on the next page.

Group Presentation

Each student will be a part of a small group that will be required to give a formal presentation on an aspect of one of the units.  Assignment of the presentation unit will be done the first day of class.  The group should give me a short synopsis of their prospective topics 1 week before the presentation date.  The groups will also work together occasionally in class to review case studies and do other group activities.

Research Paper

The student will choose one of the units as their primary interest.  For the given unit, they will write a research paper on the topic.  The paper should be a comprehensive study of the unit.  Although there is no set length for the paper, a good estimate of length is thirty (30) pages.  An annotated outline of the paper is due on the sixth week of classes. The final paper is due on the fourteenth week of classes.  Both a softcopy and hardcopy of the paper are due.


Two exams will be given.  They will cover all three units of study.


Research papers WILL NOT be accepted late. Tests will be in-class.  Reasonable accommodations will be made for job-related travel, etc. but requirements will not be waived.



Refereed Journal Articles

Technology is changing rapidly. In order to keep current with trends, it is

important to be familiar with the literature in the field. Therefore, we

will be creating a class biography to enhance our knowledge of the field.

Students will be required to conduct literature searches to select three

(3) refereed articles relating to each unit (Systems Engineering, process

improvement, configuration management) we study for a total of nine (9)

articles for the semester. The articles should be taken from refereed

journals (e.g. IEEE, ACM). It is not necessary to make copies of the

articles for your fellow students, but it is necessary to make me a copy of

each article.


The student will submit a one-page summary of each article for inclusion in

the classes’ bibliography. Students need to give both a hardcopy and

softcopy of the article writeup to me. Please put all three articles in the

same softcopy document. Please save the document in a Microsoft Word 6.0

format. The softcopy document should be named AAAA00X.doc where AAAA is the

first four characters in your last name and X is the number of the unit

contained on the disk. For example, my document for unit one would be

BROU001.doc. The writeups for the entire class will be consolidated and

given back to you on the same disk you give me. Please run a virus checker

on your disk before you give it to me. For a class of 25 students, we would

have around 90 articles for each unit for a total of 270 articles by the

end of class. This will make a nice bibliography for further study.


Please follow the format predefined in the template, it will make my

consolidation of the bibliography much easier. Below is what the summaries

are supposed to look like, but there is additional formatting contained in

the template (headers, ...), so please use it.


Authors: [bold type, last name of author, first name of author, semicolon;

last name of next author, first name of next author, semicolon, etc.]


Title: [bold type, title of article]


Publisher: [only label is bold; contains publisher, volume, number, etc.]


Date of Publication: [only label is bold; contains date article was



Keywords: [only label is bold; contains keywords associated with the

article; usually five to ten keywords]


Abstract: [only label is bold; a brief summary of the contents of the article]


Note: type should be Arial; 12 point; line spacing of 1.5 lines.


Three examples of article summaries are attached below.


In addition, the student will be required to write a short paper for each

unit comparing and contrasting the 3 articles they have selected for the

unit. This will be read only by the professor.





Author: Carmel, Erran; and Becker, Shirley


Title: A Process Model for Packaged Software Development


Publisher: IEEE Transactions on Engineering Management, Vol. 42, No. 1


Date of Publication: February 1995


Keywords: COTS; commercial software; shrink-wrapped software; software

product; methodology; life-cycle; custom software


Abstract: As software development migrates from its basis as a customized

process for customized products to building packaged products there is a

greater need for a product development process model that is market

oriented. Field study conducted by these authors suggest that process

models are not widely used in the packaged industry. A review of the

current models in software engineering, engineering management, and

marketing management indicate short falls in some manner across the board

for packaged software processes. This article identifies eight special

needs of package software that are not inherent in the individual models

currently used: addressing multiple user types, differentiating the

product, finding the remote customer, involving the remote customer,

facilitating speed of development, creating the marketing interface,

developing a highly iterative mode, and releasing a near defect-free

product. These needs are met in the proposed packaged software process

model offered by the authors. This model is based on two central

constructs: a requirements loop and a quality loop. The loops are separated

by a stage where the requirements are frozen. The goal of the requirements

loops is to discover requirements early and comprehensively. The process

model relies heavily on incremental prototyping, has several evaluation and

exit points and structures the involvement of customers as well as

marketing externalities. The quality loop addresses the need to reduce

defects: it begins with design and coding. It is also incremental and has

evaluation and exit points.




Author: Dvorak, Joseph


Title: Conceptual Entropy and its Effect on Class Hierarchies


Publisher: IEEE Computer


Date of Publication: June 1994


Keywords: Risk, class hierarchy, object-oriented programming


Abstract. The author intoduces the concept of conceptual entropy as a valid

concept in analyzing object-based class hierarchies. In this context, a

class hierarchy is a set of object classes that are related to each other

through superclasses and subclasses, that is, through the inheritance

relation defined in object-oriented systems. The author points out that, in

any system which undergoes frequent change, entropy causes the system to

tend toward disorder. Applying this idea to class hierarchies, the author

asserts that class hierarchies tend toward conceptual disorder as the

number of changes applied to them increases. This disorder increases the

risk that the hierarchy will be misused, misunderstood by others, or even

worthwhile at all.


The author illustrates conceptual entropy by describing an experiment he

conducted with computer science students in which each student was asked to

construct a class hierarchy from an actual set of classes extracted from a

Smalltalk library. The resulting hierarchies were compared for superclass

selection (the number of classes which had the same superclass), and

hierarchy level selection (the number of classes at the same hierarchy

level). The results showed that conceptual entropy increased as we travel

down the class hierarchy, largely because the number of options for

classification increases, there was no common viewpoint of the conceptual

architecture, so each student classified concepts according to his/her own



The author provides a quantitative framework for class hierarchy design,

called object-oriented conceptual modeling (OOCM), which minimizes, if not

eliminates, conceptual entropy. The model uses three quantitative metrics

to determine whether a concept should be subclassed (inherited): conceptual

specificity, which measures how specific the class’ concept is; conceptual

consistency, which determines whether two class’ concepts are consistent;

and conceptual distance, which quantifies the similarity between two

classes. The author proposes an algorithm using these metrics which, if

applied to class hierarchies, should minimize their conceptual entropy.



Author: Bellinzzona, Roberto; Fugini, Maria; Pernici, Barbara


Title: Reusing Specifications in OO Applications


Publisher: IEEE Software


Date Of Publication: March 1995


Keywords: Requirements analysis, Reuse evaluation, composition and

tailoring, Detailed design, Implementation.


Abstract: The article is about the development of Ithaca Object Oriented

Methodology (IOOM) which was developed jointly by one of the authors namely

Barbara and another Valeria De Antonellis. The object of this methodology

is to help developers and designers compose new reusable components.

Basically its quite similar to other OO approaches but it starkly differs

from them in its emphasis on requirements collection and analysis as well

as reuse from early development phases. IOOM is based on existing OO

concepts which makes use easier, also it uses the concept of roles which

let its designers and developers separate the concerns and gives the

ability for composing a specification. Lastly IOOM also permits refinement

levels which offer the ability to create specs. At different levels. IOOM

has a unique way of structuring requirements collection , in which the

first step of reuse evaluation is made easier thus enabling developers to

know what can be used in the other processes. IOOM is also compatible with

F-ORM which is Functionality in Objects with Role Models.




Week 1>

22 January

¨       Background; Introductions,

¨       Unit One: Systems Engineering (Systems Definition)

¨       Lecture:  Blanchard Chapter 1

¨       Inclass exercise




Week 2>

29 January

¨       Unit One: Systems Engineering (Lifecycles)

¨       Lecture: Blanchard Chapter 2

¨       Inclass exercise




Week 3>

5 February

¨       Unit One: Systems Engineering (Management)

¨       Lecture: Blanchard Chapter 18, 19




Week 4>

12 February

¨       Unit One: Systems Engineering

¨       Articles on Systems Engineering Due

¨       Group Presentations: Unit One




Week 5>

19 February

¨       Unit Two: Process Improvement

¨       Lecture:  Ahern Part One

¨       Inclass exercise




Week 6>

26 February

¨       Test One:  Unit One

¨       Annotated Outline of Final Paper Due




Week 7>

4 March

¨       Unit Two: Process Improvement

¨       Lecture:  Ahern Part Two




Week 8>

11 March

¨       Spring Break




Week 9>

18 March

¨       Unit Two: Process Improvement

¨       Lecture:  Ahern Part Three




Week 10>

20 March

¨       Unit Two: Process Improvement

¨       Articles on Process Improvement due

¨       Group Presentations: Unit Two




Week 11>

27 March

¨       Unit Three: Configuration Management

¨       Lecture: CM Part 1

¨       Inclass exercise




Week 12>

3 April

¨       Unit Three: Configuration Management

¨       Lecture: CM Part 2

¨       Inclass execise




Week 13>

10 April

¨       Professor at Conference




Week 14>

17 April

¨       Test Two:  Units Two & Three

¨       Final Research Paper Due




Week 15>

23 April

¨       Articles on CM Due

¨       Group Presentations: Unit 3