CS4500 Project Plan
January 29, 2009
Team Groundhog
1.0 Introduction
1.1 Project Overview
We will be creating an application that will allow for viewing of
GDS II files and printing to an Epson 9800 printer(1440
dpi, 44” wide). The language used will be C# in the .Net framework, with a
target deployment on Windows.
1.2 Definitions, Acronyms,
and Abbreviations
GDS II: database file format which is the de facto industry
standard for data exchange of integrated circuit or IC layout artwork
VLSI: Very Large Scale Integration
Plotter: large format printer
Alpha Blending: convex combination of two colors allowing for transparency
effects in computer graphics. The value of alpha in the color code ranges from 0.0
to 1.0, where 0.0 represents a fully transparent color, and 1.0 represents a
fully opaque color.
1.3 References
http://en.wikipedia.org/wiki/VLSI
http://en.wikipedia.org/wiki/GDSII
1.4 Overview of Document
The following discusses how we intend to complete our project
efficiently. We will explain our development model, assign roles and plan how
we intend to review and audit our source code. We'll also discuss logistics,
such as meeting times. We'll then discuss our product in more detail and talk
about any restrictions or guidelines.
2.0 Project Organization
2.1 Process Model
We will use the Agile Process model: http://en.wikipedia.org/wiki/Agile_software_development.
2.2 Organizational
Structure and Responsibilities
We will have a permanent team leader. This person will be
responsible for communicating with Prof. Henderson. We will try to preserve positions without
rotating around to allow people to become experts in their designated areas of
work.
2.3 Organizational
Boundaries and Interfaces
Prof. Brunvand will act as our Customer.
We will provide the most recent releases to him as they are available. The
Customer or the development team may post alterations to this project plan in
the indicated area on the Team Webpage. Any changes will be discussed by the
Team and a decision will be made as a group prior to implementation.
2.4 Reviews, Walkthroughs,
Inspections, and Audits
2.4.1 Procedures for
Reviews, Walkthroughs, Inspections, and Audits
We are working with the Agile Development process, and as such we
will have many iterations of the software in which we can review and
walkthrough with each other what we have completed. We will implement Peer Code
reviews to inspect and audit each other's code. Each meeting we will discuss
what we have completed the past week.
2.4.2 Peer Review and Audit
schedule
|
Date |
Activity |
|
February 27 |
Peer Code Review pre-Stage1 release |
|
March 19 |
Peer Code Review pre-Stage2 release |
|
April 2 |
Peer Code Review pre-Stage3 release |
|
April 12 |
Peer Code Review pre-Final release |
3.0 Team-Specific Aspects
3.1 Management Objectives
and Priorities
Our priority will be to produce a fully functioning viewer and
printing utility. We will be focusing on the challenges surrounding the GDS II
format in order to take full advantage of our limited time. We will break each
functional module into sections and assign these to individual team members.
3.2 Team Name
Groundhog. We will be taking Feb 2nd off to observe our holiday, and watch out for our shadows.
3.3 Meeting Times
We have decided to meet during class time. Additional meetings
outside of this time will occur as determined during normal meeting times. Sundays are currently the best extra day for
all team members. We have a recurring
meeting every two weeks with Prof. Brunvand on
Tuesdays at 2 PM.
3.4 Team's Range of Skills
and Experience (1=no experience - 5=very experienced)
|
Category |
Tim |
Josh |
Scott |
Adam |
Curtis |
|
OpenGL |
5 |
1 |
4 |
2 |
2 |
|
Team Based Programming |
5 |
5 |
5 |
5 |
5 |
|
Version Control |
5 |
5 |
5 |
5 |
5 |
|
Management Skills |
2 |
5 |
5 |
3 |
3 |
|
Web Development |
5 |
3 |
5 |
5 |
3 |
|
UI Design |
4 |
4 |
4 |
4 |
4 |
|
Writing Skills |
3 |
5 |
5 |
3 |
3 |
|
QA |
3 |
3 |
3 |
5 |
5 |
4.0 Preliminary Sketch of Project Requirements
4.1 Overview of Functional
Requirements
Our product will be a Windows based utility for viewing and printing GDS II files. We will use an alpha blending strategy to allow various layers within the object to be displayed “correctly”. Current implementations of this type of tool use a screen door approach to account for overlaps. Allowing for transparency at each layer is also required. This will enhance the current implementations by allowing a much larger range of colors to be used.
4.2 Overview of Data
Requirements
The data will be based on GDS II files provided by Prof. Brunvand. GDS II
files are binary formatted files that contain a large amount of information
about the graphic. There will be
considerations for the amount of data that we can store in memory versus
needing to stream from disk. The printer
service will also have data requirements that should follow standard windows
print driver specifications.
4.3 General Constraints,
Assumptions, Dependencies, and Guidelines
Due to the nature of GDS II files, the minimum computer
specification will need to be more inline with a high
end desktop. Memory speed and size
should be optimized. It should run on any Windows operating system. We are dependent on using the Epson printer
provided by Prof. Brunvand. It would be nice if the application can print
on any printer, not just the Epson.
Must Have features:
·
Load GDS II file
·
View Object as specified in the GDS II file
·
Modify colors, transparency, and alpha by layer
·
Print Object on Epson plotter
Nice to Have
·
Edit shapes and sections of the Object
·
Save updated GDS II file to disk
·
Print on additional printers
·
3D rendering of Object
4.4 User View of Product
Use
The end user will be able to load up a previously generated GDS II file, and view it in the application. They will be able to set transparencies and alpha blending values for the various layers. They can then send the job for printing. Nice to have features will be allowing the user to modify the shapes and forms in the object. Additionally, selecting alternative printers will be a Nice to have.