SyddWareSDRTool-WEB HelpSyddWare

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:


SDR TOOL INFORMATION ON THE DATA ENTRY FIELDS

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.

SDR TOOL INFORMATION ON THE EDIT/VIEW FIELDS

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.
                     

EDITOR INFORMATION

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"

GENERAL TOOL INFORMATION

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


SDR Tool Flow

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.

FUNCTIONS

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.


* N * E * W * * F * E * A * T * U * R * E * S *


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.



Jump to the Syte Map
SyteMap
SyddWare Logo DuckyPage © SyddWare, Jeffrey R. (Sydd) Souza *