You need to know about many concepts of computer science, e. g., data structures, programming language design and software engineering. Much of this material has been acquired in previous computer science courses. However, you may have to acquire more.

Also, you will need to have an in-depth knowledge of the application area in which the project's problem resides. This you probably do not possess. How do you acquire the required knowledge base?

You acquire a technical knowledge base through textbooks, articles, your notes and your Project Notebook. You must develop an attitude which fosters learning on your own. The course's weekly meetings will provide direction and outline the concepts and learning processes, but you must apply them to acquire the knowledge base.

You need to learn how to read technical material, think critically about the material, distinguish scholarly works from popular press, critically evaluate the quality of a source and extract useful information.

You will need to acquire organizational skills to cope with the complexity of the material.

"Knowledge is not acquired by osmosis, but by discipline and hard work." [Colson, C. and J. Eckerd, Why America Doesn't Work, 1991, p. 103.]

As new systems analysts, your project team will solve the open-ended problem supplied by your Supervisor (Instructor). Firstly, the team must understand the problem by exploring its scope and implications. This will require a technical investigation and analysis of the application area.

Secondly, the team will formulate alternative solutions. This will require creative thinking skills, e. g., brainstorming.

Thirdly, the team will evaluate each alternative solution. Before the evaluation, the team needs to derive the evaluative criteria including technical aspects both hardware and software; legal aspects, e. g., possible risks and patent infringments; economic aspects and user aspects. Members of the team will need to acquire skill in costing and legal analysis.

Fourthly, the team will select the "best" solution based on their evaluative criteria. In the Feasibility Report, the team will provide convincing evidence for the selection.

Fifthly, the team will perform requirements analysis for the project and write a Requirements Specification Document including evaluation criteria. As part of the final report of the Fall semester,the team will propose a preliminary design for the prototype system.

During the second semester, you will perform a detailed design and implement the prototype system. In May, your team's Final Report will explain the results of testing the prototype to your evaluation criteria.

To explore and express your technical ideas, you will need to apply computer science modeling techniques, e. g., object oriented design and formal language theory. You may also need mathematical modeling techniques, e. g., statistical modeling, queuing theory, differential equations and graph theory.

The team will follow the engineering design process and apply good design techniques.

What the Accrediation Board of Engineering and Technology (ABET) says about engineering design.

A common desgin methodology for software is object-oriented design.

Any software engineering design needs to be tested. You will use a standard design review form for your team Project Reviews.

``The people who succeed in an industrial environment are team-oriented, have leadership attributes, and can express themselves orally and on paper.''

Above quote written by Kenneth Neves in ``Thoughts On CS Candidates For Industrial Positions,'' ACM Computing Surveys, Vol. 28, No. 4es, December 1996.

Since most software and hardware in industry is developed in teams, you need practice in team dynamics and performing in leadership roles.

Planning is the key to a successful team project. We suggest that your team use the three-step stategy as outlined below:

1. Team agrees on purpose, scope and overall technical tasks.

2. Members take assigned tasks and develop detailed plans and solutions.

3. Team reviews members' work frequently and provides feedback.

This strategy combines team work and individual effort; it is effective because it draws on the strengths of both.

Leadership is another key to success. You should elect your leader at the first team meeting. We recommend that each team member's role be rotated.

Effective communication between your team members as well as with your Supervisor is a must. Formal communication lines, e. g., minutes of meetings, memoranda, reports and Project Notebook, are described elsewhere. However, don't ignore that informal communication lines, e. g., email between team members, are important too and fostering them is the responsibility of the team.

Part of a team's organization is configuration management, i. e., keeping a history of all the configurations (versions) of the project. A project evolves over time and sometimes it is important to be able to back up to a previous step. Perhaps, the team decides that a recent design decision was the wrong one and wants to backup and try an alternative. A team should apply configuration management to ideas, designs, reports and programs.

Configuration management is especially important for computer programs since they are so fluid. In the case of programs, a configuration management tool such as RCS can also be used as part of a disaster plan. For example, last one night one of the members of the team accidently does irrepairable damage on a large program file. With RCS, the team can easily retrieve a previous version of the file.

A Project Notebook is a three-ring binder of bound pages in which your team can keep their daily technical and rhetorical work. It allows your team to keep precise and accurate records of what each member is doing. Because no one can remember everything precisely, a written record at the time something happens is the only way to insure accuracy of the event. Obviously, engineers have an ethical responsibility to keep written records that are precise and clear in their Project Notebook.

In order to develop good documentation habits, you must maintain the team's Project Notebook. The Project Notebook Standards describes the procedures for the daily keeping of your team's Project Notebook. You will record such information as literature reviews, bibliographical information, ideas, design notes, team meetings, drafts of reports, critiques of reports and reports. Provided you develop a daily habit of placing information in the Project Notebook, you will be able to write precise and clear technical reports because all the necessary information will be at the team's disposal.

Your project supervisor will periodically read, evaluate, and sign your team's Project Notebook.

For the team project, you must gather information in order to understand and define the scope of the assigned problem. The staff of Bucknell's Bertrand Librarry can assist you to perform a literature search including both manual searches and electronic ones.

If an article or book is not in the library, you may request it from Inter-Library Loan. But remember Inter-Library Loan may take one to two weeks.

The information you collect must be either recorded or enclosed in your Project Notebook.

Since your team will compile a bibliography for inclusion in the technical reports, you must collect the essential bibliographical information on a literature source (Web-based and electronic ones as well as traditional sources) when you are looking at it. Do not reply on your memory! Record the essential information in your personal journal and accurately transcribe it to your team's Project Notebook. Accurary is paramount because the readers of your report may want to consult the original sources of your information.

We recommend BibTex format for compiling the bibliography. However, a MAC-based tool such as Endnotes is also acceptable.

After a team's report is "published," the team will enter the latest important bibliographic entries in the CSCI 475 Shared Bibliographic Database.

You will need to organize your time and interactions with your team members. Your organizations skills will be needed to deal with the technical aspects of the design and, later, the implementation of the prototype. But also, you will need to organize the writing duties of the team. Being organized will be a key to the success of the project.

Further, you will need to acquire organizational skills to cope with the complexity of the application area, e. g., computational biology.

Communication includes reading, writing, listening and speaking.

You will learn to read technical material in order to extract useful material and to critically analyze the quality of the material.

During project reviews and project presentations, you will learn how to critically listen as well as speak.

In the course, you will write notes in your own personal journal, notes in the team's Project Notebook, memoranda, article reviews, research paper and technical reports, e. g., Feasibility Report, Requirements Specification Document. Also, your team will write a User's Manual and a Technical Manual. You will be become aware that a technical report is a living document. You will not view the report as an ugly burden needed to be written after all the technical fun is completed. You should view the process of writing as a mode of thinking and a way of clarifying your ideas. And you should use this mode of thinking early and often during the lifetime of the project.

You must use a word processor for all your memoranda, papers and documents. I suggest you use the LaTex document preparation tool on the Sparc workstations. Although LaTex is not as friendly as, for example, Microsoft Word on the Mac, it is virtually a standard for computer science departments around the world! If you have your own Mac or IBM PC compatible, a free version of LaTex may be obtained from the Internet or from individuals on campus.

One advantage of using LaTex is that it ``automatically'' pulls the bibliographic references from a BibTex database. A further advantage is that a LaTex document is just an ACSII text file. This means a variety of Unix tools can be used on the file such as RCS to save revisions. Also, a text file is easily sent by email to colleagues around the world.

One criterion for the comparison of alternative solutions is their economic impact on the organization. You will use such economic aspects as hardware costs, network costs, software development costs, royalty costs, maintenance costs and legal costs.

Another criterion is the legal aspects of each alternative which includes liability issues, patent infringements, copyright infringements, trade secrets and other issues of intellectual property. Also, you should be concerned for an individual's privacy and protect freedom of expression.

As citizens in our society, systems analysts must observe the conventional ethics of "obey the laws of the land" and "observe the golden rule," that is, "do unto others as you would have them do unto you." However, systems analysts must also observe professional ethics that protect the public interest, because systems analyst develop systems that can effect the public welfare. Failures or improper designs can have a devastating effect on an individual or group of individuals. A large collection of such computer-based failures can be found at The Risks Digest.

The purpose of professional codes of conduct is to protect the public interests. As a systems analyst you must develop a conscientious attitude and avoid the sins of incompetence. You must work hard, pay attention to detail, and take pride in your work. Furthermore, you must not "pass the buck" but accept your professional responsibilities.

You will follow the Association for Computing Machinery's (ACM) Code Of Ethics and Professional Conduct and ACM's Software Engineering Code of Ethics. Please read both documents carefully.

Also, you should be aware of the workings of the following organization Computer Professionals for Social Responsibility - CPSR. We encourage you to join.