Difference: APPXSourceCodeControlSystem (1 vs. 19)

Revision 192012-04-08 - ChrisBrower

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

APPX Source Code Control System

Line: 146 to 146
 
  1. Scope Maint - Need to be able to see all higher level scope records.
  2. Projects - need to be able to change the level that a project is attached to - Suite, Version, Application. For example, if attached to suite, need to be able to move the project to a version or individual application.
  3. Projects - it would be nice if we could add a Project directly & specify which Suite/Ver/App it pertained to, instead of adding it in Suite/Versions/Applications first. See #12 above.
Added:
>
>

Comments:

Read what other users have said about this page or add your own comments. 


<--/commentPlugin-->
  -- SteveFrizzell - 29 Oct 2007

Revision 182012-04-05 - BredaHennessy

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

APPX Source Code Control System

Line: 11 to 11
 

Suites / Versions / Applications

Changed:
<
<		Within the source code control system, applications can be grouped by version and by suite. For example, you might define a suite for the the APPXBANG Business Applications. Within that suite, you might define three versions; a production version (00), a test version (01), and a development version (02). Each version would include the 12 applications that make up the APPXBANG Business Application suite. In this example, there would be 36 separate applications defined in the APPX Application file. An application must be defined in the APPX Application file before it can be included in a source code control system suite and version.
>
>		Within the source code control system, applications can be grouped by version and by suite. For example, you might define a suite for the APPXBANG Business Applications. Within that suite, you might define three versions; a production version (00), a test version (01), and a development version (02). Each version would include the 12 applications that make up the APPXBANG Business Application suite. In this example, there would be 36 separate applications defined in the APPX Application file. An application must be defined in the APPX Application file before it can be included in a source code control system suite and version.
 

Projects / Jobs / Tasks

Within the source code control system, development tasks are created and managed and are grouped by job and by project. Projects can be created for a Suite, a Suite/Version, or a Suite/Version/Application.

Line: 21 to 21
  When defining the scope for a project, job, or task it is sometimes easier to specify the exceptions. For example, you might define a scope to Exclude all design objects and then, by exception, you might define additional scope records identifying specific design objects to be included. Or, you might take the opposite approach and define a scope to Include all design objects and then, by exception, you might define additional scope records identifying specific design objects to be excluded.
Changed:
<
<		Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.
>
>		Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, it's Versions, or it's Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.
 

Notes

Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects.

Line: 81 to 81
 Scopes can be specified at the Suite, Version, Application, Project, Job and Task levels (highest to lowest). A scope at a lower level modifies or overrides a scope at a higher level. Scopes at the same level are combined to get a net effect. For example, you might have a Scope that allows changes to all subroutines, and another Scope that disallows changes to a specific subroutine.

Projects

Changed:
<
<		Projects can be defined for a Suite, a Suite/Version, or for a Suite/Version/Application. Each project is identified by a 10-character Project ID. Project ID's must be unique at each Suite/Version/Application level. In other words, you can create more than one project with the same Project ID as long as the projects are defined for different Suites, Suites/Versions, and Suites/Versions/Applications.
>
>		Projects can be defined for a Suite, a Suite/Version, or for a Suite/Version/Application. Each project is identified by a 10-character Project ID. Project IDs must be unique at each Suite/Version/Application level. In other words, you can create more than one project with the same Project ID as long as the projects are defined for different Suites, Suites/Versions, and Suites/Versions/Applications.
  Depending on which level a project is defined, there is an implied scope constraint. For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version.

Jobs

Line: 92 to 92
 

Tasks

Changed:
<
<		A Task is the lowest level of work. Task are subordinate to Jobs, which are subordinate to Projects. Each Project may contain multiple Jobs, and each Job may contain multiple Tasks.
If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against.
>
>		A Task is the lowest level of work. Tasks are subordinate to Jobs, which are subordinate to Projects. Each Project may contain multiple Jobs, and each Job may contain multiple Tasks.
If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against.
 

Notes

Revision 172010-02-24 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

APPX Source Code Control System

This page describes the Source Code Control System feature of APPX Application Design.

Changed:
<
<		The Source Code Control System in APPX 5.0.1 has a variety of issues which prevent it from being used successfully. The status of the Source Code Control System has therefor been changed from "Released" to "Experimental". You should not attempt to use this feature until the issues have been resolved and the status is changed to Released.
>
>		The Source Code Control System in APPX 5.0.1 has a variety of issues which prevent it from being used successfully. The status of the Source Code Control System has therefore been changed from "Released" to "Experimental". You should not attempt to use this feature until the issues have been resolved and the status is changed to Released.
 

Concepts

Revision 162010-02-09 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

APPX Source Code Control System

This page describes the Source Code Control System feature of APPX Application Design.

Added:
>
>		The Source Code Control System in APPX 5.0.1 has a variety of issues which prevent it from being used successfully. The status of the Source Code Control System has therefor been changed from "Released" to "Experimental". You should not attempt to use this feature until the issues have been resolved and the status is changed to Released.
 

Concepts

Line: 22 to 24
 Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.

Notes

Changed:
<
<		Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects.
>
>		Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects.
 

Suites

The APPX Source Code Control system requires suites that are to be managed must first be defined. The Suite Maintenance program can be used to enter and edit suites.

Line: 36 to 40
 

Design Access

Design access controls what level of access is allowed for the applications within a suite. Design access must be specified for each suite and is inherited by each application in the suite in the event that design access is not specified for the application or the application's version. The following design access levels are allowed:

Changed:
<
<
  • NO ACCESS - Does not allow design objects to be viewed or edited.
  • VIEW ONLY - Allows design objects to be viewed but not edited.
  • NOT TRACKED - Allows design objects to be viewed and edited.
  • TRACKED - Requires that a Project/Job/Task be identified before a design object can be viewed or edited.
>
>

  • NO ACCESS - Does not allow design objects to be viewed or edited.

  • VIEW ONLY - Allows design objects to be viewed but not edited.

  • NOT TRACKED - Allows design objects to be viewed and edited.

  • TRACKED - Requires that a Project/Job/Task be identified before a design object can be viewed or edited.

 

Scope Defaults

Each Suite must include default scope specifications indicating that all design objects are to be automatically included or excluded and which design modes are allowed for included objects.

Line: 86 to 91
 If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against.

Tasks

Changed:
<
<		A Task is the lowest level of work. Task are subordinate to Jobs, which are subordinate to Projects. Each Project may contain multiple Jobs, and each Job may contain multiple Tasks.
If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against.
>
>		 A Task is the lowest level of work. Task are subordinate to Jobs, which are subordinate to Projects. Each Project may contain multiple Jobs, and each Job may contain multiple Tasks.
If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against.
 

