1

The Electronic Stamp Mail Server and Client

Project Plan Part 1: Software Development Plan

by

SDP Draft 2 September 10, 2003

2

This Project Plan was prepared and provided as a deliverable for Florida State University, Software Engineering Class, CEN 5035, for Fall Term 2003. This document is based on the IEEE 1058-1998 Standard for Project Management plans. _________________________ Gabrielle Reed, Project Manager _________________________ E Shen, Repository Expert _________________________ Stanislav Ustymenko, Project Leader _________________________ Yunwei Wang, Technical Leader

3

Change History

Revision Date Author Section/Pages Affected

Remarks

Draft 1

September 4, 2003

R. G. Reed E Shen Stanislav Ustymenko Yunwei Wang

All

Initial

Final September 10, 2003.

R. G. Reed E Shen Stanislav Ustymenko Yunwei Wang

All Revisions based on Dr. Baker’s Review.

4

Preface This document is prepared as part of the requirements for Software Engineering class. The information contained within is based on preliminary information provided in the text books, the Software Engineering Class, and website. As plans, methods and techniques are learned in the Software Engineering class, they will be added to this document. We would like to thank the PALS Learning Systems Institute at the College of Education for the use of equipment and software provided under National Science Foundation Grant # IIS-0218692.

5

Table of Contents 1. Overview 1.1. Project Summary 1.1.1. Purpose, scope and objectives 1.1.2. Assumptions and constraints 1.1.3. Project deliverables 1.1.4. Schedule and budget summary 1.2. Evolution of plan 2. References 3. Definitions 4. Project organization 4.1. External interfaces 4.2. Internal structure 4.3. Roles and responsibilities 5. Managerial process plans 5.1. Startup-plan 5.1.1. Estimation plan 5.1.2. Staffing plan 5.1.3. Resources acquisition plan 5.1.4. Project staff training plan 5.2. Work plan 5.2.1. Work Activities 5.2.2. Schedule allocation 5.2.3. Resource allocation 5.2.4. Budget allocation 5.3. Control plan 5.3.1. Requirements control plan 5.3.2. Schedule control plan 5.3.3. Budget control plan 5.3.4. Quality control plan 5.3.5. Reporting plan 5.3.6. Metrics collection plan 5.4. Risk management plan 5.5. Closeout plan 6. Technical process plans 6.1. Process Model 6.2. Methods, tools and techniques 6.3. Infrastructure plan 6.4. Product acceptance plan 7. Supporting process plans 7.1. Configuration management plan 7.2. Verification and validation plan 7.3. Documentation plan 7.4. Quality assurance plan 7.5. Reviews and audits 7.6. Problem resolution plan 7.7. Subcontractor management plan 7.8. Process improvement plan 8. Additional plans Annexes

Gantt Chart Pert Chart

Index

6

List of Figures 4.2 Figure 1. Team Organizational chart

7

List of Tables 1.1.4. Table 1. PERT (Technology Task Flow) chart with major tasks from the Engineering Software Website. These reflect the tasks associated with the development model. (See Annexes) Table 2. GANTT chart with major tasks from the Engineering Software Website. These reflect the tasks associated with the development model. (See Annexes) 4.2 Table 3. Team members, team assignment and contact information. 5.2.2 Table 4. Work Breakdown Schedule. The Preliminary determination of staffing time needed per month for the duration of the project.

8

1. Overview

1.1. Project Summary

1.1.1. Purpose, scope and objectives This document will be used to plan the software design project of an Email Stamp vendor Server and an Email client that utilizes the Email Stamp. This type of system is proposed to help combat the onslaught of spam in email inboxes. Current filtering software has be determined to help only superficially.[Personal Experience, 2003]. Maintenance on this system is expected to be no more demanding than the current email client systems. The use of email stamp will impact many users who correspond to those who require email stamps. The training of these individuals can be done by automatic response to emails without the stamp of where to purchase the stamp and how to use it. This is going to difficult to implement due to the “free” culture of internet. The prototype will be demonstrated and final report will be provided for the final acceptance by the client.

1.1.1.1. System Level Project Description This project is to develop an email stamp system prototype composed of an email stamp vendor, email client, and SMTP server. The Stamp Vendor is to operate on top of the TCP/IP Internet protocol. It is expected to be available from anywhere on the Internet. The email client runs locally on a workstation. This will enable client to read email even if the internet is not available.

1.1.1.2. System Description This prototype system will encompass aspects in the white paper, “A Method of Limiting Unwanted E-Mail Using a Form of Electronic Stamp”, provided by Dr. Baker.

