CSc 4330 Software Systems Development
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,
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
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
Detailed Design Documents
and Test Plans 4/01/04
Code Completion Target 5/04/04
All Material Due 5/06/04
"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
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
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,
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:
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
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)
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)
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
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.