Notes

Added:
>
>
 Use this option to enter or view any free form notes. Notes can be associated with Suites, Versions, Applications, Projects, Jobs, Tasks and Objects.

Bugs:

Line: 107 to 113
 
  1. Projects/Jobs/Tasks Maint - Add mode is not allowed. I can only add a project from within Application Suites maint.
  2. Projects/Jobs/Tasks Maint - Object record does not show correct notes count.
  3. projects/Jobs/Tasks maint - When viewing Full Log Detail, Object record has no owner. What is the owner field used for?
Changed:
<
<

  1. Fields are missing documentation -Fixed

>
>

  1. Fields are missing documentation -Fixed

 
  1. Design - Source Code Control panel should not refer to "# for Xfer"
Changed:
<
<
  1. Design - Source Code Control panel refers to "# In Use". Don't know what this means. - It's the number of Objects with an Active status.
>
>
  1. Design - Source Code Control panel refers to "# In Use". Don't know what this means. - It's the number of Objects with an Active status.
 
  1. Design - Source Code Control - Select Project. Column headings are screwed up.
  2. Design - allowed me to select a task that had a status of pending. - Changed the status to Active automatically. Seems like the status should be Assigned before it can be selected.
  3. Design - SCC - Select Project - Does not show all available projects. Maybe because they all had the same Project ID?
Line: 121 to 127
 
  1. Design - Help pulldown list all items twice
  2. Design - SCC panel on menu still showed 0 in use after I had made a change to an input object.
  3. Design - SCC Log detail - shows changed=N for an input object after I made a change.
Changed:
<
<
  1. Design - Fixed - Tried to add a comment to an audit history record. Would not save comment.
>
>
  1. Design - Fixed - Tried to add a comment to an audit history record. Would not save comment.
 
  1. Design - SCC panel on design menu has a label "Control Level". System Admin uses "Design Access". We need to be consistent.
  2. XFER - SCC let me select object that was not complete.
  3. XFER - SCC Status values are IDENTIFIED, ACTIVE, and COMPLETED? What is this field??
Changed:
<
<
  1. XFER - SCC needs to allow xfer of Project, Job, or Tasks based on Dependence & Mgt Status. Should individual objects be allowed to be excluded?
  2. XFER - Fixed - status column not lined up.
>
>
  1. XFER - SCC needs to allow xfer of Project, Job, or Tasks based on Dependence & Mgt Status. Should individual objects be allowed to be excluded?
  2. XFER - Fixed - status column not lined up.
 
  1. XFER - two counts in footer - What are they?
  2. XFER - Clear All and Select All buttons don't seem to work.
  3. XFER - Selected For Xfer logic field should not allow null value
  4. SCC Inquiries - Menu says "Object History" - screen says "Object Inquiry".
  5. SCC Inquiries - Menu says "Objects Inquiry" - screen says "Audit Information - Search".
Changed:
<
<
  1. Project Maint - Fixed - need to enter field doc.
>
>
  1. Project Maint - Fixed - need to enter field doc.
 
  1. SCC Note - Entered notes via Opt 96. Did not select a Project/job/task. Now those notes show on every object via Opt 96.
  2. SCC Note - There is a 'Process' pulldown menu that shows one item - 'SC- SCTRACK- CUR STATUS' throughout Application Design. Is this supposed to be there?

Enhancements:

  1. Scope Maint - Need to be able to scan on Object Name field.
  2. Scope Maint - Need to be able to see all higher level scope records.
  3. Projects - need to be able to change the level that a project is attached to - Suite, Version, Application. For example, if attached to suite, need to be able to move the project to a version or individual application.
Changed:
<
<
  1. Projects - it would be nice if we could add a Project directly & specify which Suite/Ver/App it pertained to, instead of adding it in Suite/Versions/Applications first. See #12 above.
>
>
  1. Projects - it would be nice if we could add a Project directly & specify which Suite/Ver/App it pertained to, instead of adding it in Suite/Versions/Applications first. See #12 above.
  -- SteveFrizzell - 29 Oct 2007

Revision 152008-09-15 - SteveFrizzell

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="APPXAdministrator"
>
>
META TOPICPARENT name="APPX500Features"
 

APPX Source Code Control System

This page describes the Source Code Control System feature of APPX Application Design.

Revision 142008-08-26 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"
Deleted:
<
<
 

APPX Source Code Control System

This page describes the Source Code Control System feature of APPX Application Design.

Line: 23 to 22
 Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.

Notes

Deleted:
<
<
 Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects.

Suites

Line: 54 to 51
 The scope default values are not inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)
Scope Type
Deleted:
<
<
 
  • INCLUDE - All design objects are included within the scope of the suite.
  • EXCLUDE - All design objects are excluded from the scope of the suite.
Allow Add?
Line: 75 to 71
 Each Version of a Suite may have one or more Applications. The same Application may exist in more than one Version. However, a specific application/version may only be assigned to a single suite.

Application Attributes

Scope

Added:
>
>		Scopes allow you to control what objects can be accessed as part of this Application, Suite, Task or Project. Scopes work with Design Access, and in some cases, have no meaning. For example, if Design Access is NO ACCESS, then Scope is irrelevant, since design access is prohibited.

Scopes can be specified at the Suite, Version, Application, Project, Job and Task levels (highest to lowest). A scope at a lower level modifies or overrides a scope at a higher level. Scopes at the same level are combined to get a net effect. For example, you might have a Scope that allows changes to all subroutines, and another Scope that disallows changes to a specific subroutine.

 

Projects

Projects can be defined for a Suite, a Suite/Version, or for a Suite/Version/Application. Each project is identified by a 10-character Project ID. Project ID's must be unique at each Suite/Version/Application level. In other words, you can create more than one project with the same Project ID as long as the projects are defined for different Suites, Suites/Versions, and Suites/Versions/Applications.

Changed:
<
<		Depending on which level a project is define, there is an implied scope constraint. For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version.
>
>		Depending on which level a project is defined, there is an implied scope constraint. For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version.
 

Jobs

Added:
>
>		 A Job is the intermediate level of work. Jobs are subordinate to Projects. Each Project may contain multiple Jobs, and each Job may contain multiple Tasks.

If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against.

 

Tasks

Added:
>
>		A Task is the lowest level of work. Task are subordinate to Jobs, which are subordinate to Projects. Each Project may contain multiple Jobs, and each Job may contain multiple Tasks.
If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against.
 

Notes

Added:
>
>		Use this option to enter or view any free form notes. Notes can be associated with Suites, Versions, Applications, Projects, Jobs, Tasks and Objects.
 

Bugs:

  1. Suite Maint - Version count is not correct when two suites have been entered.
  2. Suite Maint - Scope count should display "None" when no scope records have been entered.