1.1.1.3. Development hardware/software Hardware: The system is intended to be platform independent. A number of scenarios with existing hardware will be performed. Both Apache web server as well as IIS is available for research. Software: The development software will be determined within the next week. Product is expected to meet the SMTP, POP3 standards.

1.1.2. Assumptions and constraints

1.1.2.1. Performance measures and values expected E-mail client that uses the stamps should also read previous mail format as well. This Backward compatibility is required to work with all existing mail programs. It is should have 100% compatibility with existing email protocol.

9

The system uses existing SMTP Internet protocol. The system passes when it meets the standards protocol. The issuing and usage of the stamps are to be resistant to the forgery of stamps. This is assured by using public-key encryption, with the current acceptable practice in length of key. The client using the stamps should not be hindered in message format or length. The stamp location within the email should not restrict the content of the email message. The use of the stamp will be reviewed to see if it interferes with the size of a message. Application will apply the stamp prior to sending Reading/sending emails with stamps should not impose a significant time lag compared to reading/sending normal email messages without stamps.

1.1.2.2. Availability The email client runs on local machine. The stamp vendor and SMP server will run 24/7 hours on the server side.

1.1.2.3. System response time.

With the addition of the stamp vendor in the loop, the system should not perform more that 10% percent below the performance the unmodified mail program.

1.1.2.4. Database response time

An e-commerce system will be tested and metrics will be determined for each transaction. The database will contain the e-commerce records. The system is not to impact the database response time. This will not be included in this first stage prototype.

1.1.2.5. Number of transactions per second The system is designed so that there will not be noticeable lag after the implementation of the vendor program.

1.1.2.6. Other measures The following list will be reviewed for relevancy relative to the user’s specification and incorporated as appropriate.

Number of simultaneous users; Simultaneous number of connections supported; I/O channel utilization; Backup & recovery;

1.1.3. Project deliverables The following is a short list of the major deliverables according to the Gantt chart:

A secure stamp vendor prototype; Client email software prototype; User manual (sever and client) design;

10

Software development documentation and Source and source documentation; User training plan design;

1.1.4. Schedule and budget summary

