CSc 4330 Software Systems Development
Spring
2004
Course: TTh 9:10-10:30 am Lockett
005
Instructor: Donald H. Kraft Office: 286 Coates Phone: 578-2253
Office Hours: TTh 10:30am-Noon, 3:00-4:30pm
Text: Sommerville, Ian, Software
Engineering, 6th edition, Reading, MA: Addison-Wesley Publishing Company,
1995, QA76.758.S65
References: There may be additional readings from a variety of
sources, including other books, technical reports, conference proceedings, and
journal articles. Some of those books are listed below:
Kling,
R. (ed.), Computerization and
Controversy: Value Conflicts and Social Choices, 2nd edition,
San Diego, CA: Academic Press,
1996, QA76.9.C66C377
Pfleeger,
S. L. Software Engineering: Theory and
Practice, Upper Saddle River, NJ: Prentice-Hall,
1998, QA76.758P49, ISBN
0-13-624842-X
Pressman,
Roger S., Software Engineering: A
Practitioner's Approach, 5th edition, New York, NY:
McGraw-Hill, 2001, QA76.758.P75
Peters,
J.F. and Pedrycz, W., Software
Engineering: An Engineering Approach, New York, NY: John
Wiley
& Sons, Inc., 1999, QA76.758.P45
Braude,
E.J., Software Engineering: An
Object-Oriented Perspective, New York, NY: John Wiley &
Sons,
Inc., 2001
Schach,
S.R., Classical and Object-Oriented
Software Engineering: With UML and C++, 4th edition,
Boston, MA: McGraw-Hill,
QA76.758.S318
Eriksson,
H.-E. and Penker, M., UML Toolkit,
New York, NY: John Wiley & Sons, Inc., 1997,
QA76.64L45
In addition, there are
journals with articles of interest, including the ACM Transactions on Programming Languages and Systems, IEEE Software, and IEEE Transactions on Software Engineering.
Abstract: Software engineering, or software systems development,
is concerned with problems relating to the application of sound engineering
principles to the production of quality software. This course involves a broad
range of topics including: theory and examples, history of software
development, current methods, human issues, and computer aided software
engineering (CASE), as well as modern approaches such as object-oriented
development, metrics and cost estimation, process considerations, and new
applications such as software reuse.
Prerequisites: CSc 3102 Advanced Data Structures and Algorithm
Analysis
Grading:
Research Paper(s) 20%
Computers
in Society Paper 15%
Term
Project 40%
Final
Exam 20%
Class
Participation & Assigned Homework 5%
In the course, all of you will
be asked to do a research paper, along the lines of a
bibliographic essay, on a given topic related to current methodologies,
research ongoing in the field, and/or new applications. Sample paper
topics, all specifically related to software, include:
Metrics Reuse Standards
Reverse Engineering Re-engineering UML Tools and Methods
Modern CASE Tools Human Factors Formal Models for SE
Designing Applets (WWW) Cost Estimation Testing
Designing User Front-Ends Software Personnel Management Logical
Database Design
Project Management Programming Environments
The paper should be on the
order of ten pages (do not take that
number too literally!). Please note that you need to consult the research
literature (at least three articles in
scholarly journals or technical conference proceedings) in software
engineering, although you can consult books, too, and the WWW. You must go beyond defining
terms (e.g., what is “object oriented programming”) and discuss what the
current research says.
A second paper will be required for graduate students seeking graduate
credit in this course, and both the topic and the
paper itself are due at the same times as
the first paper (see below). This second paper must be more detailed with even more
emphasis on research issues (requiring more research articles) and must be on a
different topic than the
first paper.
Another
paper is due, for all
students, on a subject related to computers in society. This
includes such topics as the role of information technology in society,
technological utopia, economics of information, cultural and organizational
influences of information, transformation of work, social relationships,
privacy, social control, safety, intellectual property, and ethics. This paper
should be on the order of five pages
(do not take that number too literally!). The Kling reference might be helpful.
This paper should be written from the perspective of you being a consultant to
a business, and present your opinions of the issues, problems, and approaches
to solutions.
For all of these papers,
they should consist of bibliographic essays, each describing a concept and relaying the state‑of‑the‑art
in terms of the topic of the assignment (in other words, do not provide
a tutorial, rather, focus on research). The choices of topics must be
approved by the instructor and must be specified in writing by February 5,
2004; the papers will be due by April 15, 2004. Late
papers don’t get credit, no excuses! Do not simply concatenate several
abstracts from papers, and do not rely solely on textbooks; do weave a
pattern of what is going on with the topics selected. This should be based upon
the open literature in the field, especially in terms of journals, conference
proceedings, technical reports, and, perhaps, even web sites if needed). Do not
forget to list your references and to use
them, citing them in the papers. Most importantly, do not simply copy
entire sections, or even papers or web pages, especially without citing them;
it is academically dishonest as well as intellectually dishonest; you will be
caught and violators will be prosecuted.
A team project, involving the design and
implementation of a relatively small, computerized information system, is also
required, and which will count for part of the total grade (including
individual performance on the team project, team performance on the project,
and the project itself). The theme for this year's group project is presented
in a separate handout.
Your
team organization is critical to the success of the project. Teams should
consist of 3-5 people, preferably with differing backgrounds, skills, and
abilities. It is strongly recommended that you choose a "team leader"
or "captain." The leader will not be responsible for doing all
of the work. The leader will do part of the work but will also ensure that:
1. Tasks are assigned to suitable team personnel;
2. Tasks are evenly distributed to team personnel;
and
3. Meetings are scheduled in a timely manner and run
efficiently.
Coordination
of effort is vital! Due to the limitations imposed by the time available (until
the "end of the semester," project schedules must be kept on target
if at all possible. You must provide notification of your team membership,
including designation of a team captain, and upon which project you propose to
work, all by February 6, 2003. In addition, the following
milestones are provided:
One
important issue is that all team members must contribute to the final
project. If a team finds that a subset of that team is not pulling their load,
they must contact me immediately and schedule a group meeting to discuss
this and find a solution; do not wait until the end the semester to point out
such problems.
System Requirements 2/12/04
Requirements Specification 2/26/04
Preliminary Design Documents
(Architectural) 3/18/04
Detailed Design Documents
and
Test Plans 4/01/04
Walkthrough 4/13/04-4/15/04
Code Completion Target 5/04/04
All Material Due 5/06/04
Implementation
and
Demonstration 5/04/04-5/06043
"All
Material" includes the implemented system; code listings (perhaps in
electronic format, e.g., on a disk); final versions of the requirements, design
specifications, test plans, implementation plans, and maintenance plans; and
the users and programmers manuals.
These, plus a working system are the “deliverables.”
No
late work, e.g., walkthrough presentations or final demonstrations, will be
accepted. Make-up on exams will not be given. Exceptional cases, such as
illness or accidents, will be handled on an individual basis (Instructor must
be notified prior to the test of the problem and proof presented - otherwise a
score of zero will be given). Students will have one week from
the date an assignment or homework or test is returned to seek corrections on
the grading. After that time, no changes will be made to scores. All
assignments will be due on a specific date and must conform to the guidelines
in the CSC Program Requirements Guide. The individuals in the group must do
programs for the project; collaboration across groups beyond discussing the
issues of what is required for the project is prohibited. All cases of
plagiarism or excessive collaboration on assignments or tests will be treated
as academic dishonesty.
Homework may be assigned from time to time in
class. Written answers are due at the beginning of the class period on the due
date given. The homework grade(s) will be part of the participation
portion of your final grade.
Topics to be covered include:
Introduction Text, Chapters 1-3 1/20/04-1/27/04
Software
Engineering, Software Life Cycle
Requirements Text, Chapters 5-9 1/29/04-2/03/04
Requirements Engineering, Requirements Analysis,
System Models, Requirements Definition and
Specification,
Specification, Model-Based Specification
Software Prototyping, Formal Specification, Algebraic
Computers in Society Kling 2/05/04-2/10/04
System Requirements Due
Software Design Text, Chapters 10-15 2/12/04-2/19/04
Software Design, Architectural Design,
Object-Oriented
User Interface Design
Design, Function-Oriented Design, Real-Time System
Design,
Mardi Gras Holiday 2/24/04
Requirements Specification Due
Implementation Pfleeger, Chapter 7 2/26/04-2/26/04
Coding
Dependable Systems Text,
Chapters 16-18 3/02/04-3/0-9/04
Software Reliability, Programming for Reliability,
Software Reuse, Safety-Critical Software
Preliminary Design Documents
(Architectural) Due
Verification and
Validation Text, Chapters 19-21 3/11/04-3/18/04
Verification and Validation, Defect Testing, Static
Verification
Delivery Pfleeger,
Chapter 10 3/23/04-3/30/04
Detailed Design Documents and Test
Plans Due
Spring Break 4/06/04-4/08/04
Walkthroughs 4/13/04-4/15/04
Maintenance Text, Chapters 26-29 4/20/04-4/22/04
Software Maintenance, Configuration Management,
Software Re-Engineering Management
Management Text, Chapter 4,22-25 4/27/04-4/29/04
People,
Software Cost Estimation, Quality Management, Metrics,
Process
Improving
Project Demonstrations 5/04/04-5/06/04
Implementation and
Demonstration
Code Completion Target, All Material Due
Final Exam Tuesday 5/11/04 5:30-7:30 pm
Things to Ponder for Your Project:
System Requirements
I. Product Definition
Problem statement,
Functions to be provided, Processing environment (hardware and software), User
characteristics, Solution strategy, Product features (prototype, modest, and enhanced
versions), Acceptance criteria, Sources of information, and Glossary of terms
II. Project Plan
Life-cycle model
(terminology, milestones, work products), Team structure, Development schedule
(milestones and reviews), documents to be prepared, Manner of demonstration, Sources of information, and
Glossary of terms
Software Requirements Specification
Section 1: Product
overview and summary
Section 2: Development,
operating, and maintenance environments
Section 3: External
interfaces and data flows (User displays and report formats, User command
summary, High-level data flow diagrams, Logical data sources and sinks, Logical
data stores, Logical data dictionary)
Section 4: Functional
specifications
Section 5: Performance
requirements
Section 6: Exception
conditions and exception handling
Section 7: Early subsets
and implementation priorities
Section 8: Foreseeable
modifications and enhancements
Section 9: Acceptance
criteria (Functional and performance tests, documentation standards)
Section 10: Design
guidelines (hints and constraints)
Section 11: Sources of
information
Section 12: Glossary of
terms
Design Documentation
I. External design
specifications (User displays and report formats, User command summary,
Detailed data flow diagrams, Logical data stores, Logical data dictionary, and
logical format of data files and data bases)
II. Architectural design
specifications (Structure diagrams, Parameter specifications, Logical data
structures, and functional descriptions)
III. Detailed design
specifications (Subprogram interface specifications, Documentation prologue for
each routine, Pseudocode for each routine, Physical data structure and data
file specifications, and Packaging specifications)
Test Plan
Each test case should
provide the following information (Type of test - functional or performance or
stress or functional, Machine configuration, Test assumptions, Requirements
being tested, Exact test stimuli, and Expected outcome - be precise)
I. Functional tests
(Nominal inputs - expected results, Boundary conditions - minima and maxima,
Logically related inputs - correct and incorrect relations, Special values -
empty files or 1x1 matrices, and Default initial values)
II. Performance tests
(Response and execution and throughput times, Memory and channel and bus
utilization)
III. Stress tests
(Intentional attempts to break system)
User's Manual
I. Introduction (Product
rationale and overview, Terminology, Basic features, Summary of display and
report formats, and Outline of the manual)
II. Getting started
(Sign-on, Help mode, and Sample run)
III. Modes of operation
(Commands and displays and options)
IV. Advanced features
V. Command syntax and
system options
Team
Project
Consider
the problems of managing a professional society journal, the Journal of the
American Society for Information Science and Technology (JASIST). What is needed is a comprehensive journal
management software package to keep track of the papers, the authors, the
referees, the published papers, and so forth in a reasonable manner. This
project has been considered before but not with all the bells and whistles that
are now required. For journal details,
check out http://www.csc.lsu.edu/~kraft,
and click on links on the left with JASIST in the name. Of course, part of the problem is to allow
the Editor to better control and manage the journal.
Consider
a paper being submitted to the journal by an author or several authors. One
must log in the paper, which can be submitted in hard copy, although many are
now coming in electronically via email.
Each paper is given a control number (e.g., 03213). The Editor must select referees based on a)
their knowledge of the subfield of the paper, b) their not being overworked
reviewing other papers for JASIST, c) their record of timeliness and
reasonableness, and d) their having no direct relationship with the authors of
the paper in question. If the paper is
submitted electronically, the referee should get an email with the title and
abstract, and if he/she is willing to referee, then an email with the full
paper. If the paper has been submitted
via hard copy, a copy is sent to the referee via regular mail. Of course, a letter acknowledging the
submission is sent to the corresponding author, and email copies of that letter
are sent to all authors whose emails are known.
Late
referees must be nagged, so a reminder service is needed. Once all of the reviews are in, and are
usually on a special form, the Editor determines if the paper is to be a)
accepted, b) rejected, c) subject to major revisions and needing to be refereed
again, or d) subject to minor revisions not needing further refereeing. A letter with referees’ comments must be
sent to the corresponding author. If
a paper has mixed reviews, i.e., one referee says no while the other says minor
or yes, respectively, or if the first referee says major and the second referee
says yes, then the author must be told and the paper sent to a third referee to
break the tie.
Papers
under major revision status, when revised, are sent to at least one of the
original referees, usually the more critical one, with an email to the
corresponding author noting receipt of the revision. If the referee indicates that still more major revisions are
needed, the paper is rejected and the corresponding author is notified via
letter. Papers under minor revision
status are reviewed by the Editor and usually accepted, with a notification
letter to the corresponding author.
If
a paper is determined to be unacceptable, then the author must be sent a letter. If a paper is to be accepted, then the
author is sent a letter asking for a) original artwork for all figures if we do
not have them, b) the email addresses of all authors if we do not have them, c)
the copyright transfer form if we do not have it after the acknowledgement
letter, d) a disk with the electronic version of the paper in proper format,
and e) the final electronic submission form.
The package must be complete before being sent to the publisher. When the paper is sent to the publisher, it
is given a new JA control number (e.g., JA2014) and a cover form, noting the
number of pages and figures and tables, is generated as part of the package.
Once
the accepted paper is given a publication date from the publisher, the list of
referees is updated and the hard copy file is deleted.
Some
complicating factors include: a) the journal is a professional society journal
but is published by a commercial publisher (John Wiley & Sons, Inc.); b)
while some articles are submitted electronically originally, but not all are,
and some are sent via hard copy originally but revisions or final drafts are
sent electronically; c) while I try to send hard copy letters with forms for
all cases, I try to send a copy of those electronically, too; d) often authors
do not send all the materials together for the final package for accepted
papers so we have to hold onto the papers until we have everything; e) once the
publisher gets the final package, they copyedit the paper and generate a pdf
file of that paper, sending it by email to the corresponding author to approve
– some authors make small changes – and once it is approved, it goes on the
publisher’s web site for the journal under EarlyView; f) once the paper comes
out in print, and we run fourteen issues per year, the EarlyView draft is
deleted by the publisher and the pdf version from the print journal is on the
web site; g) authors are asked to note if they have a version of the paper on
their personal web site to cite their paper in the journal; h) statistics are
needed on the referees and the papers; i) access is needed to the log by
authors’ names, titles, control numbers, and referees’ names; j) papers under
ten pages long are considered Brief Communications and require only one referee
rather than the two for regular research papers; and k) reviewing is
single-blind, i.e., reviewers know the authors’ names but authors cannot know
the referees’ names.
Some
even more complicating factors include: a) the journal also publishes Letters
to the Editor and Book Reviews, which get JA numbers; b) the journal publishes
Perspectives and Special Topic Issues, which are handled by guest editors but
whose papers get JA numbers; c) papers older than two years that have not been
processed are usually rejected
administratively by the Editor; d) the journal changed its name in 2001 from
the Journal of the American Society for Information Science (JASIS); e)
the Publisher keeps a version of the Journal online at its web site with a
somewhat complicated structure (JASIST and JASIS are seen as
separate, only ASIST members and people at institutions who have an
institutional subscription such as LSU can get full text); f) it would be nice
to maintain a list of referees with names and addresses and subject interests,
as well as past performances as referees; g) sometimes authors send the
original in hard copy but email the revision to the Editor; h) the list of
current referees must be maintained and input into the new system and
occasionally printed out (names only in alphabetic order) to publish in the
Journal to thank them.
I need several teams, each consisting of approximately five-or-so students, to handle this project. The teams are considered part of a class super-team, which will have the responsibility of creating the entire journal management system. Together, we will delegate one of the subprojects to each team. I envision teams working on modules, including authors, papers, referees, electronic submissions, emails, letters, logs, statistics, backup and security, front-ends, and querying the logs (e.g., finding out which paper a given referee is supposed to be doing). Your teams must be formed by the end of the third week of class, including the designation of a team captain. You must inform the instructor of your team and team structure at that time. Consider what part(s) of the entire problem your team would like to tackle and solve. Moreover, you need to be aware that the rule is in effect that the bigger the team is, the more that is expected of them. Perhaps we can have two super teams in a sort of friendly competition with each other.
Note that your
instructor serves as both funder and user of your proposed system. Your team
will be graded as one unit in terms of the effort expended on your subsystem.
You should know the emphasis is on the software engineering effort and
documentation, rather than on the working subsystem itself (although you must
have a working subsystem). You should provide proper visual aids for
your documentation, e.g., flow control charts, data flow charts, E-R diagrams,
or UML charts. Again, since we will be dividing up the labor across teams, with
one team doing one part, another team doing another part, and so on, so there
will be a great need for coordinating (i.e., integrating) the modules into an
overall project software.