DDS Template
-
Upload
jerome-bayocboc -
Category
Documents
-
view
270 -
download
3
Transcript of DDS Template
-
8/22/2019 DDS Template
1/27
Detailed Design Specification
2006, 2010, 2012 Actian Corporation
Project NameClick here to enter name
Author Click here and enter name(s)
Last Saved Date June 4, 2012
Revision
Template Revision 2.0
162090111.doc
-
8/22/2019 DDS Template
2/27
Responsibility List
Note: The Responsibility List reflects those required to review and provide feedback
for the document. Signoff by those listed is required prior to the beginning of the
development phase.
Additional reviewers
162090111.doc
Page2 of 27
Assigned To Action Responsibility Signature
Owner Engineer/Architect
Peer Review Development Manager
Chris Rogers
Jonathan Rosen
Peer Review QA Manager
Test Review QA Engineer
Alex Hanshaw Peer Review Sustaining Engineering Manager
Sustainability Review Sustaining Engineering
Engineer
Pam Fowler Peer Review Level 1 Support Manager
Ahmed Ezzat Peer Review Chief Architect
Elaine Grieco
Lee Howard
Peer Review Technical Writer
Peer Review Services
Peer Review Services
-
8/22/2019 DDS Template
3/27
Note: The additional reviewers list reflects other people that should be copied on the
document and invited to review meetings, but feedback from them is not required for
the document to be approved. Managers of other engineering groups are copied for
comment on how it affects their product or product area. The manager for your own
engineering area is included in first table and can be removed from here.
SQL Language Review
162090111.doc
Page3 of 27
Assigned To Action Responsibility Signature
Karl Schendel Information DBMS
Teresa King Information Gateways
Teresa King Information Connectivity
Joe Kronk Information OpenROAD
Roger Whitcomb Information Tools
Emma McGrattan InformationUsability
-
8/22/2019 DDS Template
4/27
Note: The SQL language review table lists people that should be sent an initial draft
copy of this document if you answered yes to any questions in section 2.2. If you did
not answer yes to any of those questions you may delete this table.
162090111.doc
Page4 of 27
Assigned To Action Responsibility Signature
Ian Kirkham Language Review DBMS
Teresa King Language Review Gateways
Teresa King Language Review Connectivity
Joe Kronk Language Review OpenROAD
Alex Hanshaw Language Review Supportability and
Backward
Compatibility
-
8/22/2019 DDS Template
5/27
Change History:
Revision Date Last Revision By Description of Change
30-Nov-2007 Steve Ball Template: Fixed up instructions to be more Ingres
product range specific and added sections specific to
Ingres/OpenROAD
3-Dec-2007 Steve Ball Template: Add tech writing changes and examples
section
4-Dec-2007 Steve Ball Template: changes based on feedback
1-May-08 Christine Normile Template: changes based on working meeting Punta
Cana, DR, Development Summit 2008
22-May-08 Christine Normile Template: removed confidential markings
21-Aug-2008 Steve Ball Template: Add language review elements
4-Apr-2009 Steve Ball Template: Added section on catalog changes
13-Aug-2010 Chris Clark Template: Fixed typos, footer now includes file name.
24-May-2012 Chris Clark Template: Company name change, default reviewers
updated
4-Jun-2012 Chris Clark Template: Facility reviewers updated, updated,
DEFINITIONS, ACRONYMS AND ABBREVIATIONS
to change which text is bold. Uploaded to
http://community.actian.com/wiki/Image:DDS-
Template.doc
162090111.doc
Page5 of 27
http://community.actian.com/wiki/Image:DDS-Template.dochttp://community.actian.com/wiki/Image:DDS-Template.dochttp://community.actian.com/wiki/Image:DDS-Template.dochttp://community.actian.com/wiki/Image:DDS-Template.doc -
8/22/2019 DDS Template
6/27
TABLE OF CONTENTS
1 INTRODUCTION.........................................................................10
1.1 SCOPEANDSUMMARY.................................................................................10
1.2 DEFINITIONS, ACRONYMSAND ABBREVIATIONS................................................10
1.3 REFERENCES.............................................................................................10
1.4 NOTEWORTHY ISSUES.................................................................................10
2 ARCHITECTURE OVERVIEW.........................................................12
2.1 HIGHLEVELDESCRIPTION.............................................................................12
2.2 SQL LANGUAGECHANGES...........................................................................12
2.3 IMPLICATIONSFOR GCA..............................................................................13
2.4 CONNECTIONPARAMETERS...........................................................................13
2.5 LANGUAGE, UNICODEANDINTERNATIONALIZATION ISSUES .................................13
2.6 IMPLICATIONSFORINGRES/STAR....................................................................13
2.7 IMPLICATIONSFORDBATOOLS......................................................................14
2.8 NEWIMA/MIBOBJECTS.................................................................................14
2.9 NEWTRACEPOINTS.....................................................................................14
2.10 CATALOGALTERATIONS.............................................................................14
2.11 IMPLICATIONFOR GATEWAYS......................................................................14
2.12 IMPLICATIONSFORDATABASEDRIVERS..........................................................15
2.13 IMPLICATIONSFOROPENROAD.....................................................................15
2.14 DESIGN LIMITATIONSAND ASSUMPTIONS......................................................15
2.15 PLATFORM SPECIFIC ISSUES.......................................................................15
162090111.doc
Page6 of 27
-
8/22/2019 DDS Template
7/27
2.16 PRODUCTINTERACTION.............................................................................16
2.17 PATENT INFORMATION...............................................................................16
3 EXTERNAL SPECIFICATION.........................................................17
3.1 USERPERSPECTIVE.....................................................................................17
3.2 INSTALLATIONAND ADMINISTRATION PERSPECTIVE............................................17
3.3 MIGRATION ISSUES.....................................................................................17
3.4 SECURITY IMPACT.......................................................................................17
4 INTERNAL SPECIFICATION..........................................................19
4.1 ESTIMATEDTASKSAND EFFORT....................................................................19
4.2 PROGRAMMING..........................................................................................20
4.3 COMPATIBILITYLIBRARYINTERFACECHANGES...................................................20
4.4 INTERFACE ...............................................................................................20
4.5 BUILDIMPLICATIONS....................................................................................21
4.6 UI RESOURCE/PROPERTIES FILES..................................................................21
4.7 BITMAP RESOURCES...................................................................................21
4.8 ICON FILES...............................................................................................22
4.9 PICCOLOCHANGENUMBERS..........................................................................22
5 IMPACT AND DOCUMENTATION SUMMARY..................................23
5.1 PRODUCT/COMPONENT IMPACTS...................................................................23
5.2 DOCUMENTATION.......................................................................................23
6 QUALITY ISSUES........................................................................24
6.1 UNIT TESTING SUMMARY.............................................................................24
162090111.doc
Page7 of 27
-
8/22/2019 DDS Template
8/27
6.2 HANDOFFQAIMPACT....................................................................................24
6.3 TESTING RECOMMENDATIONS.......................................................................24
6.4 REGRESSION RISKASSESSMENT....................................................................24
7 PACKAGING AND INSTALLATION IMPACT.....................................26
8 SUPPORT IMPACT......................................................................27
8.1 EXAMPLESANDTESTS.................................................................................27
162090111.doc
Page8 of 27
-
8/22/2019 DDS Template
9/27
PREFACE
This document describes external functional specifications as well as design
specifications for one feature of a release project. There will be many Detailed
Design Specifications (DDS) for each project, one for each major feature
described in the Software Requirements Specification (SRS) or project wiki page.
The SRS or the wiki page is the master document for the entire project.
This is intended to be a living document. The product development cycle is a
dynamic process in which our understanding of the project and its criteria for
success are refined over time. It is therefore expected that the completed
Detailed Design Specification will undergo many revisions during the course of a
project as requirements; resources and constraints evolve. The engineer would
not be expected to complete all sections in the initial draft; some sections are
designed so that they can only be completed one the project is coded. *note that
you are expected to continue updating this document until the release
project is handed over to SE*
The Development Manager is responsible for the contents of this document.
Deliverables that must be completed prior to releasing this document are at least
one of:
Software Requirements Specification
Wiki page on the engineering web describing the components of the project
All template instructions can be identified by theirgray italic type. This information
may be removed after completing the necessary project information.
Ant information detailed in this document should not be repeated in the wiki page
for this feature unless there is a compelling reason to do otherwise one of the
copies of the information may become out-of-date. If you need to, refer to the
DDS on the wiki page.
162090111.doc
Page9 of 27
-
8/22/2019 DDS Template
10/27
1 INTRODUCTION
1.1 SCOPE AND SUMMARY
Explain what the feature is expected to do; notes on the drivers for this feature
(such as partner or customer requirements) should be placed in here.
Click here to begin typing
1.2 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
Provide the definitions of terms, acronyms and abbreviations required to
interpret this document. For consistency, use the format in the examples below:
Detailed Design Specification: (DDS) A representation of a software system or
component of a system created to facilitate analysis, planning, implementation
and decision-making. The DDS is used as the primary medium for
communicating software design information.
Click here to add additional definitions
1.3 REFERENCES
Provide a list of documents referenced elsewhere in this document and/or
other documents that were used during research or may help the reader
understand the feature.
Identify each document by title, report number (if applicable), date and
publishing organization.
If possible, specify the sources from which the references can be obtained
Click here to begin typing.
1.4 NOTEWORTHY ISSUES
Since the DDS is an evolving representation of the design (a "living document"),
this section is used to keep track of issues that arise during the project life cycle
and items that need special attention. If you add a FIX_ME or comment similar
162090111.doc
Page10 of 27
-
8/22/2019 DDS Template
11/27
to need to do something about blah here to the code, you should note theissue here.
Click here to begin typing
162090111.doc
Page11 of 27
-
8/22/2019 DDS Template
12/27
2 ARCHITECTURE OVERVIEW
2.1 HIGH LEVEL DESCRIPTION
Describe the overall architecture. Architectural design may be represented in
many forms, including text, graphical description, pseudo-code representation or
combination.
Click here to begin typing
2.2 SQL LANGUAGE CHANGESAre there any changes in this feature that alter the SQL language in any way?
Did you add syntax to the Ingres SQL language? Did you remove syntax from
the Ingres SQL language? Did you add any new data-types or functions to SQL?
Did you make any other changes that affect the SQL language?
NOTE: If you answered yes to any of the questions above you must send the
initial draft of the DDS for language review to the people designated in the SQL
Language Review table at the start of this document and fill out all of the
following sub-sections. If there are no language changes you may delete all
these sub-sections
Click here to begin typing
2.2.1Language changes to Ingres/Star
Will the language changes be implemented in Ingres/star? If not why not?
Click here to begin typing
2.2.2Language Changes to ABF
Will the language changes be implemented in ABF? If not why not?
Click here to begin typing
2.2.3Language Changes to Database Procedures
Will the language changes be implemented or be functional inside database
procedures? If not why not?
162090111.doc
Page12 of 27
-
8/22/2019 DDS Template
13/27
Click here to begin typing
2.2.4Language Changes to Embedded SQL pre-compilers
Will the language changes be implemented in the embedded SQL Pre-
compilers? If not why not?
Click here to begin typing
2.2.5Effects on dynamic SQL
Will the language changes work in dynamic SQL? If not why not?
Click here to begin typing
2.3 IMPLICATIONS FOR GCA
Is there anything about this feature (including language or data-type changes)
that will require a new GCA message type or have any other affect on GCA?
Click here to begin typing
2.4 CONNECTION PARAMETERS
Does this feature require, use, or add any new DBMS connection parameters?
Click here to begin typing
2.5 LANGUAGE, UNICODE AND INTERNATIONALIZATION ISSUES
Is there anything about this feature that causes it to have unique characteristics
or testing requirements when implemented for the international market and
support for international or multi-byte character sets including Unicode (UTF16 or
UTF8)?
Click here to begin typing
2.6 IMPLICATIONS FOR INGRES/STAR
Does this feature have any implication for Ingres/Star? If so what are they?
162090111.doc
Page13 of 27
-
8/22/2019 DDS Template
14/27
Click here to begin typing
2.7 IMPLICATIONS FOR DBA TOOLS
Does the feature have any implications for the DBA tools such as copydb,
auditdb, rollforwarddb, verifydb? Would a new verifydb option be useful?
Click here to begin typing
2.8 NEW IMA/MIB OBJECTS
Did you add any IMA objects as part of this feature? Are there any that would be
useful that perhaps you didnt add because of lack of time?
Click here to begin typing
2.9 NEW TRACE POINTS
Trace points should be avoided in favor of IMA objects. If you added any trace
points detail them here with an explanation of why it was not suitable for an IMA
object.
Click here to begin typing
2.10 CATALOG ALTERATIONS
Does the feature add or alter the Ingres catalogs, either DBMS catalogs, front-
end catalogs, or iidbdb catalogs? If so, fill in the details here and be sure to
update the document containing the catalog spec, which can be found here:
http://community.ingres.com/wiki/Ingres_Catalogs
Click here to begin typing
2.11 IMPLICATION FOR GATEWAYS
Does this feature have any implications for the Ingres gateways? Do any SQLlanguage changes need to be considered for implementation in gateway
products?
Click here to begin typing
162090111.doc
Page14 of 27
http://community.ingres.com/wiki/Ingres_Catalogshttp://community.ingres.com/wiki/Ingres_Catalogs -
8/22/2019 DDS Template
15/27
2.12 IMPLICATIONS FOR DATABASE DRIVERS
Does this feature have any implications for any of the database drivers such as
ODBC, JDBC, Python, PHP, Ruby, etc? Do any SQL language changes need to
be considered for implementation in these drivers?
Click here to begin typing
2.13 IMPLICATIONS FOR OPENROAD
Does this feature have any implications for OpenROAD? De sure to mention any
changes to ADF that are necessary to implement this feature, they often impact
OpenROAD. Do any SQL language changes need to be considered for
implementation in OpenROAD
Click here to begin typing
2.14 DESIGN LIMITATIONS AND ASSUMPTIONS
This section should list current limitations and assumptions made in the design.
Click here to begin typing
2.14.1 Dependencies
Does this feature depend on any external functionality (such as an XML parser,
or some other similar piece of code that does not belong to Ingres)? Does this
feature depend on another feature that will be, or has been coded in this release
of the product? Describe the dependency.
Click here to begin typing
2.15 PLATFORM SPECIFIC ISSUES
Is there anything about this feature that causes it to have unique characteristicsor testing requirements when implemented on a specific platform? Are there any
platform limitations to this feature, or is it intended to run only on one platform?
Will the feature need to re-coded for other platforms (e.g. CL additions or re-
architecture)
Click here to begin typing
162090111.doc
Page15 of 27
-
8/22/2019 DDS Template
16/27
2.16 PRODUCT INTERACTION
Does this feature cause any changes in the way that Ingres products interact
with each-other other than already detailed in the above sections? Are there
certain products that will/will no work with this feature (this is more relevant to
tools such as VDBA and new middle-ware servers)?
2.17 PATENT INFORMATION
If there is any technology being developed for this feature that could be
considered for a patent, note the information here.
Click here to begin typing
162090111.doc
Page16 of 27
-
8/22/2019 DDS Template
17/27
3 EXTERNAL SPECIFICATION
3.1 USER PERSPECTIVE
In this section, the focus is on the tasks that a user will perform with this feature.
Describe what the feature does and how it works form a user perspective.
Focus on how it is used to perform the function described in the high level
description.
Provide screen shots if appropriate
Click here to begin typing
3.2 INSTALLATION AND ADMINISTRATION PERSPECTIVE
Include any special installation and setup tasks, system parameters or other
preparations that are necessary prior to use. Describe the steps needed to
setup and get the component going and any ongoing administration that will
need to be performed if relevant. List all configuration parameters that apply to
this feature here.
Click here to begin typing
3.3 MIGRATION ISSUES
Describe any special steps required to migrate from existing versions
Ingres/OpenROAD to this version that arise because of this feature. Does this
feature have any new catalogs or other implications for upgradedb?
Is the component going to be backward compatible?
Can this version co-exist with an older version?
Click here to begin typing
3.4 SECURITY IMPACT
Does anything about the function need securing? Could it do any damage?
Could it cause the display of sensitive information?
Does the implementation methodology do anything that produces a potential
security exposure, such as run as root or Ingres (if this is an application)?
162090111.doc
Page17 of 27
-
8/22/2019 DDS Template
18/27
Click here to begin typing
162090111.doc
Page18 of 27
-
8/22/2019 DDS Template
19/27
4 INTERNAL SPECIFICATION
4.1 ESTIMATED TASKS AND EFFORT
Estimate the engineering effort to code and test the component ready for hand
over to QA and Technical Writing. If it is a large function, break it up into smaller
function points and estimate each one. For large projects, filling out the table
below and should help but is not required. Estimates should be effort to code
complete; that is engineering effort assuming 100% of an engineers time is
used, which will not normally be equal to elapsed time for the project. Estimates
should include time to:
Code the feature and all of the error checking required for the feature
(error checking may be up to 50% of the code in the DBMS)
Test your code and make corrections
Write and post an integration plan (or more than one for large projects)
Run HandoffQA for each proposed submission and check the results
As a guide, an experienced engineer who already knows the code will normally
write and sanity test about 100 lines of code per day; engineers with less
experience or those that are new to the code will write less. Factor about 20% ofthe time it took to code for final testing and fixes. Look at existing modules to
help make an estimate of the number of lines of code required. Tasks should
normally be submitted as they are sane and complete, so the formula might be
something like:
Time for task = (no_of_lines / 100) + 2 days for IP and HandoffQA
Total time = Sum (time for all tasks) + 20% for overall testing and fixes
Click here to begin typing
Task Effort
(person-
days)
Assigned to Done
(yes/no)
Tested
(yes/no)
Description of task
TOTAL Total days - - -
162090111.doc
Page19 of 27
-
8/22/2019 DDS Template
20/27
4.2 PROGRAMMING
List programs and modules written, changed or deleted. Initially this will be a
first pass estimate of what needs to be changed, it will likely change during the
course if the project. The version of this document at code complete will contain
the modules or programs that actually changed.
Click here to begin typing
4.2.1Module 1Provide a short description of what the module does and how it changed if it
was altered.
Click here to begin typing
4.3 COMPATIBILITY LIBRARY INTERFACE CHANGES
Describe any changes made to the compatibility library interface. Any changes
described here should be copied to CL platform reviewers for approval before
changes are made, and the CL spec should be updated to reflect the new
interface. Current platform reviewers are:
Darren Horler VMS
Viktoriya Driker - Windows
Bob Bonchik, Alex Hanshaw UNIX
Alex Hanshaw - Linux
Click here to begin typing
4.4 INTERFACE
How do other components that are external to the design interact with thiscomponent? Describe methods and rules of interaction.
Communication protocols; is GCA affected? Other?
Changes of facility call interfaces in the DBMS (e.g. is dmf_call changed?)
162090111.doc
Page20 of 27
-
8/22/2019 DDS Template
21/27
Changes to the interface of non static functions
New error codes or error conditions that will be logged or propagated up the
stack to other functions. Has the error handling for those functions been
updated?
Click here to begin typing
4.5 BUILD IMPLICATIONS
Does this feature require any special jam rules? Did it require any changes in
jam MANIFEST files? Any new build targets? Any other build alterations?
4.6 UI RESOURCE/PROPERTIES FILES
This section is largely relevant to GUI applications like OpenROAD and can be
removed for DBMS features.
Provide the names of the files required by the UI and Messages
File Name Byte Count Word Count Format Comments
4.7 BITMAP RESOURCES
This section is largely relevant to GUI applications like OpenROAD and can be
removed for DBMS features.
Provide the bitmap resources.
File Comments
162090111.doc
Page21 of 27
-
8/22/2019 DDS Template
22/27
4.8 ICON FILES
This section is largely relevant to GUI applications like OpenROAD and can be
removed for DBMS features.
Provide the icon files used.
File Comments
Release note
System
requirements
4.9 PICCOLO CHANGE NUMBERS
Provide piccolo change numbers for changes made for this feature. This will be
filled in after the fact and should include change numbers for propagations of the
same change to other branches if appropriate
Change Number Submitted to (code-
branch)
Submission date
main
162090111.doc
Page22 of 27
-
8/22/2019 DDS Template
23/27
5 IMPACT AND DOCUMENTATION SUMMARY
The estimates in this section are approximate and are intended to give other
groups such as Technical Writing, Services, Support and QA an idea of the
impact this change will have.
5.1 PRODUCT/COMPONENT IMPACTS
5.1.1Entities
List the tools, commands, reports and messages that are impacted by thedevelopment of the module/function. Use the table below to summarize these
changes; you can refer to other sections for details.
Entity New Modified Comments
Tool
Commands
Messages
Help Modules
5.2 DOCUMENTATION
List the existing end-user documentation that is affected by modules changes,
and how it is affected. Be as specific and thorough as possible.
MANUAL CHANGES NEEDED Estimated
# of Pages
Installation Guide
Database Administrator Guide
System Administrator Guide
Connectivity Guide
SQL Reference Guide
Command Reference Guide
Migration Guide
162090111.doc
Page23 of 27
-
8/22/2019 DDS Template
24/27
6 QUALITY ISSUES
Look at the component from the QA point of view. Suggest any special tests
that will stress the component. Think how to make the component NOT work
and what special tests should be performed on this component. This is a
guideline to the QA testing procedures.
6.1 UNIT TESTING SUMMARY
Testing individual functions or subroutines in isolation is called unit testing. Unit
testing in some cases requires the developer to use stubs and drivers. Describe
the unit testing you did in these sections. Attach all unit tests to the wiki page for
this feature so that they are available to QA.
6.1.1Unit Testing Description
List and unit testing planned or done.
Click here to begin typing
6.2 HANDOFFQA IMPACT
In this section you should document expected or observed diffs in HandofQAcaused by the feature as well as other things that impact HandoffQA; should any
new tests be added to HandoffQA for this feature to prevent regression?
6.3 TESTING RECOMMENDATIONS
Suggest other additional function tests that are necessary. Special test
requirements, for example: the security levels, hardware or software
configurations,code page and multiple code pages, multi-system issues. Note
anything that cannot be tested in a lab and which might require field tests. What
can go wrong? How are these situations dealt with?
Click here to begin typing
6.4 REGRESSION RISK ASSESSMENT
What would be the implications of failure in the component? Is the code
complex? What is the potential for destabilizing existing functions?
162090111.doc
Page24 of 27
-
8/22/2019 DDS Template
25/27
What other areas of the product/component interact with this module?
Click here to begin typing
6.4.1Backward Compatibility Issues
Is there anything that should be tested for backward compatibility? Does this
feature affect how a down-rev client connects the current version of the DBMS?
Did the GCA protocol level change? Is upgradedb required?
Click here to begin typing
162090111.doc
Page25 of 27
-
8/22/2019 DDS Template
26/27
7 PACKAGING AND INSTALLATION IMPACT
Indicate any special packaging or installation requirements. Detail what the
packaging and installation requirements, if any, will be. Detail any new files that
are required, remember they should be added to the manifest, you are
responsible for doing this as part of the project.
Click here to begin typing
162090111.doc
Page26 of 27
-
8/22/2019 DDS Template
27/27
8 SUPPORT IMPACT
Detail any diagnostics or trace facilities built in to the component including new
IMA objects, trace points, or other build time or run-time diagnostics. Note
anything that could be made into a good supportability tool. Note components
that are:
Difficult to diagnose (for example: no tracing facility, dependent on specific
timing)
Difficult to service
Include workarounds where appropriate.
Click here to begin typing
8.1 EXAMPLES AND TESTS
Detail any example or test code that you wrote during the development of the
feature that may be useful to help support, QA, or customers to understand the
feature or useful to QA for testing. Attach all example and test code or details to
the wiki page for this feature
162090111.doc
Page 27 of 27