Line: 98 to 107
 
  1. Projects/Jobs/Tasks Maint - Add mode is not allowed. I can only add a project from within Application Suites maint.
  2. Projects/Jobs/Tasks Maint - Object record does not show correct notes count.
  3. projects/Jobs/Tasks maint - When viewing Full Log Detail, Object record has no owner. What is the owner field used for?
Changed:
<
<
  1. Fields are missing documentation - document all fields.
>
>

  1. Fields are missing documentation -Fixed

 
  1. Design - Source Code Control panel should not refer to "# for Xfer"
Changed:
<
<
  1. Design - Source Code Control panel refers to "# In Use". Don't know what this means.
>
>
  1. Design - Source Code Control panel refers to "# In Use". Don't know what this means. - It's the number of Objects with an Active status.
 
  1. Design - Source Code Control - Select Project. Column headings are screwed up.
  2. Design - allowed me to select a task that had a status of pending. - Changed the status to Active automatically. Seems like the status should be Assigned before it can be selected.
  3. Design - SCC - Select Project - Does not show all available projects. Maybe because they all had the same Project ID?
Line: 112 to 121
 
  1. Design - Help pulldown list all items twice
  2. Design - SCC panel on menu still showed 0 in use after I had made a change to an input object.
  3. Design - SCC Log detail - shows changed=N for an input object after I made a change.
Changed:
<
<
  1. Design - Tried to add a comment to an audit history record. Would not save comment.
>
>
  1. Design - Fixed - Tried to add a comment to an audit history record. Would not save comment.
 
  1. Design - SCC panel on design menu has a label "Control Level". System Admin uses "Design Access". We need to be consistent.
  2. XFER - SCC let me select object that was not complete.
  3. XFER - SCC Status values are IDENTIFIED, ACTIVE, and COMPLETED? What is this field??
  4. XFER - SCC needs to allow xfer of Project, Job, or Tasks based on Dependence & Mgt Status. Should individual objects be allowed to be excluded?
Changed:
<
<
  1. XFER - status column not lined up. (fixed spf)
>
>
  1. XFER - Fixed - status column not lined up.
 
  1. XFER - two counts in footer - What are they?
  2. XFER - Clear All and Select All buttons don't seem to work.
  3. XFER - Selected For Xfer logic field should not allow null value
  4. SCC Inquiries - Menu says "Object History" - screen says "Object Inquiry".
  5. SCC Inquiries - Menu says "Objects Inquiry" - screen says "Audit Information - Search".
Changed:
<
<
  1. Project Maint - need to enter field doc.
>
>
  1. Project Maint - Fixed - need to enter field doc.
 
  1. SCC Note - Entered notes via Opt 96. Did not select a Project/job/task. Now those notes show on every object via Opt 96.
  2. SCC Note - There is a 'Process' pulldown menu that shows one item - 'SC- SCTRACK- CUR STATUS' throughout Application Design. Is this supposed to be there?

Enhancements:

  1. Scope Maint - Need to be able to scan on Object Name field.
  2. Scope Maint - Need to be able to see all higher level scope records.
  3. Projects - need to be able to change the level that a project is attached to - Suite, Version, Application. For example, if attached to suite, need to be able to move the project to a version or individual application.
Changed:
<
<
  1. Projects - it would be nice if we could add a Project directly & specify which Suite/Ver/App it pertained to, instead of adding it in Suite/Versions/Applications first.

>
>
  1. Projects - it would be nice if we could add a Project directly & specify which Suite/Ver/App it pertained to, instead of adding it in Suite/Versions/Applications first. See #12 above.
  -- SteveFrizzell - 29 Oct 2007
Added:
>
>
 
META FILEATTACHMENT attachment="SuiteMaint1.PNG" attr="" comment="Suite Maintenance" date="1208965624" name="SuiteMaint1.PNG" path="C:\Documents and Settings\steve\My Documents\APPX 4.3\SuiteMaint1.PNG" size="30737" stream="C:\Documents and Settings\steve\My Documents\APPX 4.3\SuiteMaint1.PNG" user="Main.SteveFrizzell" version="1"

Revision 132008-08-25 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"
Added:
>
>
 

APPX Source Code Control System

This page describes the Source Code Control System feature of APPX Application Design.

Line: 6 to 7
 

Concepts

Changed:
<
<
>
>
 

Suites / Versions / Applications

Changed:
<
<		Within the source code control system, applications can be grouped by version and by suite.  For example, you might define a suite for the the APPXBANG Business Applications.  Within that suite, you might define three versions; a production version (00), a test version (01), and a development version (02).  Each version would include the 12 applications that make up the APPXBANG Business Application suite.  In this example, there would be 36 separate applications defined in the APPX Application file.  An application must be defined in the APPX Application file before it can be included in a source code control system suite and version.
>
>		Within the source code control system, applications can be grouped by version and by suite. For example, you might define a suite for the the APPXBANG Business Applications. Within that suite, you might define three versions; a production version (00), a test version (01), and a development version (02). Each version would include the 12 applications that make up the APPXBANG Business Application suite. In this example, there would be 36 separate applications defined in the APPX Application file. An application must be defined in the APPX Application file before it can be included in a source code control system suite and version.
 

Projects / Jobs / Tasks

Changed:
<
<		Within the source code control system, development tasks are created and managed and are grouped by job and by project.  Projects can be created for a Suite, a Suite/Version, or a Suite/Version/Application.
>
>		Within the source code control system, development tasks are created and managed and are grouped by job and by project. Projects can be created for a Suite, a Suite/Version, or a Suite/Version/Application.
 

Scope

Changed:
<
<		Scope is usually used to define the boundaries for a Project, Job, or Task.  In other words, you can use scope to define which design objects are allowed to be viewed, edited, deleted, etc. when a designer is working on a specific Task.  If you want to exercise precise control, scope will let you do that.  For example, you could define a Task to modify the CUSTOMER MAINTENANCE input process and you could specify that only that one specific design object (CUSTOMER MAINTENANCE) is allowed to be changed and that it is not allowed to be deleted. However, on the other extreme, if you, as a project manager, don't want to control access to specific design objects, then you can simply not define a scope for a Task.
>
>		Scope is usually used to define the boundaries for a Project, Job, or Task. In other words, you can use scope to define which design objects are allowed to be viewed, edited, deleted, etc. when a designer is working on a specific Task. If you want to exercise precise control, scope will let you do that. For example, you could define a Task to modify the CUSTOMER MAINTENANCE input process and you could specify that only that one specific design object (CUSTOMER MAINTENANCE) is allowed to be changed and that it is not allowed to be deleted. However, on the other extreme, if you, as a project manager, don't want to control access to specific design objects, then you can simply not define a scope for a Task.
 
