RESEARCH PAPER #2 CHECKLIST: Here's a checklist that you should use in the writing of your second Research Paper for the USC SAE 574 Class. This is what I use in grading papers. This isn't meant to indicate a strict FORMAT or an OUTLINE-- it's just a checklist. Please refer to the class website and lecture notes for detailed instructions on formatting your paper. ( ) Title Page? ( ) Abstract (with a brief biography)? ( ) Introduction or Background or History? ( ) A general description of the system? ( ) Analysis using Lectures 6 through 9? ( ) Optional analysis using Lectures 10 through 12? ( ) A summary or conclusion? ( ) References or bibliography or footnotes? You can use any of the analytical techniques described in Lectures #6 through #9 in the accomplishment of your second Research Paper, as appropriate to your chosen subject. But be sure to include AT LEAST the following: Analysis to be performed from Lecture #6: ( ) What is the model of the design and usage of at least one major portion of the system? (At least one paragraph and at least one UML Use Case diagram and at least one Class or Structure diagram, and at least one Activity or Sequence diagram-- additional diagrams are optional but worthy of extra credit) Analysis to be performed from Lecture #7: ( ) What is the top-level operational view of the system? (At least one paragraph and at least one top-level OV-1 figure) Remember that an OV-1 is a cartoon that shows how the system is operated, not how it is constructed. ( ) What is the operational node connectivity of the system? (At least one paragraph and at least one top-level OV-2 figure, other OV's are optional but worthy of extra credit) Remember that an OV-2 is essentially a flow diagram of the system operation that shows the major operations and the kind of information that is passed from one operation to another. ( ) What are some of the key information exchange requirements of the system? (At least one paragraph and an OV-3 figure with at least 6 key data exchanges identified and characterized in OV-3 format) ( ) What is the top-level system view of the system? (At least one paragraph and at least one top-level SV-1 figure) Remember that a SV-1 is essentially a block diagram of the system design that shows the major parts and interfaces between the major parts. Be careful not to confuse an SV-1 with an OV-2: an SV-1 shows the parts of the DESIGN (i.e. how the system is built), whereas an OV-2 shows the USE of the system (i.e. how the system is operated and used). ( ) What are the system interface details of the system? (At least one paragraph and at least one SV-3 figure, other SV's are optional but worthy of extra credit) Analysis to be performed from Lecture #8: ( ) What is enterprise architecture in which the system inhabits? (At least one paragraph and at least one top- level Zachman Framework or other enterprise architecture figure, such as a FEA Business Reference Model plus FEA Service Reference Model plus FEA Performance Reference Model plus FEA Technical Reference Model plus FEA Data Reference Model) ( ) What are the services to be provided by the system, and who are the customers that would benefit from such services? (At least one paragraph and at least one top-level service model figure, such as a FEA Service Reference Model showing at least one major service domain, one major service type, and at least three service components with descriptions) Analysis to be performed from Lecture #9: ( ) What is the ontology of at least one major portion of the system? (Develop a taxonomy that describes at least three key portions or objects of the system, including properties (domain & range) that govern how those parts can be used, e.g. “X is part of…”, “value of x must be…”; then provide at least three Inference Rules that characterize the behavior between those key objects using simple “if… then…” statements using the key descriptors, and describe how the system works IN TERMS OF THE KEY OBJECTS described in the Taxonomy) ( ) What are the spiral or evolutionary development stages that were (or will be or should be) used in the system, e.g. key steps, prototypes, simulations, risk mitigation activities, steps that incorporated lesson-learned from the above? (at least one paragraph and at least one top-level figure) What if you can’t find information about one or more of the above items on the checklist? DO NOT SKIP THAT ANALYSIS, and assume that it is not applicable! Such omission will significantly impact your grade. You may need to recommend what should be (or could be) added to the system, and then analyze that recommendation. If appropriate, you can point out design characteristics of your chosen topic as covered in Lectures #10 through #12, however, this is NOT REQUIRED. But such analysis can improve your grade, i.e. as "extra credit". PLEASE NOTE that a 2nd Research Paper usually requires such extra credit to obtain a grade of "A minus" or above! The second paper is a bit more "free format" in that the specific analytical techniques are fewer in number; however you'll need to provide sufficient depth and breadth of analysis to get a good grade. My intent in providing you with this list is to HELP you in accomplishing a comprehensive analysis of your chosen topic, and to provide some insight into the kind of technical "meat" that I'm looking for in considering your paper's grade. N.B. very few papers are worthy of an “A” grade in this class unless they EXCEED most of the requirements given in the Research Paper Checklist (i.e. have more that the minimum required). The checklist descriptions represent the minimum requirements for a passing grade (“B”) in the class. And to deserve an “A+” grade, a paper would have to be of sufficient quality and depth of analysis that it could be used as a Guest Lecture for this class. One of the metrics used to grade papers is the volume of analysis, which should be at least 15 pages of analysis in terms of 12 point text in Times New Roman font, single spaced, with 1" top and bottom margins and 1-1/4" left and right margins (and figures deleted unless they specifically contribute to, or are part of the analysis). HINTS! Common mistakes that students make include: * No title page. Believe it or not, this happens! In many of the USC Distance Education Network (DEN) classes (but not this one), students are required to submit their papers via e-mail or a fax to the DEN, rather than online via DEN Assignments. In such cases students may be used to filling out a DEN submittal form. The DEN submittal form is not a title page! * No abstract, or missing a biography in the abstract. Yes, you have to both provide an abstract for approval AND place that abstract on the second page of your paper. If you have adjusted your abstract after obtaining approval of your chosen topic, then the ADJUSTED abstract should be used in the paper. * No clear linkage of analysis to the checklist. * Analysis text provided, but without a required diagram (see checklist above for required diagrams). * Figures(s) without a detailed explanation of content. You should not succumb to the temptation of filling in blank space or attempting to increase the length of your paper with meaningless figures (including diagrams, graphics, artwork, and tables). All figures should have a reference in your text (a figure number, a table number, etc.). And your text should include at least one paragraph that explains the figure in terms of the analysis that you’re providing. In short, everything in your paper should be relevant. * Missing one (or more) of the other items on the checklist. * UML Use Case Diagram missing system boundary (dashed line box). * OV-2 without detailed indication of content of needlines or description of content of operational nodes. * SV-3 without descriptive text in matrix cells, or with blank cells (don't just put a dot or an * to indicate an interface, put in a couple of words to explain the interface-- and if no significant interface then mark that cell with a dash or N/A or shading). * Zachman Framework missing rows or columns (must be a 6-by-6 matrix), or missing detailed description; OR FEA missing major components (should be BRM + PRM + SRM + TRM + DRM) if substituting for a Zachman Framework. * Generic FEA SRM for Service Domain, Service Type, and Service Component-- must be tailored! Or else only one or two service components described, or missing Service identification (must identify Domain, Type, and Component) * Ontology provides taxonomy but missing inference rules (IF…THEN relationships), or taxonomy presents less than three major objects/parts of the system, or inference rules not related to objects in the taxonomy. * Generic Spiral Development figure, copied directly from the class figure-- must be tailored! * Limited depth of analysis (paper too short: less than 20 pages in total or less than 15 pages of detailed analyses). For example, a 50 page paper filled with detailed technical descriptions and fancy color figures/pictures of the system (but only 5 pages of net-centric analysis via the checklist above) will not receive a good grade. * No (or improper) references, footnotes, or bibliography. Surely you must have used something as a reference in the development of your paper, even if you are a “world expert” on your chosen topic! And please remember to properly cite the SAE 574 class lectures if you use material from those lectures in your paper. Remember also that too many references to uncontrolled Internet sites may detract from your paper’s grade. * Improper citations for quoted text or copied artwork. Yes, you can “borrow” artwork or a figure or table from another source, but you must properly cite that source! And yes, you can include direct verbiage from another source, but you must properly designate those words in quotations and properly cite that source! (This includes the case where you are the author of the “other source”!) Failure to properly reference copied text will be treated as a violation of academic integrity! * Excessive amount of quoted text. This includes large amounts of text quoted from papers that you wrote for a different class! * Speling errorz. Please remember to do a “Spell Check” before submitting your paper. If a quoted source includes a spelling error, simple place the designation (sic) after that word to show that you weren’t the one that made the error. Also remember that most spell-checkers are not a substitute for good editing (for example, deciding whether “threw” or “through” is the correct word in a given context). Ken Cureton cureton@usc.edu