Table 1. PERT (Technology Task Flow) chart with major tasks from the Engineering Software Website. These reflect the tasks associated with the development model. (Source: http://ww2.cs.fsu.edu/~shen/sweng/segyprojectPert.pdf )

11

Table 2. GANTT chart with major tasks from the Engineering Software Website. These reflect the tasks associated with the development model. (Source: http://ww2.cs.fsu.edu/~shen/sweng/segyprojectGantt.pdf )

1.2. Evolution of plan

The different versions of the plan will be maintained on our website at http://ww2.cs.fsu.edu/~shen/sweng/index.htm .

12

2. References Baker, Theodore, “A Method Of Limiting Unwanted E-Mail Using A Form Of Electronic Stamp”. (Confidential) http://www.cs.fsu.edu/~baker/sweng/restricted/assign/antispam.txt Baker, Theodore, "Software Development Plan", Software engineering course website http://www.cs.fsu.edu/~baker/sweng/restricted/notes/SDP.html. (c) 2003 IEEE standards for project management 1058-1998. The entire guideline was used in this document. Available at http://membres.lycos.fr/benoitouellet/IEEE_1058_Project_Management_Plan.pdf . Klensin, J., Editor “RFC 2821 Simple Mail Transfer Protocol (SMTP)” © The Internet Society April 2001 Available at http://www.ietf.org/rfc/rfc2821.txt Myers, J. & Rose, M., RFC 1939 “Post Office Protocol - Version 3”, May 1996, © The Internet Society, Available at http://www.ietf.org/rfc/rfc1939.txt Resnick, P., Editor, RFC 2822 dated April 2001 " Internet Message Format" © The Internet Society This defines the format for the syntax and headers that make up email messages. Available at http://www.faqs.org/rfcs/rfc822.html.

13

3. Definitions SMTP: Simple Mail Transfer Protocol (SMTP), documented in RFC 2821, is Internet's standard host-to-host mail transport protocol and traditionally operates over TCP, port 25. In other words, a UNIX user can type Telnet hostname 25 and connect with an SMTP server, if one is present. POP3: Post Office Protocol 3: The protocol used in communication between the e-mail client and post office server. Basic Mail Message format RFC2822: IETF standard electronic mail message format with header and content descriptions. Email-stamp: This is an electronic stamp that is generated using information particular to the sender of the email, the dates of validity, and the vendors ID. The stamp is encrypted using the private key of the vendor, with the public key available to confirm that it is not a forgery. Stamp vendor: E-commerce server that generates the Email-stamp that allows set up and use during the process of sending an email. Email client: Any email client that supports the SMTP mail protocol. Email-Stamp-client: The email client with the additional functionality to sort incoming email by categories of stamped or not.

14

4. Project organization

4.1. External interfaces Dr. Baker, negotiating on weekly bases, publishes our deliverables every week. TelTech Alliance is our external interface. They are going to review our prototype for feasibility of use.

4.2. Internal structure

Name Title Email Home Work

Gabrielle Reed Project Manager 562-3442 644-0149 (M,W,F)

487-3711 (T,R)

E Shen Repository Expert 445-0136 644-0149

Stanislav Ustymenko Project Leader 575-0804 NA

Yunwei Wang Technical Leader 576-0690 921-2054

Table 3. Team members, team assignment and contact information.

Figure 1. Team Organizational chart

15

4.3. Roles and responsibilities This responsibilities are adopted from the Project Team guidelines. These will be modified as duties are distributed with the project development.

PROJECT MANAGER has the responsibility of setting up all meetings of the team, managing meeting, calling meeting to order, setting meeting agenda, conducting, and dismissing meeting organizing next meeting , responsible for compiling "original project deliverables" which has been accomplished by all team members

PROJECT LEADER has the responsibility of directing the project therefore leading the project portion of the meeting, reporting to professor project issues not resolvable in the team and settling team and project disagreements, (minutes are required each week This is the only one who can bring a personnel issue to professor - usually cost points.

TECHNICAL LEADER is responsible for getting ready (in final form) all "project deliverables" with the help of the team prior to publication, checking for consistency of deliverables.

REPOSITORY EXPERT is responsible for publishing project deliverables on the web, and compiling minutes of the meeting, posting minutes to the deliverables.

16

5. Managerial process plans

5.1. Startup-plan

5.1.1. Estimation plan This project will begin September 3, 2003 and end December 5, 2003.

5.1.2. Staffing plan This project will use four highly qualified professionals in field of computer science. Their previous and currently held positions encompass database analyst; computer analyst II; software engineer; public relation specialist. The team will function until the project is done or the end of the fall Semester 2003, whichever comes first. The following are additional individuals/ resources needed for the completion of the project:

Dr. Baker as consultant for client needs. A Security specialist as consultant or Security Resources An e-commerce specialist or e-commerce resources.

The team is currently democratic centralized. We will be meeting in a central location, and self assigning tasks and discussing the remainder. All project content is discussed and planned out in the meeting. (see section 4.2 for more information) The users of the system, email clients are not organized. The user of the system for the purpose of testing will be the team member who is not responsible for the development of the component that is under testing.

5.1.3. Resources acquisition plan We need a group website to exchange files, set up team webpage, and version control tool; We currently have access to a web design station, a software development station and a project planning station. We also have access to an apache and an IIS web server.

5.1.4. Project staff training plan The following have been determined as areas requiring staff training and additional resources:

Version control, Unix group capabilities and use, SMTP protocol; Public-key encryption methods, Microsoft project, Review of Uniform Modeling Language, Review of Java, Enterprise Java and Java Servlets

17

5.2. Work plan

5.2.1. Work Activities All team members participate in Weekly meetings; prepare for meetings; research into each topic area to be discussed at the meeting and participate in documentation requirements and prototype development;

5.2.2. Schedule allocation The team members are expected to contribute about 10 hrs a week on the plan, design and implementation and testing.

Name September October November December total R. G Reed 40 40 40 10 130 E Shen 40 40 40 10 130 Stanislav Ustymenko

40 40 40 10 130

Yunwei Wang 40 40 40 10 130 Total Project 160 160 160 40 520 hrs

Table 4. The Preliminary determination of staffing time needed per month for the duration of the project.

5.2.3. Resource allocation

All Team members have access to the Unix group; access to yahoo group; access to CS major computer lab, internet resources; Some individual has access to MS Project, Visio, IIS.

5.2.4. Budget allocation Our team members donate supplies for meetings and plan for a completion party at the end of the term. Team members donate work time as outlined in 5.2.2. Equipment is provided by the Computer Science Department at Florida State University. Additional resources are available through the generous funding of NSF for the PALS Learning Systems Laboratory.

5.3. Control plan

Design Reviews These reviews deal with the design and coding checks, and concerned with correctness. Design reviews will be conducted for good use of design patterns and reuse. Design reviews will be conducted on weekly bases, assuring the adequacy the specification and the demonstration of good design principles and sound software-engineering practices.

18

Management Reviews These reviews deal with the project checkpoints, plans, and schedules. Planning charts and design timeline will be checked on a weekly basis. Quality Reviews These reviews cover the technical reviews of quality of deliverable products standards adherence, and documentation. Technical reviews will be conducted at the end of each phase of development for the quality of deliverable products, standards adherence, and adequacy of the documentation. End Product Reviews This review deals with the outcomes: no action, refer for repair, and the need to reconsider the overall product. The internal review will be at the final meeting of the team. Internal reviews will be conducted at the end to check for completeness. The Project will be presented to Dr. Baker and TalTech Alliance for external product review.

5.3.1. Requirements control plan (to be filled out as a part of requirement analysis )

5.3.2. Schedule control plan Check schedule weekly

5.3.3. Budget control plan During the weekly review of our time budget, we will compare the time spent with the amount of time allotted for each task. From this, we will be able to make realistic estimation of what we can accomplish within the remaining time.

5.3.4. Quality control plan Technical leader will assure a consistent level of quality of all the deliverables

5.3.5. Reporting plan Repository expert will post and assure the adequate format of the weekly deliverables.

5.3.6. Change management plan Project manager will make modification to plan when it is deemed as appropriate by the team members.

5.3.7. Metrics collection plan Project leader will coordinate the final metrics and testing of the plan

19

5.3.8. Risk management plan The Risk of the entire system will be analyzed. Each of the risk areas pinpointed will be researched by team members who will work through possible solutions and proactive measures with respect to risks.

5.3.9. Closeout plan A binder with all the associate plans, codes, help files, training plans will organized and be available electronically on the website.

20

6. Technical process plans

6.1. Process Model The team has chosen the "Waterfall with backup" as a model for the development process of this project.

6.2. Methods, tools and techniques The JSK 1.4; Application server; Java Free Email client; E-Commerce software; J builder; Java email server; UML modeling using Rational Rose or Visio; Project Managing tool.

6.3. Infrastructure plan Our team plans to do the initial version using a UNIX operating system, perform the design drawings and design specifications using Rational Rose or Visio; We will be using a design workstation; development station with J-builder; Email server for test prototypes; development server for e-commerce and stamp issuing systems.

6.4. Product acceptance plan Deliverables will be reviewed and approved by the developers, users, before final signature by project manager.

21

7. Supporting process plans

7.1. Configuration management plan Design will be changed according to initial specification.

7.2. Verification and validation plan

7.2.1. Performance measures and values expected

Client that uses the stamps should also read previous mail format as well. This Backward compatibility is required to work with all existing mail programs. It should have 100% compatibility with existing email protocol. The system uses existing SMTP Internet protocol. The system passes when it meets the standards protocol. The issuing and usage of the stamps are to be resistant to the forgery of stamps. This will be assured by using public-key encryption, with the current acceptable practice in length of key. The client using the stamps should not be hindered in message format or length. The stamp location within the email should not restrict the content of the email message. The use of the stamp will be reviewed to see if it interferes with the size of a message. Application should apply the stamp prior to sending

7.2.2. The system will be tested to see whether it works. It can encrypted a stamped; sell a stamp; insert stamp in a email; sort the email by category.

7.2.3. The team will review the adequacy of the test.

7.3. Documentation plan A standard will be selected for each deliverable. It will be clearly documented in the document.. It will be selected based on its appropriateness to the project and its acceptance to the field. All deliverables will be submitted using this standard. The deliverables will be submitted according to milestones in the development model and deliverables calendar on the SWENG website. The following describes documentation that will be retained in the process of this project:

Documentation will be retained for all decisions.; IEEE standard deliverables of the waterfall model will be used for administrative reports; UML will be used to document all technical deliverables; Minutes will be taken and saved for all meetings; Major decisions on project details, and team assignments will be documented; A list of outstanding issues will be updated every week.

7.4. Quality assurance plan

22

One person assigned to be quality assurance person to monitor quality to make sure the deliverables are delivered “on time” “sufficient to do the job”

7.5. Reviews and audits All deliverables will be reviewed by internal peer review, post for comments, then external review by Dr. Baker All staff member will perform auditing duties. Team members will perform code walkthroughs for the uniform understanding of the project solutions during team meetings. The team uses "Majority rule" as the basis for the approval process.

7.6. Problem resolution plan

All issues will be reviewed at the project management meeting. Issues that delay development schedules will be resolved by majority.

7.7. Subcontractor management plan This project prohibits the use of a subcontractor. It is against FSU Honor code

7.8. Process improvement plan The team has a commitment to keep an open mind and be vigilant to learn of ways to improve the project in any way.

23

8. Additional plans Any additional plans will be placed here as they are needed and developed.

Annexes Pert Chart Gantt Chart

Index The Index will go here.