Changed:
<
<		When defining the scope for a project, job, or task it is sometimes easier to specify the exceptions.  For example, you might define a scope to Exclude all design objects and then, by exception, you might define additional scope records identifying specific design objects to be included.  Or, you might take the opposite approach and define a scope to Include all design objects and then, by exception, you might define additional scope records identifying specific design objects to be excluded.
>
>		When defining the scope for a project, job, or task it is sometimes easier to specify the exceptions. For example, you might define a scope to Exclude all design objects and then, by exception, you might define additional scope records identifying specific design objects to be included. Or, you might take the opposite approach and define a scope to Include all design objects and then, by exception, you might define additional scope records identifying specific design objects to be excluded.
 
Changed:
<
<		Scope can be defined for Projects, Jobs, and Tasks.  Scope can also be defined for Suites, Versions, and Applications.  If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite.  If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version.  The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.
>
>		Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.
 

Notes

Deleted:
<
<		 
 
Changed:
<
<		Notes can be attached at many different points within the structure of the source code control system.  Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects.
>
>		 Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects.
 

Suites

Changed:
<
<		The APPX Source Code Control system requires suites that are to be managed must first be defined.  The Suite Maintenance program can be used to enter and edit suites.
>
>		The APPX Source Code Control system requires suites that are to be managed must first be defined. The Suite Maintenance program can be used to enter and edit suites.
 

Suite Attributes

Suite ID

Line: 37 to 38
 Each suite has a 30-character description.

Design Access

Changed:
<
<		Design access controls what level of access is allowed for the applications within a suite.  Design access must be specified for each suite and is inherited by each application in the suite in the event that design access is not specified for the application or the application's version.  The following design access levels are allowed:
>
>		Design access controls what level of access is allowed for the applications within a suite. Design access must be specified for each suite and is inherited by each application in the suite in the event that design access is not specified for the application or the application's version. The following design access levels are allowed:
 
  • NO ACCESS - Does not allow design objects to be viewed or edited.
  • VIEW ONLY - Allows design objects to be viewed but not edited.
  • NOT TRACKED - Allows design objects to be viewed and edited.
  • TRACKED - Requires that a Project/Job/Task be identified before a design object can be viewed or edited.
Changed:
<
<

Scope Defaults 

>
>

Scope Defaults

 
Changed:
<
<		Each Suite must include default scope specifications indicating that all design objects are to be automatically included or excluded and which design modes are allowed for included objects.
>
>		Each Suite must include default scope specifications indicating that all design objects are to be automatically included or excluded and which design modes are allowed for included objects.
 
Changed:
<
<		Scope Defaults must be specified for each suite and are inherited by each application in the suite in the event that scope defaults are not specified for the application or the application's version.  The scope default fields provide a quick way to specify the equivalent of a scope record for the suite.
>
>		Scope Defaults must be specified for each suite and are inherited by each application in the suite in the event that scope defaults are not specified for the application or the application's version. The scope default fields provide a quick way to specify the equivalent of a scope record for the suite.
 
Changed:
<
<		Scope defined at the suite level cannot be overridden by project scope records.  In other words, a project manager cannot define a project that is outside of the scope defined for the suite.
>
>		Scope defined at the suite level cannot be overridden by project scope records. In other words, a project manager cannot define a project that is outside of the scope defined for the suite.
 
Changed:
<
<		The scope default values are not inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)
>
>		The scope default values are not inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)
 
Scope Type
Changed:
<
<		 
>
>
 
  • INCLUDE - All design objects are included within the scope of the suite.
  • EXCLUDE - All design objects are excluded from the scope of the suite.
Allow Add?
Line: 67 to 68
 If checked, this option will allow objects to be changed for applications within the suite.

Versions

Changed:
<
<		A Suite may have one or more Versions.  For example, a suite may have a Production version, a Development version, and a Test version.  Versions are identified by a two-character code. The same version code may be used in more than one suite.  However, the applications for a specific version may not be assigned to more than one suite.
>
>		A Suite may have one or more Versions. For example, a suite may have a Production version, a Development version, and a Test version. Versions are identified by a two-character code. The same version code may be used in more than one suite. However, the applications for a specific version may not be assigned to more than one suite.
 

Version Attributes

Applications

Changed:
<
<		Each Version of a Suite may have one or more Applications.  The same Application may exist in more than one Version. However, a specific application/version may only be assigned to a single suite.
>
>		Each Version of a Suite may have one or more Applications. The same Application may exist in more than one Version. However, a specific application/version may only be assigned to a single suite.
 

Application Attributes

Scope

Projects

Changed:
<
<		Projects can be defined for a Suite, a Suite/Version, or for a Suite/Version/Application.  Each project is identified by a 10-character Project ID.  Project ID's must be unique at each Suite/Version/Application level.  In other words, you can create more than one project with the same Project ID as long as the projects are defined for different Suites, Suites/Versions, and Suites/Versions/Applications.
>
>		Projects can be defined for a Suite, a Suite/Version, or for a Suite/Version/Application. Each project is identified by a 10-character Project ID. Project ID's must be unique at each Suite/Version/Application level. In other words, you can create more than one project with the same Project ID as long as the projects are defined for different Suites, Suites/Versions, and Suites/Versions/Applications.
 
Changed:
<
<		Depending on which level a project is define, there is an implied scope constraint.  For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version.
>
>		Depending on which level a project is define, there is an implied scope constraint. For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version.
 

Jobs

Tasks

Notes

Bugs:

  1. Suite Maint - Version count is not correct when two suites have been entered.
  2. Suite Maint - Scope count should display "None" when no scope records have been entered.
Changed:
<
<
  1. Suite Maint -  needs optional child to go directly to Versions.
  2. Version Maint - needs optional child to go directly to Applications.
>
>
  1. Suite Maint - needs optional child to go directly to Versions.
  2. Version Maint - needs optional child to go directly to Applications.
 
  1. Suite Maint - Labels are not being displayed correctly on the buttons on the continuation frame for suites.
Changed:
<
<
  1. Suite Maint - Scope Type, Allow Add?, Allow Del?, and Allow Chg? should all be required fields.
>
>
  1. Suite Maint - Scope Type, Allow Add?, Allow Del?, and Allow Chg? should all be required fields.
 
  1. Suite Maint - Field labels need to be more verbose, e.g. "Allow Add?" could be "Allow New Objects To Be Added?
  2. Notes Maint - Titlebar needs to identify the parent type that the note is attached to, e.g. "Source Code Control - Suites"
  3. Notes Maint - Heading area should identify the specific record that the note is attached to, e.g. "Suite: APPXBANG - APPXBANG Business Applications"
