|
Professor: |
Dr. Peggy Brouse |
|
|
|
|
Work Phone: |
(703) 993-1502 (with voice mail) |
|
FAX: |
(703) 993-1706 |
|
E-mail: |
|
|
Office: |
GMU: Science
and Technology II - Room 317 |
|
Office Hours: |
Thursday |
|
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 |
|
Text: |
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 |
|
Grades: |
15%
- Refereed journal articles (5% for each unit) |
|
|
25%
- Group presentation |
|
|
30%
- Exams (15% for each exam) |
|
|
30%
- Final Paper |
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.
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.
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
published]
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:
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
view.
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 |