The contents of this page is a grab-bag of information on the original SDRTool Motif Version. Some of it's pertinent to the Web version, some not. Basically in this version, fill in what you like to the fields.
If you specify a good email address in the Originator field we can email you confirmation that a pseudo-SDR was created, otherwise not much will happen after you apply one.
Also, in the Motif version, selecting an SDR Type (Software, Hardware, etc.) generally caused a popup to appear with a customized-per-project list of items to further detail the area of the problem. In the case of the hardware list the popup contained a radio-box list of all the hardware components on the given project. We didn't implement this here so nothing happens when you select the SDR Type.
The Edit/View links, in the Motif version brings up your favorite editor inividually configurable) on a file that gets saved and tracked via SCCS or RCS through the life of the SDR. Here we just bring up a simple text area.
One more thing. Where it says below about certain fields bein enterable or not enterable by certain users, this applies to the Motif version. You can change any or all fields on the Web version (currently). Also some of the fields in the Motif version are "smart" fields, like the NEW/ID# field which does not let you type a bad format value (other than one that's too short) into it, and the Hours field that enforces XX.X format. Not here - no enforcement of anything is done.
Now, the help file from the Motif version:
Id#/NEW: Allows you to type in either NEW or an Id in the form A##### ------- where A is one of N,D,H,S,T,V and the #'s are numbers. If you specified NEW, continue filling in the rest of the fields required and Press Apply to enter the new SDR (it will then give you an N##### for that SDR; CM will assign the appropriate permanent number). To query an existing SDR, type in the number in this field and press TAB or the Apply button and the database will be queried. Priority: The following are the definitions of SDR priority. This should be -------- your best guess, CM may override. 5 - Out of Scope - would be nice to have, time permitting 4 - Minor Problem - low priority but should be done 3 - Functional Bug - should be fixed but may be worked around in the interim 2 - Requirement Conflict 1 - Highest Priority - Stops the system - fix ASAP Title: Required for new SDRs - quotes may be stripped out to prevent ----- SQL horkage. Status: Current state of SDR. Users are limited as to what state they may ------ change the SDR to depending upon the current state. It won't let you do it if you're not allowed. The status values are the following (provided in case you get a report with the numerical equivalents only): New/CCB1 = 1 - just created or back to CCB1 after assessment Assess = 2 - Assigned To user is assessing the problem Assigned = 3 - Assigned To user is working the problem CCB2 = 4 - Assigned To user has completed changes and files are ready to be turned over to CM Resolved = 5 - CCB2 has approved the changes and files may now be turned over to the CM baseline Rejected = 6 - CCB has rejected this fix for reasons outlined in the Comments CM Eval = 7 - CM has turned over the files for a resolved SDR and the CM baseline awaits promotion Promote = 8 - CM has promoted the baseline relative to this SDR Originator: Not editable by users, automatically entered when SDR is created. ---------- Only the Originator, the Assigned To and CM can change the contents of any of the EDIT/VIEW Files and have them saved when Apply is pressed. The only exception to this is the Comments file which can be changed by anyone. Assigned To: Not editable by users, automatically entered when SDR created. ----------- Only the Originator, the Assigned To and CM can change the contents of any of the EDIT/VIEW Files and have them saved when Apply is pressed. The only exception to this is the Comments file which can be changed by anyone. The field next to the Assigned To text entry field is for the person named in the Assigned To field to use to enable one or more other engineers the capability of updating the Edit/Text files on this SDR. We found that some SDRs got assigned to a lead person who then had one or more of their flunkies do the work. Other times a change was required by both the database person and the MMI person so it made sense to let the "assignee" coordinate updates but not require him to have to actually update the files. This is a comma delimited list of users whom the "assignee" deignates as being allowed to change the SDR files. Date Originated: Not editable by users, automatically entered when SDR --------------- created. Date Assigned: Not editable by users, automatically entered when SDR ------------- created. Reflects the date assigned for assessment if Status is Assess, date assigned to be worked if Status is Assigned. If SDR is assessed then later assigned, only the Assigned date will be saved for posterity. SDR Type: Choose one and a corresponding window will popup with subcategories. -------- Choose the most applicable one (only 1 allowed). If unknown, so choose. Originator, Assigned To & CM may override later. Category: This is a generic field used for various & sundry things throughout -------- the like of a project (and easy to change in midstream). We initially used it to track DTandE threads defined by our lead systems engineer. Later, during OandM, the customer defined the jobs and funding through a series of tasks, so we changed the label to "OandM TASK ##" and used it to associate SDRs written for enhancements to the defined tasks. Other projects use this field for special control numbers, build identifiers, etc. Basically, put anything in this field or leave it blank. Hours: Number of hours required to make the fix. This ought to be filled in ----- when the SDR is turned over to CCB2 by the Assigned To person. You can specify fractional hours to the hundredths of an hour (e.g. 5.25). Currently not checked but the field won't let you type in a non-numeric or bad range value. This is a bookkeeping thing only. Date Due: For a person assigned to Assess the SDR, this represents the date -------- the CCB would like the assessment. For the person assigned to do the work, this is the date the work should be done. ONLY CM can change this field. Date Closed: This represents the date the SDR was closed. Closure for the ----------- tool means the date it changed status to Resolved or Rejected however CM may change this at any time and CM is the only one who can change it.
By pressing the corresponding button, an editor is invoked to allow you to view or modify the appropriate text section, contents of which is described below. Anyone can change the contents of the Comments section, HOWEVER ONLY THE ORIGINATOR, ASSIGNED TO and CM can change the contents of the other files. You'll still get the editor up and you'll still be allowed to change the file contents, but when you press Apply, if you are not one of the above then the file contents are discarded. The file you are viewing is merely a copy which does not get replaced until you save it from the editor, leave the editor and press the Apply button.
DESCRIPTION: Description of problem, (ie: file not updated). ----------- also, define the program impacts if the problem is not corrected. PROPOSED SOLUTION: Assessors solution to the problem, (ie: file may not be ----------------- opened when update is attempted, try opening). FILES MODIFIED: Files fixed (including new make files) and location of turnover. --------------- The location should be specified as a full pathname where CM can find the files you have changed in their CHECKED IN form. Format for this file is IMPORTANT and as follows: Blank lines and lines with a pound sign in column one are ignored so you can use # lines for comments if you like. There must be a cd command for each set of files from a different path listed; format: cd pathname Specify each file, one per line, optionally followed by the sccs revision code (try to supply it whenever possible) of the /devel version you have checked in. Example: Say you just finished an SDR & changed the following files: Cc51_system_messages.def Cc2_utilities.h Cc23_emptyline.c and Cc23_catlen.c & when you checked them in, sccs reported the following revision codes, respectively: 1.28 1.35 1.3 1.2 The minimum contents of the files modified file should be as follows: cd /devel/c/c5/c51 Cc51_system_messages.def 1.28 cd /devel/c/c2 Cc2_utilities.h 1.35 cd /devel/c/c2/c23 Cc23_emptyline.c 1.3 Cc23_catlen.c 1.2 Files in this list are REQUIRED to have: - A comment in the Revision History under DESCRIPTION OF WORK including what was changed and the SDR number (preferably on the same line as the date & your name. - Files must be checked in to /devel's SCCS - The file's sccs id keywords must be in the correct form. In other words, when you check out the file for editing, there should appear somewhere in the file the following sequences: %W% %G% COMMENTS: Everyone can edit this field. CM will be using this field to --------- document the results and actions of the review boards. Note: if you are not the assigned person of the SDR and you're adding a comment you need to send a separate mail message to the assigned person and cm stating that you modified the SDR. Formerly the Impacts file - SDRs prior to N00121 may have information relative to the former name. PROBLEM: Exact cause of problem, (ie: path to file is incorrectly constructed). -------- TESTING: What unit testing needs to be run to verify that the resolution -------- was accepted. STEPS TO RECREATE: Exact steps/conditions needed to replicate the problem. ----------------- RESOLUTION: How the problem was fixed, (ie: added extension to filename). ----------- BUILD INSTRUCTIONS: Any special CM instructions such as changes needed to the ------------------ makefile, NEW routines/file being turned over, obsolete routines/files to be deleted, etc. This file MUST contain either the word NONE or special instructions when the SDR is turned over to CCB2 from an ASSIGNED state or the CCB will reassign the SDR back.
FOR TEXT,VI,EMACS EDITORS: ------------------------- 1. THE DEFAULT EDITOR FOR THE SDR TOOL IS THE 'textedit', the OpenLook editor supplied with the Suns. Note: when you are using this editor in the tool under the edit/view section, if the file does not exist textedit will prompt you to create it - please confirm creation. 2. TO USE 'VI' EDITOR, PUT THIS IN YOUR .LOGIN FILE: setenv SDREDITOR "/usr/local/bin/xvi" 3. TO USE 'EMACS', PUT THIS IN YOUR .LOGIN FILE: setenv SDREDITOR "/usr/local/bin/emacs"
** 1. HOW TO INITIATE THE SDR TOOL. A. AT THE :PROMPT TYPE IN sdrtool. (ignore any X Toolkit warnings if you see any) ** 2. Use the TAB to move from different fields. (please review the sdr tool flow and functions sheets attached). Some of the fields are not editable by the user, only the CM account (such as the dates, etc.). ** 3. To look up an existing SDR: A. Enter either the original "N" number or the Permanent "D","T","S", etc. number (if none is assigned, the Permanent number will match the original number) in the Id#/NEW field then press TAB. This causes a database query for that SDR and, if found, the database record will be filled in. B. You can have a copy of the entire contents of the SDR mailed to you by pressing the Mail Me a Copy button after you have one displayed. This can also be accomplished outside the tool using the showsdr script (run it without any parms to see how). ** 4. To change something about an SDR: A. Only the originator, the user assigned the SDR and CM can change things about an SDR after it has been enterred. You will be allowed to look at any of the files (and even make changes to them) but if you are not one of the above YOUR CHANGES WILL NOT BE SAVED. The ONLY exception to this is the Comments file which anyone can edit. B. Changes are only kept AFTER you press the Apply Button at the bottom and ONLY if you meet the criteria above. You may throw away any changes you make by simply terminating the tool before Applying or pressing the Abort button at the bottom. This includes changes to files. Any changes you make to files will get logged with date/time and your username when you press the Apply button. ** 5. To enter a new SDR: A. Type the word NEW in the Id#/NEW field and fill in all other pertinent information to the fields as well as to the files. Some of the fields cannot be changed by you and some will be provided when you press the Apply button (such as Originator (your login), Date Originated, etc.) Some fields are required such as Title. B. Press the Apply button. A new ID will be assigned (an "N" number) and you will be mailed a copy (as will CM). ** 6. IF you need help using the tool please contact me. (cm) ** 7. If you have any complaints or bugs contact Sydd......
THE FOLLOWING ARE TYPES OF SDRS
WARNING: This table is all skewed - it needs some work - pay no attention to the man behind the curtain!
SEND FILLED IN REQUIRED AVAILABLE STATUS MAIL TO PERSON BY TOOL FIELDS FIELDS ------ ------- ------ --------- -------- --------- NEW/CCB1 CM originator ID number title priority originator originator description type board members date originated thread comments steps to recreate proposed solution problem CCB1 assess/assigned/ rejected assigned to date due priority -------------------------------------------------------------------------------- ASSESS person person date assigned New/CCB1 assigned assigned date and person type to to added to thread the end of hours any file comments opened steps to recreate proposed solution problem -------------------------------------------------------------------------------- ASSIGNED person person date assigned CCB1/CCB2 assigned assigned date and person type to to added to thread the end of hours any file comments openned steps to recreate proposed solution problem resolution files modified testing build instructions -------------------------------------------------------------------------------- CCB2 CM CCB1 CCB1/resolved/rejected board members build instructions (MUST) -------------------------------------------------------------------------------- RESOLVED CM date closed originator person assigned to -------------------------------------------------------------------------------- REJECTED CM date closed originator person assigned to -------------------------------------------------------------------------------- CM EVAL CM CCB2/REJECTED/PROMO/ * CM WILL USE THIS FIELD AS A HOLDING PLACE FOR SDRS THAT HAD FILES TURNED OVER AND TESTED. DIFFED AND PLACED INTO THE CM SCCS BASELINE. THESE SDRS/FILES WILL BE CANDIDATES FOR PROMOTION. -------------------------------------------------------------------------------- PROMO CM CCB2/REJECTED/RESOLVED * CM WILL USE THIS FIELD FOR SDRS/FILES THAT HAVE BEEN EVAL'ED AND CAN SUCCESSFULLY BUILD A RUNABLE EXE. THE FILES/SDR WILL GET TESTED, CAPTURED. THEN THE SDR WILL BE MOVED TO A RESLOVED STATED.
ORIGINATOR: IS THE CREATOR OF A NEW SDR.
ASSESSOR: SHOULD REVIEW THE PROBLEM AND COMPLETE THE REQUEST FOR ANALYSIS AS SPECIFIED.
ASSIGNED (FIXER): IS DETERMINED BY CCB1, THE FIXER MUST EVALUATE THE THE PROBLEM AND DETERMINE THE APPROPRIATE TECHNICAL SOLUTION. WHEN THE SOLUTION HAS BEEN DETERMINED THE FIXER WILL UPDATE THE SDR AND TURNOVER THE FILES.
File Edited Indicators
If you edit one of the nine Edit / View files, and a /tmp file is created, the labels on the Edit / View buttons will have an asterisk appended to them. The asterisk indicates that this file exists in /tmp but has not yet been applied (i.e. saved).
Unapplied Files Notification
Other than the Comments file, which any user can change for any SDR, the only users allowed to apply changes to the Edit / View files are the Originator, the Assignee, and the CM user. This has always been the case, however the tool never told you that your files were not applied. Now, after pressing Apply in an attempt to save changes you made to one or more of the files when you do not meet the above criteria, a new "beep message" appears at the bottom warning you that files may not have been applied AND the contents of the files is mailed to you in a single message. This enables you to possibly forward the message to the appropriate person to get the changes made. It also prevents you from losing work and not knowing about it.
CM Operations Popup
When a file is turned over to CM, a special script is normally run against the contents of the Files Modified file to verify the following information:
Then, once everything checks out, the CM person will perform the turnover of the files. Normally, the person who turned over the SDR to CCB2 has no idea when these latter two steps were taken without asking. NOW YOU DO! Place the mouse pointer over the Orig #: box and press the Select (left) button. A new Popup appears called CM Operations, which contains 4 buttons similar to the following:
________________________________ _____________________________ | Validate Files Modified | | Perform CM Turnover | -------------------------------- ----------------------------- ________________________________ _____________________________ | See Validate Results | | See Turnover Results | -------------------------------- -----------------------------
You'll notice first that the Perform CM Turnover is deseensitized (i.e. grayed out) - only CM is allowed to use this button.
The two 'See' buttons act just like the Edit / View buttons in the main window: they bring up the editor on a file. However, if the Validation or Perform steps have not been done (and you can tell right away because if they had been, the buttons would be reverse video just like the Edit / View buttons indicating there is a file saved with this SDR), no editor will come up. Thus you can use these two buttons to see if the Validate or Perform steps have been done yet on this SDR after it has been turned over to CM.
You can also use the Validate Files Modified button to perform the Validate yourself. Results will be placed in the appropriate file and the corresponding 'See' button will be highlighted when the job is done. You can then popup the file, examine the results, and make any fixes needed before turning the SDR over to CM. This will save CM time. The output may look a bit confusing at first, so get Sydd or Annie to help you through the first few times so you'll know what will be accepted & what won't. By the way, between the time you press the Validate Files Modified button and the time it completes its task (which may range in the minutes if you have a lot of files in the Files Modified file) the Validate Files Modified button's label will have square brackets around it. This is to indicate that it is still running the command. You can still do other things with the SDR, but I suggest you wait until the task is complete (the brackets go away).
Also note that the See Validate Results may go reverse video while the Validate Files Modified task is still running. This will probably happen when you leave the editor of any other Edit / View file. This is normal. You'll be tempted when this happens to look at the results, but if you try with the See Validate Results button, you'll get a beep message: "That file is already being modified" Once the brackets on the command button go away, you should be able to view the results.
WARNINGS: If you attempt to leave the sdrtool with the Validate Files Modified task still running, it will probably not completely terminate until the task completes. In other words, the main window may go away, but the tool may not exit until the child task is done. Don't kill the sdrtool when this happens. Just let it complete on its own.
If you change the Files Modified to try to fix errors in its syntax reported by the filmon_verify script run when you press the Validate Files Modified, you'll have to Apply the change to the Files Modified file before retrying the Validate Files Modified button again: the validation is performed against the LAST APPLIED Files Modified file, not the last one saved in /tmp.
Once the SDR has been turned over by CM, you probably won't be able to press the Validate Files Modified button anymore on that SDR, since that would not only be a useless thing to do (since all the files will have been turned over, the new results will indicate that all of the files are IDENTICAL to the version in CM), but you'll replace the output from the last time the validate was performed prior to the turnover.
|