Changed:
<
<
  1. Notes Maint - When adding a note, if you press CANCEL, Notes Maintenance is canceled and you are returned to the calling program.  You should be returned to the list of notes.
  2. Notes Maint - Change is not allowed from the scrolling list of notes.  Change should be allowed. Add, delete, and inquire are all allowed.
  3. Projects/Jobs/Tasks Maint - Add mode is not allowed.  I can only add a project from within Application Suites maint.
>
>
  1. Notes Maint - When adding a note, if you press CANCEL, Notes Maintenance is canceled and you are returned to the calling program. You should be returned to the list of notes.
  2. Notes Maint - Change is not allowed from the scrolling list of notes. Change should be allowed. Add, delete, and inquire are all allowed.
  3. Projects/Jobs/Tasks Maint - Add mode is not allowed. I can only add a project from within Application Suites maint.
 
  1. Projects/Jobs/Tasks Maint - Object record does not show correct notes count.
Changed:
<
<
  1. projects/Jobs/Tasks maint - When viewing Full Log Detail, Object record has no owner.  What is the owner field used for?
>
>
  1. projects/Jobs/Tasks maint - When viewing Full Log Detail, Object record has no owner. What is the owner field used for?
 
  1. Fields are missing documentation - document all fields.
  2. Design - Source Code Control panel should not refer to "# for Xfer"
Changed:
<
<
  1. Design - Source Code Control panel refers to "# In Use".  Don't know what this means.
  2. Design - Source Code Control - Select Project.  Column headings are screwed up.
  3. Design - allowed me to select a task that had a status of pending. - Changed the status to Active automatically.  Seems like the status should be Assigned before it can be selected.
  4. Design - SCC - Select Project - Does not show all available projects.  Maybe because they all had the same Project ID?
  5. Design - I made a change to an input object and it did not prompt me for a comment describing the change when I exited from the object. 
>
>
  1. Design - Source Code Control panel refers to "# In Use". Don't know what this means.
  2. Design - Source Code Control - Select Project. Column headings are screwed up.
  3. Design - allowed me to select a task that had a status of pending. - Changed the status to Active automatically. Seems like the status should be Assigned before it can be selected.
  4. Design - SCC - Select Project - Does not show all available projects. Maybe because they all had the same Project ID?
  5. Design - I made a change to an input object and it did not prompt me for a comment describing the change when I exited from the object.
 
  1. Design - When looking at the scrolling list of input process, there is no indication of which ones have been changed.
  2. Design - If I hover over the title Project message, the tooltip that pops up has truncated info.
  3. Design - Object status screen - data fields are offset to the left and display on top of field labels.
Line: 111 to 112
 
  1. Design - Help pulldown list all items twice
  2. Design - SCC panel on menu still showed 0 in use after I had made a change to an input object.
  3. Design - SCC Log detail - shows changed=N for an input object after I made a change.
Changed:
<
<
  1. Design - Tried to add a comment to an  audit history record.  Would not save comment.
  2. Design - SCC panel on design menu has a label "Control Level".  System Admin uses "Design Access".  We need to be consistent.
>
>
  1. Design - Tried to add a comment to an audit history record. Would not save comment.
  2. Design - SCC panel on design menu has a label "Control Level". System Admin uses "Design Access". We need to be consistent.
 
  1. XFER - SCC let me select object that was not complete.
Changed:
<
<
  1. XFER - SCC Status values are IDENTIFIED, ACTIVE, and COMPLETED?  What is this field??
  2. XFER - SCC needs to allow xfer of Project, Job, or Tasks based on Dependence & Mgt Status.  Should individual objects be allowed to be excluded?
>
>
  1. XFER - SCC Status values are IDENTIFIED, ACTIVE, and COMPLETED? What is this field??
  2. XFER - SCC needs to allow xfer of Project, Job, or Tasks based on Dependence & Mgt Status. Should individual objects be allowed to be excluded?
 
  1. XFER - status column not lined up. (fixed spf)
  2. XFER - two counts in footer - What are they?
  3. XFER - Clear All and Select All buttons don't seem to work.
Line: 128 to 129
 

Enhancements:

  1. Scope Maint - Need to be able to scan on Object Name field.
  2. Scope Maint - Need to be able to see all higher level scope records.
Changed:
<
<
  1. Projects - need to be able to change the level that a project is attached to - Suite, Version, Application.  For example, if attached to suite, need to be able to move the project to a version or individual application.
>
>
  1. Projects - need to be able to change the level that a project is attached to - Suite, Version, Application. For example, if attached to suite, need to be able to move the project to a version or individual application.
  2. Projects - it would be nice if we could add a Project directly & specify which Suite/Ver/App it pertained to, instead of adding it in Suite/Versions/Applications first.
 
Deleted:
<
<		 
  -- SteveFrizzell - 29 Oct 2007
Deleted:
<
<
 
META FILEATTACHMENT attachment="SuiteMaint1.PNG" attr="" comment="Suite Maintenance" date="1208965624" name="SuiteMaint1.PNG" path="C:\Documents and Settings\steve\My Documents\APPX 4.3\SuiteMaint1.PNG" size="30737" stream="C:\Documents and Settings\steve\My Documents\APPX 4.3\SuiteMaint1.PNG" user="Main.SteveFrizzell" version="1"

Revision 122008-06-04 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"
Deleted:
<
<
 

APPX Source Code Control System

This page describes the Source Code Control System feature of APPX Application Design.

Line: 124 to 123
 
  1. SCC Inquiries - Menu says "Object History" - screen says "Object Inquiry".
  2. SCC Inquiries - Menu says "Objects Inquiry" - screen says "Audit Information - Search".
  3. Project Maint - need to enter field doc.
Added:
>
>
  1. SCC Note - Entered notes via Opt 96. Did not select a Project/job/task. Now those notes show on every object via Opt 96.
  2. SCC Note - There is a 'Process' pulldown menu that shows one item - 'SC- SCTRACK- CUR STATUS' throughout Application Design. Is this supposed to be there?
 

Enhancements:

  1. Scope Maint - Need to be able to scan on Object Name field.
  2. Scope Maint - Need to be able to see all higher level scope records.

Revision 112008-04-25 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

Line: 117 to 117
 
  1. XFER - SCC let me select object that was not complete.
  2. XFER - SCC Status values are IDENTIFIED, ACTIVE, and COMPLETED?  What is this field??
  3. XFER - SCC needs to allow xfer of Project, Job, or Tasks based on Dependence & Mgt Status.  Should individual objects be allowed to be excluded?
Changed:
<
<
  1. XFER - status column not lined up.
