Post on 12-Sep-2014
description
Macintosh Print Controller
Final Report
Team May03-08
MetalCraft, Inc.Mason City, IA
Dr. James Davis
Luke BodeenDavid LeggeCurt MelchertRyan Sinnwell
April 8, 2003
i
Table of ContentsList of Figures....................................................................................................................iiiList of Tables......................................................................................................................ivList of Definitions................................................................................................................v1 Introductory Materials.................................................................................................1
1.1 Executive Summary.............................................................................................11.1.1 Necessity for Project....................................................................................11.1.2 Project Activities.........................................................................................11.1.3 Project Results.............................................................................................11.1.4 Recommendations for Future Work............................................................2
1.2 Acknowledgement...............................................................................................21.3 General Problem and Solution Approach Statement...........................................2
1.3.1 Problem Statement.......................................................................................21.3.2 Solution Approach Statement......................................................................3
1.4 Operating Environment.......................................................................................31.5 Intended Users and Uses......................................................................................41.6 Assumptions and Limitations..............................................................................41.7 End Product and Other Deliverables...................................................................4
2 Project Approach and Results......................................................................................52.1 End-Product Functional Requirements................................................................52.2 Resultant Design Constraints...............................................................................52.3 Approaches Considered and Approach Used......................................................62.4 Detailed Design...................................................................................................82.5 Implementation Process Description.................................................................102.6 End-Product Testing Description......................................................................112.7 Project End Results............................................................................................12
3 Resources and Schedules...........................................................................................123.1 Resource Requirements.....................................................................................12
3.1.1 Personnel Effort Requirements..................................................................123.1.2 Financial Requirements.............................................................................13
3.2 Schedules...........................................................................................................144 Closure Materials.......................................................................................................17
4.1 Project Evaluation..............................................................................................174.2 Commercialization.............................................................................................184.3 Recommendations for Additional Work............................................................184.4 Lessons Learned................................................................................................194.5 Risk and Risk Management...............................................................................19
i
4.6 Project Team Information..................................................................................214.7 Closing Summary..............................................................................................214.8 References..........................................................................................................214.9 Appendices........................................................................................................22
4.9.1 Appendix 1 – Process flow diagram page 1..............................................224.9.2 Appendix 2 – Process flow diagram page 2..............................................234.9.3 Appendix 3.................................................................................................24
ii
List of FiguresFigure 1 – Current data flow for MetalCraft printing process…………………………...3Figure 2 – Proposed data flow for MetalCraft printing process…………………………7Figure 3 – Gantt chart of project schedule page 1……………………………………… 15Figure 4 – Gantt chart of project schedule page 2 ………………………………………16
iii
List of TablesTable 1 – Personnel effort budget (original) …..………….……………………………..13Table 2 – Personnel effort budget (revised) ....…………….…………………………….13Table 3 – Personnel effort budget (actual) ….…………….………………..……………13Table 4 – Financial budget ………………………………………………………………14
iv
List of DefinitionsCheckMate – custom software used by MetalCraft to make a file with the serial numbers
required for each job
cron – Unix application to schedule system and application events
Indigo Omnius– printing press used to print labels on clear plastic material
Mac OS X – the latest version of the Macintosh operating system
Postscript – standard file format for sending pages to a printer or RIP
QuarkXPress – publishing program for the Macintosh platform
RIP – this stands for raster image processor, it is software that tells the printer how to
place each pixel on the paper
Xdata – an extension of QuarkXPress that facilitates incorporation of data into a Quark
page from a file
v
1 Introductory MaterialsThe following sections give a short introduction and background information about the
project. It also provides information about the operating environment, users and uses,
assumptions and limitations, and the end product.
1.1 Executive Summary
The executive summary discusses the necessity for the project, the project activities and
results, and the recommended future work.
1.1.1 Necessity for ProjectThe Macintosh Print Controller project solves a process productivity issue for MetalCraft,
Inc. of Mason City, IA. MetalCraft, Inc. makes industrial labels for identification and
inventory purposes. An onsite visit was conducted to learn more about the process flow
and tools currently used. The process flow for printing pages of labels on a digital
printing press is currently slowed by a manual linking operation and file export problem.
The design person has to manually link the rows and columns of labels in the design file
so that the serial numbers are inserted in the correct order. When there are ten or even
hundreds of pages, this task can be time consuming and error prone. It can also take a
long time when the design file is exported to a Postscript format because each page has to
be converted even though they are essentially identical except for the serial numbers and
barcodes. Both of these issues reduce the productivity of the design group by tying up
their resources.
1.1.2 Project ActivitiesAfter examining a number of solution approaches, it was decided that the best approach
would be to write a Java software application to create a Postscript file that is populated
with serial numbers and barcodes. The application accepts a single page Postscript
template file, a serial number text file, and information regarding the orientation of the
serial numbers. Next the application creates the needed number of pages and inserts the
serial numbers and barcodes in the order chosen by the user. The output is a Postscript
file that can then be sent to the digital printing press for printing. Testing of the
application was done throughout the implementation and further onsite testing is planned.
1
1.1.3 Project ResultsThe project was successfully completed and a working product will be delivered to the client. The main result of the project will be an increase in productivity for MetalCraft, Inc. by reducing the manual work and redundant processing inherent in their current process.
1.1.4 Recommendations for Future WorkThe application could be changed so that less information from the user is required. This
would require the application to examine more properties of the template file. The
application could also be modified to automatically send the completed file to the printer.
The functionality provided by Checkmate could be incorporated into the application.
1.2 Acknowledgement
We would like to thank John Henry of MetalCraft, Inc., Mason City, IA for his assistance
in gathering information and providing development equipment. Thank you to Becky
Johnson of MetalCraft, Inc. for providing us with example files and clarifications
regarding the current process. We would also like to thank Dr. James Davis for his help
and encouragement.
1.3 General Problem and Solution Approach Statement
This section gives a brief explanation of the problem and the solution approach.
1.3.1 Problem StatementMetalCraft, Inc. manufactures a large variety of labels and nameplates used for product
identification and inventory purposes. Their current system requires the label layout
designer to manually link rows, columns, and pages so that the labels are numbered in the
correct order. When there are hundreds of pages, this task can take a long time. The file
of labels must then be exported to a specific format for printing. This operation also
takes a long time because the design software does not recognize that each page is the
same except for the serial numbers and barcodes and therefore does a lot of redundant
processing. Both of these issues increase the time spent on a specific job and therefore
reduce the productivity of the design group. A process flow diagram is provided in
Figure 1.
2
Figure 1 – Current data flow for MetalCraft printing process
1.3.2 Solution Approach StatementThe solution used will be a software application. Because of its placement in the process
and its functional requirements, it is able to solve both of the issues presented in the
problem statement. The design group only has to make a single page of labels and
provide it in the final printing format to the software. They will not need to do any
manual linking because the software ensures that the labels are numbered in the proper
order. Additionally, the software eliminates the need for the redundant processing of
each page because it is able to copy and use the necessary data from the single page
provided. The software solution will require that the design group start it and provide the
locations of input files, information about the file itself, and where the final product will
be placed.
1.4 Operating EnvironmentThe end product will be utilized in an office setting on a computer running Macintosh OS
9 or OS X. The conditions of the environment are controlled and neither temperature nor
3
cleanliness will affect the end product.
1.5 Intended Users and UsesUsers: The intended user for this project is the design group at MetalCraft, Inc. They
are familiar with the tasks need to complete the design and prepare it for printing.
Uses: The intended use of the project is to minimize the manual work involved in
creating the label design file. The project will be used to augment a design template with
serial numbers and eliminate redundant processing by QuarkXPress. This will reduce the
amount of time spent by the design station computer processing the file for output to the
printing press. Both of these uses will increase the productivity of the design group.
1.6 Assumptions and LimitationsThe following section lists the assumptions and limitations that are relevant to the final
version of the project.
Assumptions:
1. Input to the end product will be in Postscript format.
2. Users of the end product are already familiar with the current system and tasks to
be completed.
3. Upgrades in system software will be backwards compatible.
4. Each page of labels has the same design except for the serial number and barcode.
Limitations:
1. The design will be limited by the lack of automated execution of the software; i.e.
the operator must manually run the software and provide input.
2. Members of the project group must be familiar with or learn Java programming.
3. The design process took place outside the final operating environment; hence the
testing of the design will be limited.
4. Group has limited knowledge of Postscript fomat.
1.7 End Product and Other DeliverablesThe Macintosh Print Controller end-product will be Java desktop application that will run
on a Macintosh G4 desktop system. Input to this software will be a generic label layout
in Postscript format and a text file with a list of serial numbers generated by CheckMate.
The Java application will take the postscript file, add the desired number of pages,
4
properly insert serial numbers and barcodes, and send the completed job to the press for
printing. It will reduce layout system downtime and increase overall productivity. A
process flow and help guide will be provided to describe the sequence of tasks to be
completed.
2 Project Approach and ResultsThis section describes the requirements of the end-product, design constraints, and
approaches explored. It also provides the actual design of the end-product, a description
of the implementation and testing, and the results of the project.
2.1 End-Product Functional Requirements
The following is a list of functions that the end-product completes.
1. Accept input files from design station - The application needs to accept the
postscript template page and the list of serial numbers from the design station.
2. Lengthen layout file to proper length - The application should determine the
number of labels needed and lengthen the Postscript file as needed by repeating
the code that represents the existing labels.
3. Populate serial numbers - The Postscript file will be edited and the proper serial
numbers will be populated in the correct position on the labels. The user will
determine the numbering scheme.
4. Output final Postscript file – After all serial numbers are inserted, the file should
be output to the location determined by the user.
2.2 Resultant Design Constraints
The following list describes inherent constraints placed on the end-product.1. Postscript file format – The complexity of the file only allows the end-product to
edit the serial numbers and barcodes. It cannot change the position or properties of other items.
2. System hardware – The processing speed of the computers running the software limits the time efficiency of the end-product.
3. Network – The network equipment and cabling will limit the ability to transfer large files quickly between machines. This will slow the time that it takes to make the design station available for the next project.
4. Sustainability of current software – The current software being used may
5
change when new versions are released. This might introduce issues with the solution approach; therefore the solution should not depend heavily on the current software.
2.3 Approaches Considered and Approach Used
Numerous technical approaches were considered because of the complexity and modular
nature of the current process. The current process employs two separate computing
platforms and multiple software programs, therefore allowing a solution to be inserted in
many locations in the process flow. Each allowed solution location has its own
constraints on the form and functions of the solution.
The first approach considered was to write a Quark Xtension that would be able to
automatically do all of the linking of rows, columns, and pages. This would run on the
design station and would be used before serial numbers were inserted by XData. It would
not however be able to reduce the time that it takes to export the file to Postscript format.
It was not chosen because it only was able to solve one of the issues described in the
problem statement. Additionally, this approach did very little to free up the design
station to begin other jobs because the exporting of the design file to Postscript format
still takes a long time.
Another approach was to use a piece of software on the printing press that would take a
Postscript file that had all of the pages created but no serial numbers or barcodes inserted.
It would insert the serial numbers and barcodes into the file and then send it to the RIP.
An advantage of this approach would be that it would be able to use the printing press for
doing the insertion of the serial numbers and therefore free the design station more
quickly to begin other jobs. This option also eliminates the need to manually link the
labels in the proper order but does not help with the redundant processing and therefore
was also rejected.
6
Figure 2 – Proposed data flow for MetalCraft printing process
The approach that was chosen was one that addresses both of the time consuming tasks of
manual linking and redundant processing while exporting the design file. The proposed
data flow is shown above. It requires the design group to provide a single page of
Postscript, a file containing serial numbers, and information about the orientation. It will
be able to use this one page to create as many pages as needed and then populate them
with serial numbers and barcodes in the proper order. The only discernable
disadvantages of this approach are that it requires the user to open another program and is
susceptible to user error. However, the benefits of this approach are numerous and
greatly outweigh the disadvantages. The major benefit over other approaches is that it
cuts out all of the redundant processing because only one page is exported to Postscript
format. This eliminates the bulk of the wasted time on the design station and is therefore
the most useful option. The major reason for choosing this approach is that it provides
for the largest increase in productivity to the process.
7
2.4 Detailed Design
The design that was pursued was a custom software application to perform all of the
manual tasks that used to slow the printing process down. It was desired by the group
that this software be able to stand alone and not be reliant on the printing press or design
program. It was also important that this software be able to run anywhere. The best
choice for this was Java.
The software is to provide fast, easy execution of two tasks that used to take an extensive
amount of time. Those are numbering of the labels in the file and exporting to the
Postscript format from Quark. The numbering of the labels was mostly manual before
and now will be completely automated. The export of the Postscript file from used to
take a long time because every page was exported separately and sometimes hundreds of
pages are exported at a time. With our design, this problem is eliminated because only
one page has to be exported from Quark.
Appendix 1 and 2 can be referred to while reading the detailed design. Those appendices
show the process flow of the software. The order of operation of this software is
important because the Postscript must be written out in a sequential order. Appendix 3
can also be referred to by the reader to get a grasp on what the actual Postscript file looks
like. Appendix 3 shows the major changes that this software makes in the actual
Postscript code.
The first thing the software does is read the one page label layout file. This file is an input
from the GUI. This file will be generated by the designer and exported to Postscript
format from Quark. There are several conditions this file has to meet in order to be
processed correctly by the software. The first condition is that file is one page of
Postscript. The software will generate as many pages as needed based on the one page of
Postscript. If there is more than one page in the design file, it will not work correctly in
our software. The next condition is that the labels not be internally linked together in
Quark. If the labels are internally linked, Quark will export the file differently, affecting
the label order that our algorithms are based on. As long as the file is unlinked, it will
work correctly. The third condition is that in the place of where the serial numbers
should be, there needs to be the same number of # signs as the number of digits in the
8
serial numbers provided. The serial number will have the same number of digits
throughout. The reason for the # signs in the layout file is twofold. First, the centering of
the barcode and serial numbers is calculated in Quark and exported that way. If the
number of # signs in the exported file is different than the number of digits in the serial
number, the centering will be wrong when the serial number is put in the layout file. The
second reason for # signs is for a unique delimiter in the Postscript. The Postscript that is
read is complicated and some of it is binary. The # signs provide a unique sequence that
the software can look for and insert the serial number at that point. The final condition is
that the Postscript remains the same as all of the test and sample files that have been
encountered so far. If the Postscript standard changes, Quark’s export of the Postscript
changes, or Metalcraft’s layout process changes the software will not work. These
conditions seem extensive, but they are not hard to meet. To meet all of these conditions,
the layout designer will actually have less work to do than before. For the number of
hours that this software will save, these conditions are miniscule in comparison.
The next thing the software does is read the serial number file. The serial number file is
generated by a program called CheckMate. This file is read in and all of the serial
numbers are put into an array. This array will be used later for insertion of the serial
numbers. The conditions on the serial number file are simple, use the serial number file
that is exported from CheckMate. CheckMate is involved the current design process so
no training will be needed.
After both files are read, the program then generates the first page of the output file.
While it is generating the first page, it keeps track of the Postscript that must be copied
for additional pages.
When the first page is generated, it moves on to the rest of the pages. The number of
pages to be generated is determined based on the number of labels per page and the
number of serial numbers. The math calculation for that goes as follows:
int numLabelsPerPage = rows * columns;if(maxSerials % numLabelsPerPage > 0)//if there is more than 0 remaining labels
{lastPage = (maxSerials / numLabelsPerPage) + 1;
9
//add one extra page to the division}else//remainder is 0, so division is whole number
{lastPage = maxSerials / numLabelsPerPage;}
The number of rows and columns are passed into the software by the user. The code for
determining these numbers based on the Postscript would be extensive because of the
obscurity of the Postscript. It was determined that because these numbers can easily be
determined by the user by just looking at the layout file, that it would be useful to have
these as inputs to the software.
While generating additional pages, the software actually inserts the serial numbers as it
goes. There are three layouts that determine the order of the serial numbers in the file.
The first layout is sequentially down the column, through the entire file, then onto the
next column. The second layout is sequentially down each column per page. The final
layout is across each row. For each layout, there is a calculation to determine which index
of the serial number array to insert. These calculations are shown below.
if(layout == 1){index = ((currentPage-1) * rows) + (lastPage * rows * (currentColumn-1)) + (currentRow-1);//algorithm to go down the columns all the way through the file}
if(layout == 2){index = ((currentPage-1) * (rows * columns)) + ((currentRow-1) * columns) + (currentColumn-1);//algorithm to go across the row}
if(layout == 3){index = ((currentPage-1) * (rows * columns)) + ((currentColumn-1) * rows) + (currentRow-1);//algorithm to go down the columns on each page}
return index;
Once all of the pages are generated, some final file information is inserted and the
software is finished. The file is then ready to be inspected and dropped to the digital
printing press.
2.5 Implementation Process DescriptionThe Java development tool used to create the end-product was Borland JBuilder 7. The
coding for the graphical user interface and the main processing were split up. Basic
functions of the code were proven able to be done early on such as opening a Postscript
10
file and writing to it. After this, code for copying and inserting new pages was done.
Algorithms were developed to figure out which serial number should be placed on a label
as the code stepped through each page. Finally the code from the graphical user interface
and the main processing section were coupled. The only problem encountered was an
issue with the spatial placement of serial numbers. If only a single character was put in
the template file in place of the serial number, then when the multi-digit serial number
was inserted the spatial relations were distorted. For instance, if the serial number was
supposed to be centered, it would no longer be centered when the longer serial number
was inserted. This was solved by requiring the template file to include the same number
of place holding characters as the final serial number would have.
2.6 End-Product Testing DescriptionTesting is important in evaluating project development and final adherence to design
requirements. With these ideas in mind, the following testing activities were and will be
used.
1. Component testing – Each function was developed and tested independent of the
rest of the application. Each function was tested using the specific inputs that it
requires to complete the tasks it is designed to do. Component testing was done to
find and reduce problems that may have otherwise appeared in system integration
testing and hence be more difficult to locate and fix. The following component
tests were completed by the project group:
a. Postscript editing – A Postscript file was opened and written to, the file
was then viewed to see if the changes showed up with a Postscript viewer
such as Ghostview. This verified that serial numbers and barcodes could
be edited.
b. Page replication – A single page Postscript file was opened and used to
create a specified number of pages. The pages were viewed to ensure that
they were identical to the template page. This verified that data in the
template page could be used to create more pages.
2. System-integration testing – Once all components are tested, the final system
was tested in one piece. This tested all functional requirements and was done by
both the project group and MetalCraft, Inc. in unison. A single page template file
and serial numbers were provided by MetalCraft, Inc and then input to the
11
project’s software. The resultant Postscript file was sent to MetalCraft, Inc. and
successfully printed. This verified that the file created by the project will would
be understood by the printing press and print correctly.
3. User acceptance testing – Regular users will be trained in how to use the system
with the modifications made by our project. Both design users and production
users will then operate the system for a period of time to be determined. After
this they will provide any information regarding problems encountered or
suggestions for improvements. This testing will be completed during the onsite
delivery visit.
4. Performance testing – Testing will be done to compare the performance of the
system after modifications of the new process to the original system. This testing
will be completed during the onsite delivery visit. It is believed that the
performance difference will be great. It currently can take more than an hour to
create the large file that can be a hundred pages. The end-product software can
create a hundred pages in approximately 12 seconds.
2.7 Project End ResultsThe project was successful and the end-product will be delivered to the client in working order. The end-product meets all of the functional requirements and will greatly improve the process flow for MetalCraft, Inc.
3 Resources and SchedulesThis section provides an accounting of the estimated resources for the project and actual resources used. These resources include personnel effort and the cost of completing the project. A section is also provided that shows the schedules used.
3.1 Resource Requirements
3.1.1 Personnel Effort RequirementsThe personnel budget lays out how many hours each team member spent on each
milestone, and then the total hours for the project. The effort has also been revised to
account for changes in the project.
12
Table 1 – Personnel Effort Budget (Original)
Doc
umen
tatio
n
Res
earc
h
End
of fi
rst
sem
este
r
Impl
emen
tatio
n
Test
ing
End
of se
cond
sem
este
r
Del
iver
y
Tota
l
Luke Bodeen 12 5 4 124 10 5 5 165
David Legge 13 4 4 104 5 5 5 140
Curt Melchert 15 3 4 114 5 5 5 151
Ryan Sinnwell 14 3 4 103 10 5 5 144
Total 54 15 16 445 30 20 20 600
Table 2 – Personnel Effort Budget (Revised)
Doc
umen
tatio
n
Res
earc
h
End
of fi
rst
sem
este
r
Impl
emen
tatio
n
Test
ing
End
of se
cond
sem
este
r
Del
iver
y
Tota
l
Luke Bodeen 12 3 4 94 9 5 5 132
David Legge 13 3 4 85 7 5 5 122
Curt Melchert 15 3 4 89 5 5 5 126
Ryan Sinnwell 14 3 4 86 10 5 5 127
Total 54 12 16 354 31 20 20 507
Table 3 – Personnel budget in hours (Actual)
Doc
umen
tatio
n
Res
earc
h
End
of fi
rst
sem
este
r
Impl
emen
tatio
n
Test
ing
End
of se
cond
sem
este
r
Del
iver
y
Tota
l
Luke Bodeen 14 8 8.5 45 10 4 0 89.5
David Legge 12.5 5.5 4 20 3.5 3 0 48.5
Curt Melchert 15.5 12 4 12 0 9.5 0 53.0
Ryan Sinnwell 18 10 6 12.5 1.5 2.5 0 50.5
Total 60 35.5 22.5 89.5 15 19 0 241.5
3.1.2 Financial RequirementsWith a solution that includes a customized software application, there are not many
13
incurred costs. Those that have been encountered are listed below in Table 4 and a short
description of some of the funds follow.
Table 4 – Financial BudgetBudget Item Original Estimated
CostRevised Estimated Cost
Actual Cost to Date
Software $100 $100 $0Poster/Printing $40 $90 $87Phone Calls $25 $0 $0Equipment & Parts $0 $1700 $1700Total $165 $1890 $1787Poster/Printing – This money is out of the pockets of the team. The printing costs
include the final, bound versions of the project plan, the design document, and the final
report.
Equipment & Parts – This budget item covers the purchase of a computer for
development and testing purposes. The computer was donated by MetalCraft, Inc. and
will remain their property at the end of the project.
Phone Calls – The team has found that phone calls are not going to be needed as
frequently as anticipated. There are very open lines of communication via e-mail
between the client and the team, and each party is very prompt in responding to e-mail.
3.2 SchedulesThe project schedule is shown in the next two pages in the form of a Gantt chart. The
lightest gray bars are the original schedule. The medium gray bars are the revised
schedule for the design document. The darkest gray bars are the current schedule. The
project schedule as a whole has been followed very well. There have been some changes
in the schedule as the project has progressed. Research took a little longer than expected
because of problems contacting Quark, Indigo, and Hewlett Packard. The presentation
was developed more after Christmas break than anticipated. Development started a little
late and went a week later than expected. This was because of a label centering issue that
was unexpected. Testing also took place more in correlation with development. This was
not anticipated when developing the original schedule. This was possible because
development progressed quickly. The final report was moved up because the second
semester schedule was unknown when the schedule was made. The user manual was
added as a task because that was not in the original schedule as a task. Delivery has also
14
been moved up so the software can be used before school is over. There is only one Gantt
chart provided because there is only one deliverable for this project.
Figure 3 – Gantt chart of project schedule, page 1
15
Figure 4 – Gantt chart of project schedule, page 216
4 Closure MaterialsThis section discusses the project evaluation, commercialization prospects, recommendation for additional work, lessons learned, and risk and risk management. It also provides information about the team, a final summary, references, and appendices.
4.1 Project EvaluationThe following is an evaluation of the degree of success of the project. It is broken down into the main milestones as defined in the Gantt chart on the previous page. Each milestone is given a degree of success rating based on the following scale:
0 = not attempted1 = not met2 = partially met3 = fully met4 = exceeded5 = greatly exceeded
Then the rating of each of the milestones are averaged together to obtain an overall rating for the project as a whole. The delivery rating is not included because it will be completed by the end of the semester and is not expected to cause any problems.
Documentation (3 = fully met) – All required documentation was completed and submitted on time.
Research for Design Approach (3 = fully met) – Several approaches were considered. The necessary research was done to make an informed decision about which approach would satisfy all design requirements while still being feasible.
End of Semester (3 = fully met) – Group oral presentation was successfully prepared and delivered at the time assigned to the group.
Implement Design (4 = exceeded) – Design and coding of the solution went faster than anticipated and got the project done ahead of schedule.
Testing (2 = partially met) – The fact that the design was done remotely from the operating environment limited the testing that could be done. An onsite delivery visit is planned during with testing will be completed.
End of Project (3 = fully met) – Final project report and industrial review panel presentation were completed successfully and on time.
Delivery (0 = not attempted) – The end product has yet to be delivered to the client. An onsite delivery visit is planned.
Total Project - 3.0 = fully met
17
4.2 CommercializationThe commercial value of the end product is limited due to the specific design
requirements of the project. The end product is specifically tailored to the needs of
Metalcraft, Inc. If other companies with similar printing operations had similar needs,
then there may be a market for this product. However, these companies are likely to be
limited in number, therefore reducing the need for this product. The cost of manufacture
of the end product would include the cost of labor and the cost of the storage media (i.e.
disk or CD-ROM). Since there have been about 242 hours of labor on the project to date,
the current cost of labor is approximately 242*$20 = $4840. The retail cost of the end
product would be somewhat arbitrary and dependent on the current market value of
similar software products. A reasonable value for a product could be between $100 and
$200.
4.3 Recommendations for Additional WorkThe current final product will require the user to start the processing of the files. In the
future, it would be beneficial if the processing station could periodically monitor a drop-
box for new files to be processed. Whenever a new file arrives in the folder to be
processed, the application will process and forward it to the RIP upon completion. Once
all of the systems have been updated to Mac OS X and the RIP has drivers available for
Mac OS X, this process should not be hard. Being based on Unix, Mac OS X has the
core operating system functions such as cron with which many Unix users are familiar.
Using cron to schedule the execution of the application, the system would periodically
launch the application to look for new files to process.
Another area that can be improved is the sending of files to the RIP when the Postscript
modifications are complete. This could also be done via cron with the use of a small
AppleScript or other scripting language. Since the RIP shows up as a mapped drive on
the desktop of the processing computer, when the files are marked as done, they could be
copied to this drive where they would automatically show up as ready for printing.
The functionality of Checkmate could also be incorporated into the end-product. This
would help to reduce the number of file inputs to the end-product. It could also speed up
end-product and reduce the memory resources used by the software.
18
4.4 Lessons LearnedThe project went fairly smoothly once a technical approach was chosen. The
development and implementation of the Java coding was fairly straightforward once the
algorithms were developed. Using Java as the programming language for the project was
a good choice. Java lends itself well to string manipulation and therefore worked well for
this project.
The only problem worth noting with the development of the code was due to some lack
of clarity of the sample files sent by the client. There was some ambiguity as to how the
sample files were created (e.g. if they were already linked) and if that was an assumption
made by the client as to the type of input the final product required. It is very important
to for both the client and the group to clearly state what they want the project to do and
how it is to work.
A problem discovered in the research stage of the project was that many of the potential
technical approaches resulted in dead ends due to a lack of product support for the
software products that would form the cornerstones of those approaches. Also there was
an apparent unwillingness of some companies to give the requested technical support.
We also had difficulty in contacting some companies in the first place.
As a result of the project, the team members have gained a deeper understanding of Java
and how it can be applied in a real-world application. They have also learned enough
about the Postscript file format to be able to complete the project.
The main thing that would have been done differently if the project was to be done again
would be to more clearly define the interfaces between different parts of the process
before implementation was to be done. This would have allowed more of the software
application to be developed in parallel.
4.5 Risk and Risk ManagementPossible risks are listed with the activities designed to minimize their impact on the
project timeline and quality.
1. Loss of team member: All documents will be kept in a centralized location so
19
that any team member may view them. Communications will be made to the
entire group so that there are multiple copies of correspondence and decisions
made. Two or more members will have a part in every task.
2. Availability of client/system resources: It is possible that some of the resources
of the client or the system may be unavailable to use due to the location of the
client or their production schedule. To alleviate these issues, interfaces and
requirements must be clearly described for each component. Development and
testing may need to be done in a modeled environment locally.
3. Ineffectiveness of technical approaches: All documentation will be turned over
to the client for evaluation of project status and future work. Other suggestions of
approaches will be made to the client, so if the solution does not quite fit their
needs, they are able to make changes.
4. Loss of functioning code revisions: A system will be devised to backup
revisions of code so that they can be retrieved if they prove to be better solutions.
Also, this will provide a safe way to store the various electronic portions of the
project. Any portion of code that is known to be in working order will be backed
up before any changes are made. If a piece of functioning code is modified, it
could render it useless. This would cause a major setback in the development
process.
5. Availability of information on current system: The approach chosen may need
more information about the interaction between the RIP and Mac OS X. Care
will be taken to ensure that the technical approach taken will have sufficient
knowledge of the current system to allow a functioning product to be designed
and produced.
None of the anticipated risks were encountered. There were also no unanticipated risks
encountered and therefore the risk management strategies were not changed. Even
though no risks were encountered, the strategies should be reviewed and extended if the
group is to complete another project.
20
4.6 Project Team InformationClient: MetalCraft, Inc. Faculty Advisor: James Davis
Mason City, IA 50401 2413 Coover
John G. Henry Ames, IA 50011-3060
641-423-9460 (phone) 515-294-0659 (phone)
641-423-8898 (fax) 515-294-8432 (fax)
johnh@idplate.com davis@iastate.edu
Team: Luke Bodeen David Legge
2823 Ontario St 428 Stonehaven #6
Ames, IA 50014 Ames, IA 50010
515-292-1049 515-451-5732
lbodeen@iastate.edu dlegge@iastate.edu
Curt Melchert Ryan Sinnwell
300 Stanton Ave Apt 308 3236 Frederiksen Ct
Ames, IA 50014 Ames, IA 50010
515-598-9110 515-572-7899
melchert@iastate.edu sinnwell@iastate.edu
4.7 Closing SummaryProductivity is important to companies because of the need to get the most out of the people and resources currently available. This project was needed to help MetalCraft, Inc. increase their productivity by improving the process that they use to design and print labels. By using the proposed design, process time and flow will be significantly improved and streamlined. The solution will be independent of current software, thus allowing it to adapt to updates in the system. MetalCraft, Inc. will be able to increase their productivity for each job and in turn be able to accept more business.
4.8 ReferencesThere were no references necessary.
21
4.9 Appendices
4.9.1 Appendix 1 – Process flow diagram page 1
Appendix 1: Process flow diagram page 1.
22
4.9.2 Appendix 2 – Process flow diagram page 2
Appendix 2: Process flow diagram page 2.
23
4.9.3 Appendix 3 – Postscript code example and description
Notes are provided to describe with Postscript commands should be modified and where they should appear in the file. All other commands are from a sample page and should not be altered.
%%Page: 1 1 Identifies the beginning of each page (%% Page: 2 2, etc)
%%BeginPageSetup%RBIIncludePageSlotInvocationmTSsetuppmSVsetupinitializepage(Becky; page: 1 of 1)setjob Should change for each page, may not be
necessary though%%EndPageSetupgS 0 0 878 1238 rC1 G0 0 0 0 rF0 0 :M%%QRKSequentialPageRange: 1 1 Only on first page, if 4 pages then :1 4%%QRKPageBegin: 1 Change for each page (1, 2, 3, etc)%%QRKSequentialPage: 1 Change for each page (1, 2, 3, etc)%%PlateColor: BlackQuarkXPress_4.04 beginF/ss X 1 1 pen 0 H 0 a 0 b[] 0 p0 H(-1 -1 793 613 initclip F rc u)kpxpbu 1 F 150 45 sp0 T xpscrncalcbndxpbns2qd-1000 -1000 :Mf53 sf( )S-1000 -1000 :Mxps2ps
24
xpbu0 1 F 0 F /|______Helvetica T /|______Helvetica-Bold 0 T dfntxpbn0 1 1 fs2qd-1000 -1000 :Mf90 sf( )Sxps2psxpbu1 0 [T 6 F F /|______IndigoOne 0 T dfntxpbn1 1 1 fs2qd-1000 -1000 :Mf129 sf( )Sxps2psxpbu2 0 [T 6 F F /|______IndigoEight 0 T dfntxpbn2 1 1 fg .2 o72.1 72.1 125.9 215.9 8.1 rr1 n G1 setchc bkc 0 1 put1 Hptc0 H1 17 25 f90.8843 105.4378 m 1.3311 0 7 106.4813 (*138000*)d (* is for barcode0 15.62 12.5 f115.8955 121.5608 m .4341 .8685 5 52.1164 (138000)d ( is for text, need to search
for ( and then a number, may need to use a special
characterbkc 0 0 put1 setchc bkc 0 1 put
25
1 Hptc0 H10.07 9.5 Z90.5596 83.5232 m .2798 .7277 7 55.3898 (PROPERTY)d155.3966 h .2798 .7277 5 38.6007 (OF UOP)dbkc 0 0 putend%%QRKPageEnd At the end of every pageendp At the end of every page showpage At the end of every page %%PageTrailer At the end of every page %%Trailer Only on the last page of the file end Only on the last page of the file%%EOF Only at the end of the file
26