Title



The Electronic Stamp

Mail Server and Client

Project Plan

Part 1: Software Development Plan

by

[pic]

SDP Draft 2

September 10, 2003

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 part 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

Change History

|Revision |Date |Author |Section/Pages |Remarks |

| | | |Affected | |

|Final |September 10, 2003. |R. G. Reed |All |Revisions based on Dr. Baker’s Review.|

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, and 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.

Table of Contents

1. Overview

1. Project Summary

1. Purpose, scope and objectives

2. Assumptions and constraints

3. Project deliverables

4. Schedule and budget summary

2. Evolution of plan

2. References

3. Definitions

4. Project organization

1. External interfaces

2. Internal structure

3. Roles and responsibilities

5. Managerial process plans

1. Startup-plan

1. Estimation plan

2. Staffing plan

3. Resources acquisition plan

4. Project staff training plan

2. Work plan

1. Work Activities

2. Schedule allocation

3. Resource allocation

4. Budget allocation

3. Control plan

1. Requirements control plan

2. Schedule control plan

3. Budget control plan

4. Quality control plan

5. Reporting plan

6. Metrics collection plan

4. Risk management plan

5. Closeout plan

6. Technical process plans

1. Process Model

2. Methods, tools and techniques

3. Infrastructure plan

4. Product acceptance plan

7. Supporting process plans

1. Configuration management plan

2. Verification and validation plan

3. Documentation plan

4. Quality assurance plan

5. Reviews and audits

6. Problem resolution plan

7. Subcontractor management plan

8. Process improvement plan

8. Additional plans

Annexes

Index

List of Figures

4.2 Figure 1. Team Organizational chart

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.

Table 2. GANTT chart with major tasks from the Engineering Software Website. These reflect the tasks associated with the development model.

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

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

1. Overview

1. Project Summary

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. System Level Project Description

This project is the development of 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.

2. System Description

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

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.

2. Assumptions and constraints

1. Performance measures and values expected

Client that uses the stamps can also read previous mail format as well. This Backward compatibility is required to work with existing mail programs. It is desirable to have 100% compatibility with existing email protocol.

The system uses existing SMTP Internet protocol. The system passes when it meets the standards protocol.

The vendor and use 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 will not be hindered in message format or length. The stamp location within the email must 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 mail with stamps should not impose a significant time lag compared to than reading/sending other messages.

2. Availability

The email client will be on local machine and stamp vendor and SMP server will run 24/7 hours.

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.

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.

5. Number of transactions per sec

The system is designed so that there will not be noticeable lag after the implementation of the vendor program.

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,

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;

software development documentation and

source and source documentation;

user training plan design;

4. Schedule and budget summary

[pic]

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: )

[pic]

Table 2. GANTT chart with major tasks from the Engineering Software Website. These reflect the tasks associated with the development model.

(Source: )

2. Evolution of plan

The different versions of the plan will be maintained on our website at .

2. References

Baker, Theodore, “A Method Of Limiting Unwanted E-Mail Using A Form Of Electronic Stamp”. (Confidential)

Baker, Theodore, "Software Development Plan", Software engineering course website . (c) 2003

IEEE standards for project management 1058-1998. The entire guideline was used in this document. Available at .

Klensin, J., Editor “RFC 2821 Simple Mail Transfer Protocol (SMTP)” © The Internet Society April 2001 Available at

Myers, J. & Rose, M., RFC 1939 “Post Office Protocol - Version 3”, May 1996, © The Internet Society, Available at

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 .

3. Definitions

1. 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.

2. POP3: Post Office Protocol 3: The protocol used in communication between the e-mail client and post office server.

3. Basic Mail Message format RFC2822: IETF standard electronic mail message format with header and content descriptions.

4. 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.

5. Stamp vendor - E-commerce server that generates the Email-stamp that allows set up and use during the process of sending an email.

6. Email client - any email client that supports the SMTP mail protocol.

7. Email-Stamp-client is the email client with the additional functionality to sort incoming email by categories of stamped or not.

4. Project organization

1. External interfaces

Dr. Baker, negotiate on weekly bases, publish our deliverables every week. TelTech Alliance is our external interface. They are going to review our prototype for feasibility of use.

2. Internal structure

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

|Name |Title |Email |Home |Work |

|Gabrielle Reed |Project Manager |[pic] |562-3442 |644-0149 (M,W,F) |

| | | | |487-3711 (T,R) |

|E Shen |Repository Expert |[pic] |445-0136 |644-0149 |

|Stanislav Ustymenko |Project Leader |[pic] |575-0804 |NA |

|Yunwei Wang |Technical Leader |[pic] |576-0690 |921-2054 |

Figure 1. Team Organizational chart

[pic]

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 will be 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 will be responsible for publishing project deliverables on the web, and compiling minutes of the meeting, posting minutes to the deliverables.

5. Managerial process plans

1. Startup-plan

1. Estimation plan

1. This project will begin September 3, 2003 and end December 5, 2003.

2. Staffing plan

1. This project will use four highly qualified professionals in field of computer science.

2. Their previous and currently held positions encompass database analyst; computer analyst II; software engineer; public relation specialist.

3. The team will function until the project is done or the end of the fall Semester 2003, whichever comes first.

4. 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.

5. 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)

6. 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.

3. Resources acquisition plan

We need a group website to exchange files. Team webpage; 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.

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

2. Work plan

1. Work Activities

All team members participated 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;

2. Schedule allocation

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

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

|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 |

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.

4. Budget allocation

1. Our team members donate supplies for meetings and plan for a completion party at the end of the term.

2. Equipment is provided by the Computer Science Department at Florida State University.

3. Additional resources are available through the generous funding of NSF for the PALS Learning Systems Laboratory.

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.

• 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.

1. Requirements control plan

(to be filled out as a part of requirement analysis )

2. Schedule control plan

Check schedule weekly

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 with the remain time.

4. Quality control plan

Technical leader will assure a consistent level of quality of all the deliverables

5. Reporting plan

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

6. Change management plan

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

7. Metrics collection plan

Project leader will coordinate the final metrics and testing of the plan

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.

4. Closeout plan

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

6. Technical process plans

1. Process Model

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

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.

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.

4. Product acceptance plan

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

7. Supporting process plans

1. Configuration management plan

Design will be changed according to initial specification.

2. Verification and validation plan

1. Performance measures and values expected

1. Client that uses the stamps can also read previous mail format as well. This Backward compatibility is required to work with existing mail programs. It is desirable to have 100% compatibility with existing email protocol.

2. The system uses existing SMTP Internet protocol. The system passes when it meets the standards protocol.

3. The vendor and use 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.

4. The client using the stamps will not be hindered in message format or length. The stamp location within the email must 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

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;

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

3. Documentation plan

1. 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.

2. 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, and

• a list of outstanding issues will be updated every week.

4. Quality assurance plan

One person assigned to be quality assurance person “on time” “sufficient to do the job”

5. Reviews and audits

1. All deliverables will be reviewed by Internal peer review, post for comments, then external review by Dr. Baker

2. All staff member will perform auditing duties .

3. Team members will perform code walkthroughs for the uniform understanding of the project solutions during team meetings.

4. The team uses "Majority rule" as the basis for the approval process.

6. Problem resolution plan

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

7. Subcontractor management plan

This project prohibits the use of a subcontractor. It is against FSU Honor code

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.

8. Additional plans

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

Annexes

Any Annexes will go here.

Index

The Index will go here.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download