>
>
  1. XFER - status column not lined up. (fixed spf)
 
  1. XFER - two counts in footer - What are they?
  2. XFER - Clear All and Select All buttons don't seem to work.
  3. XFER - Selected For Xfer logic field should not allow null value

Revision 102008-04-25 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

Line: 25 to 25
   
Changed:
<
<		Notes can be attached at many different points within the structure of the source code control system.  Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, and Scopes.
>
>		Notes can be attached at many different points within the structure of the source code control system.  Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects.
 

Suites

The APPX Source Code Control system requires suites that are to be managed must first be defined.  The Suite Maintenance program can be used to enter and edit suites.

Line: 96 to 96
 
  1. Notes Maint - When adding a note, if you press CANCEL, Notes Maintenance is canceled and you are returned to the calling program.  You should be returned to the list of notes.
  2. Notes Maint - Change is not allowed from the scrolling list of notes.  Change should be allowed. Add, delete, and inquire are all allowed.
  3. Projects/Jobs/Tasks Maint - Add mode is not allowed.  I can only add a project from within Application Suites maint.
Added:
>
>
  1. Projects/Jobs/Tasks Maint - Object record does not show correct notes count.
  2. projects/Jobs/Tasks maint - When viewing Full Log Detail, Object record has no owner.  What is the owner field used for?
 
  1. Fields are missing documentation - document all fields.
  2. Design - Source Code Control panel should not refer to "# for Xfer"
  3. Design - Source Code Control panel refers to "# In Use".  Don't know what this means.
  4. Design - Source Code Control - Select Project.  Column headings are screwed up.
  5. Design - allowed me to select a task that had a status of pending. - Changed the status to Active automatically.  Seems like the status should be Assigned before it can be selected.
Changed:
<
<
  1. Design - SCC - Select Project - Does not show all available projects.
>
>
  1. Design - SCC - Select Project - Does not show all available projects.  Maybe because they all had the same Project ID?
 
  1. Design - I made a change to an input object and it did not prompt me for a comment describing the change when I exited from the object. 
  2. Design - When looking at the scrolling list of input process, there is no indication of which ones have been changed.
  3. Design - If I hover over the title Project message, the tooltip that pops up has truncated info.
Line: 110 to 112
 
  1. Design - Help pulldown list all items twice
  2. Design - SCC panel on menu still showed 0 in use after I had made a change to an input object.
  3. Design - SCC Log detail - shows changed=N for an input object after I made a change.
Added:
>
>
  1. Design - Tried to add a comment to an  audit history record.  Would not save comment.
  2. Design - SCC panel on design menu has a label "Control Level".  System Admin uses "Design Access".  We need to be consistent.
  3. XFER - SCC let me select object that was not complete.
  4. XFER - SCC Status values are IDENTIFIED, ACTIVE, and COMPLETED?  What is this field??
  5. XFER - SCC needs to allow xfer of Project, Job, or Tasks based on Dependence & Mgt Status.  Should individual objects be allowed to be excluded?
  6. XFER - status column not lined up.
  7. XFER - two counts in footer - What are they?
  8. XFER - Clear All and Select All buttons don't seem to work.
  9. XFER - Selected For Xfer logic field should not allow null value
  10. SCC Inquiries - Menu says "Object History" - screen says "Object Inquiry".
  11. SCC Inquiries - Menu says "Objects Inquiry" - screen says "Audit Information - Search".
  12. Project Maint - need to enter field doc.
 

Enhancements:

  1. Scope Maint - Need to be able to scan on Object Name field.
  2. Scope Maint - Need to be able to see all higher level scope records.

Revision 92008-04-24 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

Line: 97 to 97
 
  1. Notes Maint - Change is not allowed from the scrolling list of notes.  Change should be allowed. Add, delete, and inquire are all allowed.
  2. Projects/Jobs/Tasks Maint - Add mode is not allowed.  I can only add a project from within Application Suites maint.
  3. Fields are missing documentation - document all fields.
Added:
>
>
  1. Design - Source Code Control panel should not refer to "# for Xfer"
  2. Design - Source Code Control panel refers to "# In Use".  Don't know what this means.
  3. Design - Source Code Control - Select Project.  Column headings are screwed up.
  4. Design - allowed me to select a task that had a status of pending. - Changed the status to Active automatically.  Seems like the status should be Assigned before it can be selected.
  5. Design - SCC - Select Project - Does not show all available projects.
  6. Design - I made a change to an input object and it did not prompt me for a comment describing the change when I exited from the object. 
  7. Design - When looking at the scrolling list of input process, there is no indication of which ones have been changed.
  8. Design - If I hover over the title Project message, the tooltip that pops up has truncated info.
  9. Design - Object status screen - data fields are offset to the left and display on top of field labels.
  10. Design - Options pulldown list all items twice
  11. Design - Help pulldown list all items twice
  12. Design - SCC panel on menu still showed 0 in use after I had made a change to an input object.
  13. Design - SCC Log detail - shows changed=N for an input object after I made a change.
 

Enhancements:

  1. Scope Maint - Need to be able to scan on Object Name field.
  2. Scope Maint - Need to be able to see all higher level scope records.

Revision 82008-04-24 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

Line: 68 to 68
 If checked, this option will allow objects to be changed for applications within the suite.

Versions

Changed:
<
<		A Suite may have one or more Versions.  For example, a suite may have a Production version, a Development version, and a Test version.  Versions are identified by a two-character code.
>
>		A Suite may have one or more Versions.  For example, a suite may have a Production version, a Development version, and a Test version.  Versions are identified by a two-character code. The same version code may be used in more than one suite.  However, the applications for a specific version may not be assigned to more than one suite.
 

Version Attributes

Applications

Changed:
<
<		Each Version of a Suite may have one or more Applications.  The same Application may exist in more than one Version.
>
>		Each Version of a Suite may have one or more Applications.  The same Application may exist in more than one Version. However, a specific application/version may only be assigned to a single suite.
 

Application Attributes

Scope

Projects

Added:
>
>		 Projects can be defined for a Suite, a Suite/Version, or for a Suite/Version/Application.  Each project is identified by a 10-character Project ID.  Project ID's must be unique at each Suite/Version/Application level.  In other words, you can create more than one project with the same Project ID as long as the projects are defined for different Suites, Suites/Versions, and Suites/Versions/Applications.

Depending on which level a project is define, there is an implied scope constraint.  For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version.

 

Jobs

Tasks

Notes

Revision 72008-04-24 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

Line: 9 to 9
 

Concepts

Suites / Versions / Applications

Added:
>
>		 Within the source code control system, applications can be grouped by version and by suite.  For example, you might define a suite for the the APPXBANG Business Applications.  Within that suite, you might define three versions; a production version (00), a test version (01), and a development version (02).  Each version would include the 12 applications that make up the APPXBANG Business Application suite.  In this example, there would be 36 separate applications defined in the APPX Application file.  An application must be defined in the APPX Application file before it can be included in a source code control system suite and version.
 

Projects / Jobs / Tasks

Added:
>
>		 Within the source code control system, development tasks are created and managed and are grouped by job and by project.  Projects can be created for a Suite, a Suite/Version, or a Suite/Version/Application.
 

Scope

Scope is usually used to define the boundaries for a Project, Job, or Task.  In other words, you can use scope to define which design objects are allowed to be viewed, edited, deleted, etc. when a designer is working on a specific Task.  If you want to exercise precise control, scope will let you do that.  For example, you could define a Task to modify the CUSTOMER MAINTENANCE input process and you could specify that only that one specific design object (CUSTOMER MAINTENANCE) is allowed to be changed and that it is not allowed to be deleted. However, on the other extreme, if you, as a project manager, don't want to control access to specific design objects, then you can simply not define a scope for a Task.

Line: 18 to 22
  Scope can be defined for Projects, Jobs, and Tasks.  Scope can also be defined for Suites, Versions, and Applications.  If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite.  If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version.  The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.

Notes

Changed:
<
<
>
>		  

Notes can be attached at many different points within the structure of the source code control system.  Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, and Scopes.

 

Suites

The APPX Source Code Control system requires suites that are to be managed must first be defined.  The Suite Maintenance program can be used to enter and edit suites.

Line: 84 to 91
 
  1. Notes Maint - Heading area should identify the specific record that the note is attached to, e.g. "Suite: APPXBANG - APPXBANG Business Applications"
  2. Notes Maint - When adding a note, if you press CANCEL, Notes Maintenance is canceled and you are returned to the calling program.  You should be returned to the list of notes.
  3. Notes Maint - Change is not allowed from the scrolling list of notes.  Change should be allowed. Add, delete, and inquire are all allowed.
Added:
>
>
  1. Projects/Jobs/Tasks Maint - Add mode is not allowed.  I can only add a project from within Application Suites maint.
  2. Fields are missing documentation - document all fields.
 

Enhancements:

  1. Scope Maint - Need to be able to scan on Object Name field.
  2. Scope Maint - Need to be able to see all higher level scope records.
Added:
>
>
  1. Projects - need to be able to change the level that a project is attached to - Suite, Version, Application.  For example, if attached to suite, need to be able to move the project to a version or individual application.
   

Revision 62008-04-23 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

Line: 11 to 11
 

Suites / Versions / Applications

Projects / Jobs / Tasks

Scope

Added:
>
>		 Scope is usually used to define the boundaries for a Project, Job, or Task.  In other words, you can use scope to define which design objects are allowed to be viewed, edited, deleted, etc. when a designer is working on a specific Task.  If you want to exercise precise control, scope will let you do that.  For example, you could define a Task to modify the CUSTOMER MAINTENANCE input process and you could specify that only that one specific design object (CUSTOMER MAINTENANCE) is allowed to be changed and that it is not allowed to be deleted. However, on the other extreme, if you, as a project manager, don't want to control access to specific design objects, then you can simply not define a scope for a Task.

When defining the scope for a project, job, or task it is sometimes easier to specify the exceptions.  For example, you might define a scope to Exclude all design objects and then, by exception, you might define additional scope records identifying specific design objects to be included.  Or, you might take the opposite approach and define a scope to Include all design objects and then, by exception, you might define additional scope records identifying specific design objects to be excluded.

Scope can be defined for Projects, Jobs, and Tasks.  Scope can also be defined for Suites, Versions, and Applications.  If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite.  If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version.  The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.

 

Notes

Suites

Line: 40 to 46
  The scope default values are not inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)
Scope Type
Added:
>
>		  
 
  • INCLUDE - All design objects are included within the scope of the suite.
  • EXCLUDE - All design objects are excluded from the scope of the suite.
Allow Add?

Revision 52008-04-23 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

Line: 16 to 16
 

Suites

The APPX Source Code Control system requires suites that are to be managed must first be defined.  The Suite Maintenance program can be used to enter and edit suites.

Changed:
<
<

Attributes

>
>

Suite Attributes

 

Suite ID

Each Suite is uniquely identified by a 10-character Suite ID.

Line: 51 to 51
 
Allow Chg?

If checked, this option will allow objects to be changed for applications within the suite.

Changed:
<
<

Versions

>
>

Versions

  A Suite may have one or more Versions.  For example, a suite may have a Production version, a Development version, and a Test version.  Versions are identified by a two-character code.
Changed:
<
<

Applications

>
>

Version Attributes

Applications

  Each Version of a Suite may have one or more Applications.  The same Application may exist in more than one Version.
Added:
>
>

Application Attributes

 

Scope

Projects

Jobs

Line: 73 to 75
 
  1. Notes Maint - Titlebar needs to identify the parent type that the note is attached to, e.g. "Source Code Control - Suites"
  2. Notes Maint - Heading area should identify the specific record that the note is attached to, e.g. "Suite: APPXBANG - APPXBANG Business Applications"
  3. Notes Maint - When adding a note, if you press CANCEL, Notes Maintenance is canceled and you are returned to the calling program.  You should be returned to the list of notes.
Changed:
<
<
  1. Notes Maint - Change is not allowed from the scrolling list of notes.  Change should be allowed.
>
>
  1. Notes Maint - Change is not allowed from the scrolling list of notes.  Change should be allowed. Add, delete, and inquire are all allowed.
 

Enhancements:

  1. Scope Maint - Need to be able to scan on Object Name field.
  2. Scope Maint - Need to be able to see all higher level scope records.

Revision 42008-04-23 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

Line: 6 to 6
 This page describes the Source Code Control System feature of APPX Application Design.

Added:
>
>

Concepts

Suites / Versions / Applications

Projects / Jobs / Tasks

Scope

Notes

 

Suites

Changed:
<
<

Suite ID

>
>		 The APPX Source Code Control system requires suites that are to be managed must first be defined.  The Suite Maintenance program can be used to enter and edit suites.

Attributes

Suite ID

  Each Suite is uniquely identified by a 10-character Suite ID.
Changed:
<
<

Suite Description

>
>

Suite Description

  Each suite has a 30-character description.
Changed:
<
<

Design Access

>
>

Design Access

  Design access controls what level of access is allowed for the applications within a suite.  Design access must be specified for each suite and is inherited by each application in the suite in the event that design access is not specified for the application or the application's version.  The following design access levels are allowed:
  • NO ACCESS - Does not allow design objects to be viewed or edited.
  • VIEW ONLY - Allows design objects to be viewed but not edited.
  • NOT TRACKED - Allows design objects to be viewed and edited.
  • TRACKED - Requires that a Project/Job/Task be identified before a design object can be viewed or edited.
Changed:
<
<

Default Scope

>
>

Scope Defaults 

Each Suite must include default scope specifications indicating that all design objects are to be automatically included or excluded and which design modes are allowed for included objects.

Scope Defaults must be specified for each suite and are inherited by each application in the suite in the event that scope defaults are not specified for the application or the application's version.  The scope default fields provide a quick way to specify the equivalent of a scope record for the suite.

 
Changed:
<
<		Each Suite must include a default scope specification indicating that all processes are to be automatically included or excluded.
>
>		Scope defined at the suite level cannot be overridden by project scope records.  In other words, a project manager cannot define a project that is outside of the scope defined for the suite.
 
Changed:
<
<		Scope records defined at the suite level cannot be overridden by project scope records.  In other words, a project manager cannot define a project that is outside of the scope defined for the suite.
>
>		The scope default values are not inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)
Scope Type
  • INCLUDE - All design objects are included within the scope of the suite.
  • EXCLUDE - All design objects are excluded from the scope of the suite.
Allow Add?
 
Changed:
<
<		The scope default values in the suite record define the equivalent of a default scope record.  They are not values that are inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)

Versions

>
>		If checked, this option will allow new objects to be added to applications within the suite.
Allow Del?

If checked, this option will allow objects to be deleted from applications within the suite.

Allow Chg?

If checked, this option will allow objects to be changed for applications within the suite.

Versions

  A Suite may have one or more Versions.  For example, a suite may have a Production version, a Development version, and a Test version.  Versions are identified by a two-character code.
Changed:
<
<

Applications

>
>

Applications

  Each Version of a Suite may have one or more Applications.  The same Application may exist in more than one Version.
Added:
>
>

Scope

Projects

Jobs

Tasks

Notes

 

Bugs:

Changed:
<
<
  1. Suite Version count is not correct when two suites have been entered.
  2. Suite Scope count should display "None" when no scope records have been entered.
  3. Suite maintenance needs optional child to go to Versions.
  4. Version maintenance needs optional child to go to Applications.
>
>
  1. Suite Maint - Version count is not correct when two suites have been entered.
  2. Suite Maint - Scope count should display "None" when no scope records have been entered.
  3. Suite Maint -  needs optional child to go directly to Versions.
  4. Version Maint - needs optional child to go directly to Applications.
  5. Suite Maint - Labels are not being displayed correctly on the buttons on the continuation frame for suites.
  6. Suite Maint - Scope Type, Allow Add?, Allow Del?, and Allow Chg? should all be required fields.
  7. Suite Maint - Field labels need to be more verbose, e.g. "Allow Add?" could be "Allow New Objects To Be Added?
  8. Notes Maint - Titlebar needs to identify the parent type that the note is attached to, e.g. "Source Code Control - Suites"
  9. Notes Maint - Heading area should identify the specific record that the note is attached to, e.g. "Suite: APPXBANG - APPXBANG Business Applications"
  10. Notes Maint - When adding a note, if you press CANCEL, Notes Maintenance is canceled and you are returned to the calling program.  You should be returned to the list of notes.
  11. Notes Maint - Change is not allowed from the scrolling list of notes.  Change should be allowed.

Enhancements:

  1. Scope Maint - Need to be able to scan on Object Name field.
  2. Scope Maint - Need to be able to see all higher level scope records.
   

-- SteveFrizzell - 29 Oct 2007

Added:
>
>
META FILEATTACHMENT attachment="SuiteMaint1.PNG" attr="" comment="Suite Maintenance" date="1208965624" name="SuiteMaint1.PNG" path="C:\Documents and Settings\steve\My Documents\APPX 4.3\SuiteMaint1.PNG" size="30737" stream="C:\Documents and Settings\steve\My Documents\APPX 4.3\SuiteMaint1.PNG" user="Main.SteveFrizzell" version="1"

Revision 32008-04-23 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

Line: 6 to 6
 This page describes the Source Code Control System feature of APPX Application Design.

Changed:
<
<

Application Suites

>
>

Suites

Suite ID

Each Suite is uniquely identified by a 10-character Suite ID.

Suite Description

Each suite has a 30-character description.

Design Access

Design access controls what level of access is allowed for the applications within a suite.  Design access must be specified for each suite and is inherited by each application in the suite in the event that design access is not specified for the application or the application's version.  The following design access levels are allowed:

  • NO ACCESS - Does not allow design objects to be viewed or edited.
  • VIEW ONLY - Allows design objects to be viewed but not edited.
  • NOT TRACKED - Allows design objects to be viewed and edited.
  • TRACKED - Requires that a Project/Job/Task be identified before a design object can be viewed or edited.
 

Default Scope

Changed:
<
<		Each Application suite must include a default scope specification indicating that all processes are to be automatically included or excluded.
>
>		Each Suite must include a default scope specification indicating that all processes are to be automatically included or excluded.
  Scope records defined at the suite level cannot be overridden by project scope records.  In other words, a project manager cannot define a project that is outside of the scope defined for the suite.

The scope default values in the suite record define the equivalent of a default scope record.  They are not values that are inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)

Added:
>
>

Versions

 
Changed:
<
<		 
>
>		A Suite may have one or more Versions.  For example, a suite may have a Production version, a Development version, and a Test version.  Versions are identified by a two-character code.

Applications

Each Version of a Suite may have one or more Applications.  The same Application may exist in more than one Version.

Bugs:

  1. Suite Version count is not correct when two suites have been entered.
  2. Suite Scope count should display "None" when no scope records have been entered.
  3. Suite maintenance needs optional child to go to Versions.
  4. Version maintenance needs optional child to go to Applications.
   

Revision 22008-04-22 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

Line: 6 to 6
 This page describes the Source Code Control System feature of APPX Application Design.

Added:
>
>

Application Suites

Default Scope

Each Application suite must include a default scope specification indicating that all processes are to be automatically included or excluded.

Scope records defined at the suite level cannot be overridden by project scope records.  In other words, a project manager cannot define a project that is outside of the scope defined for the suite.

The scope default values in the suite record define the equivalent of a default scope record.  They are not values that are inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)

 

 

  -- SteveFrizzell - 29 Oct 2007

Revision 12007-10-29 - SteveFrizzell

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="APPXAdministrator"

APPX Source Code Control System

This page describes the Source Code Control System feature of APPX Application Design.

-- SteveFrizzell - 29 Oct 2007

View topic | History: r19 < r18 < r17 < r16 | More topic actions...
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback