Chapter 10 — Developing Phase: Clients
On This Page
.gif){kind=icon}
Introduction and Goals
Starting the Development Cycle
Updating Your Risk Assessments
Making Applications Ready to Communicate with SQL Server
Configuring the Client Application Environment
Testing the Solution
Closing the Development Phase
Introduction and Goals
The focus of this chapter is on connecting existing database client applications to the new Microsoft® SQL Server™ database so that a smooth transition for retargeting connectivity for clients based on Sybase client libraries occurs. The key issues for client applications are:
Functionality. The migrated application should provide at least the same features as the original version.
Connectivity. The migrated application must be capable communicating with the database server in a timely manner.
Performance. There must be no degradation in speed or throughput as a result of the migration.
Security. The transition from one platform to another must not expose the application to any security vulnerabilities resulting from the reorganization of the application architecture.
You will have established during the Planning Phase of your project which of the following approaches to take in migrating client applications:
Client applications continue on their current platform using a version of Sybase DB-Library that is compatible with SQL Server and retarget communications with SQL Server.
Client applications using a version of DB-Library or CT-Library incompatible with SQL Server remain on their current platform but use FreeTDS to communicate with SQL Server.
Client applications are migrated to the Microsoft® Windows® Services for UNIX (SFU) environment under Windows, and then they make use of FreeTDS or unixODBC to communicate with SQL Server.
Client applications are migrated to the Microsoft Windows platform and rewritten to make use of native SQL Server APIs.
There is only limited discussion of the last scenario in this chapter. The discussion of the remaining three scenarios is more detailed. However, some of the topics covered refer readers to other sources for additional information that is beyond the scope of this document.
No application migration would be successful without a clear understanding of the basic Sybase technologies that come into play during a Sybase database migration to the SQL Server platform. This chapter provides an overview of those basic technologies.
Starting the Development Cycle
Migrating clients and applications requires different kinds of effort in different settings. To identify issues that will characterize your particular client migration, you should have previously performed an analysis of existing applications to:
Identify Sybase client library issues or underlying problems that may require resolution for migration to proceed.
Recognize any client/server connectivity issues with SQL Server to determine whether your client application is a retarget or rewrite candidate.
Determine whether nonstandard client application techniques are portable.
Discover any third-party library issues.
Developing the Solution Components
Development work focuses on the following tasks that you should complete in sequence:
Reassess the risks to the client migration project.
Familiarize yourself with the SQL Server interfaces and connectivity methods that applications can use.
Configure the client application environment to use DB-Library, FreeTDS, or unixODBC as appropriate, according to the redirection method chosen.
Test the solution.
Updating Your Risk Assessments
Sybase database client migrations may require few or no modifications to operate correctly with SQL Server. Alternatively, you could have determined as part of your planning activities that some applications may not be suitable candidates for reuse at all, leaving you with no choice but to rewrite them entirely, often in an unfamiliar environment. As a result of the extensive assessment work done in Planning, you should have a much clearer picture of the risks that your project faces. You will need to update your risk assessment and reprioritize the risks so that you can manage them. The following list includes common risks that you may have to deal with when performing a client migration:
Current staff is not prepared to rewrite clients on a Microsoft Windows® or Microsoft .NET Framework platform.
FreeTDS or unixODBC might not meet the needs of your environment.
Performance of the client in an interoperation mode may not achieve the results that you want.
Baseline performance data is unavailable.
Source code may be missing or incomplete for many client applications.
Existing client code may be licensed or copyrighted in a way that precludes it from use.
Third-party libraries may not be available for the development platform.
Existing client design may have inherent security issues.
Existing source code may not compile on the Sybase development platform.
Making Applications Ready to Communicate with SQL Server
Before you begin development, you should have a good understanding of the information in this section. The following topics present important information that is applicable to database application migrations.
Database Connection Checklist
When redirecting or rehosting an application, you will need the following information from the database system administrator:
Server name — the name of the new database host server
IP address — the IP address of the new database host server
Port number — the communications port from which the new database expects to receive requests
Network protocol — TCP (Transmission Control Protocol)
Transact-SQL Migration Checklist
If you are redirecting an application to use SQL Server, you must make the following changes to your database and applications as part of the migration process. These items were described in Chapter 6, "Developing Phase: Database," and many relate to the database but are worth repeating here because of the effect they will have on applications using the database:
Change references to chained transaction mode to either unchained transactions or SQL Server 2000 implicit transactions. Change @@TRAINCHAIN references to @@OPTIONS. Change @@TRANSTATE references to @@ERROR handling logic.
Change transaction isolation levels from Sybase numeric-level identifiers to SQL Server 2000 string-based identifiers.
Delete (preferably) or change optimizer hints to use SQL Server 2000 format.
Change permanent temporary tables to global tables.
Change the error number range of user-defined messages and add severity levels.
Remove or change the following items where they occur in the Sybase database:
Sybase server roles
User-defined data cache references
Thresholds
Index hints
Set forceplan statements
Make the following required syntax changes:
Change DUMP and LOAD statements to BACKUP and RESTORE statements.
Change @@sqlstatus to @@fetch_status when processing cursors.
Change the default name of identity columns in a table to IDENTITYCOL.
Rename columns and tables that use reserved SQL Server 2000 keywords.
Modify or delete Database Consistency Checker (DBCC) statements.
Update any RAISERROR statements to use SQL Server syntax and change the range value specified by messages to values that are greater than 50,000.
Modify any code that has character (CHAR or VARCHAR) constants in double-quotes to use single-quotes.
Modify any code that makes use of CHAR_LEN to use LEN instead.
Modify and code that meks use of SUSER_NAME to use USER_SNAME instead.
Modify any code that make use of SYB_IDENTITY to use IDENTITYCOL instead.
Modify any code that makes use of SET statements to use the appropriate SQL Server equivalent.
Note See Appendices B through E for an exhaustive list of required syntax changes.
Optionally, you can make the following changes to the database and applications after migrating to SQL Server 2000:
Change scrollable server cursors.
Replace nested IF statements with the CASE statement.
Use remote procedure calls (RPCs) with result sets in INSERTS.
Use extended stored procedures for mail notification, paging, and scheduling.
Log user messages to the Windows application log or the SQL Server error log by using xp_logevent.
Make use of Microsoft Windows-integrated security and trusted connections.
Use SQL Server Agent to schedule automatic maintenance tasks, alerts, and replication.
Change the strings used by EXECUTE statements.
Make use of stored procedures to perform initialization tasks that can run automatically when SQL Server starts up.
Change the SELECT statement to use SQL-92-style joins (INNER JOIN, CROSS JOIN, LEFT OUTER JOIN, RIGHT OUTER JOIN, FULL OUTER JOIN).
Additional References and Recommended Client Migration Reading
For more information that will help you understand the technologies and processes that are involved in migrating UNIX applications, see the UNIX Application Migration Guide at https://msdn.microsoft.com/library/?url=/library/en-us/dnucmg/html/ucmglp.asp?frame=true. This document provides guidelines and best practices that are required to port existing UNIX applications to a Windows environment.
The recommended APIs for accessing a SQL Server database from client applications on the Microsoft Win32® platform are ADO.NET, ADO, and ODBC. For more information about the native Microsoft drivers, see https://www.microsoft.com/data.
For more information about the structures and mechanisms used by Sybase and SQL Server, see Appendix B, "Sybase and SQL Server Architectural Differences."
For more information about the syntactic differences between Sybase stored procedures and triggers and those used by SQL Server, see Appendix C, "Sybase Stored Procedure and Trigger Migration to Microsoft SQL Server."
For more information about the functional and syntactic differences between Sybase stored procedures and triggers and those used by SQL Server, see Appendix D, "Transact-SQL Behavioral Differences."
For more information about SQL Server, see the SQL Server product documentation at https://www.microsoft.com/sql/techinfo/productdoc/2000/default.asp.
For more information about Sybase, see the Sybase product manuals at https://www.sybase.com/support/manuals.
Configuring the Client Application Environment
The Planning phase will have determined which redirection method you will be using. The information in this section will help you implement your chosen strategy:
If applications are going to continue on their current platform using a version of Sybase DB-Library that is compatible with SQL Server and retarget communications with SQL Server, then you should read the section "Redirecting Sybase DB-Library Clients."
If applications using a version of DB-Library or CT-Library incompatible with SQL Server are going to remain on their current platform but use FreeTDS to communicate with SQL Server, then read the section "Configuring FreeTDS."
If applications are going to be migrated to the SFU environment under Windows, and then make use of FreeTDS or unixODBC to communicate with SQL Server, then read the sections "Configuring FreeTDS" or "Configuring unixODBC," as appropriate.
Redirecting Sybase DB-Library Applications
UNIX client applications written using DB-Library can be forced to use TDS 4.2 provided that they do not use any of the newer features of the Sybase server. Applications such as this tend to be earlier applications that do not access the functionality that is available in Sybase System 10 and later, so these applications are often well-suited to redirection to SQL Server instead of wholesale rewriting.
To redirect a Sybase DB-Library client application to use SQL Server, you must perform the following tasks:
Add a reference to the server running SQL Server 2000 to the Sybase interfaces file. This file implements a name service mapping logical server names to physical addresses. This step is described in more detail in the "Sybase Interfaces File" section of this chapter.
Force the Sybase DB-Library application to use TDS 4.2. You do this by adding a call from the dbsetversion function to the source code of the application. This function expects a parameter specifying which version of TDS to use. You are advised to use the Sybase constant DBVERSION_46.
For more information about how to use the dbsetversion function, see https://manuals.sybase.com/onlinebooks/group-cnarc/cng1110e/dblib/@Generic__BookView/39614.
The Sybase Interfaces File
A UNIX client identifies a Sybase database server by looking up its name in the Sybase interfaces file. This is a text file that contains information about the names of servers and their physical addresses and network protocols supported.
Note SQL Server supports clients that connect using a number of different network protocols. For more information, see Chapter 3, "Planning Phase: Database." The discussion in this section assumes that you are using TCP/IP sockets because this is the most commonly used network protocol in a Sybase/UNIX environment.
There are two common ways to make an entry into a Sybase interfaces file. In both cases, you must supply the database server name, the IP address, and the port number to which the database listens. The following sections outline the procedures to edit the interfaces file.
Editing the Interfaces File by Using the dsedit Utility
The dsedit utility provides a graphical user interface, which is designed to be executed from a graphical environment such as X-Windows under UNIX. For further information on using dsedit, see Chapter 5, "Setting up Communications Across the Network," in Configuration Guide Adaptive Server Enterprise for UNIX.
Note The following procedure assumes you are using UNIX. If you are using a different operating system or do not have X-Windows available, you might find it more convenient to follow the procedure described in the "Editing the Interfaces File Manually" section of this guide.
To add a SQL Server reference to the Sybase interfaces file:
Invoke the dsedit program. The method for doing this is operating system-dependent. For example, you can start dsedit from a UNIX shell prompt by using the following command:
$ dsedit
A screen appears that allows you to select which Sybase interfaces file to edit. By default, the interfaces file in the Sybase installation directory is selected.
Click OK to begin editing the interfaces file. A screen appears that lists the configured Sybase servers.
3. Click Add new server entry. A screen appears that allows you add new servers:
.gif)
Figure 10.1 Adding servers with dsedit
In the Server name box, type a name for the SQL Server.
Note This name is used to identify the server entry in the interfaces file when client applications connect to the server. It does not have to be the same as the name of the computer hosting the SQL Server.
Click Add new network transport. The dsedit – Network Transport Editor dialog box appears.
In the Transport type box, select Transmission Control Protocol (TCP), in the Host name box, type the name or the IP address of the computer hosting SQL Server, and in the Port number box, type the number of the port on which the computer running SQL Server listens.
Click OK to accept the changes. You will see an entry in the interfaces file for the server that you just added:
.gif)
Figure 10.2 Verifying the available servers
Click Close session to return to the initial dsedit screen, and then click Exit to quit dsedit.
.gif)
.gif)
Editing the Interfaces File Manually
Another option for adding a new server reference to the interfaces file is to do so manually. This procedure is useful if you are operating in an environment that does not provide a graphical user interface.
To edit the interfaces file manually:
Locate the interfaces file. The name and location of the interfaces file is operating system-dependent. On UNIX, the file is named interfaces and is found in the Sybase installation direction (the path to this directory is stored in the $SYBASE environment variable). On Windows, the file is named sql.ini and is located in the ini folder under the Sybase installation folder.
Open the interfaces file by using an appropriate text editor.
Scroll down to the end of the file and type the information that identifies the computer running SQL Server. The lines that you need to add specify a name that identifies the server entry and a query line that specifies the protocol and address of the server.
Note The dsedit utility also adds a master line to the interfaces file. The purpose of this line is to specify the address that the Sybase server should listen to for client requests. It is only meaningful for computers hosting Sybase database servers and is not used by clients, so it can be omitted.
The following example shows the UNIX version of the interfaces file with the entry for the DEV_SQL2000 server added. You should substitute the name of your
SQL Server and its IP address in place of the values shown.
Note The format of this file differs slightly between UNIX and Windows.
.gif)
Figure 10.3 UNIX version of the sql.ini file
If you are using Windows, the equivalent entry in the sql.ini file will look like this:
.gif)
Figure 10.4 Windows version of the sql.ini file
Save and close the file.
.gif)
.gif)
Testing SQL Server Database Connectivity
After you have added the server entry to the interfaces file, you are ready to test database connectivity. Unless you are using some intermediate software that translates client requests from one version of TDS to another, you should test the connection by executing a client application that communicates with the server using TDS 4.2.
One simple piece of software worth considering is the db_ver.pl Perl script that is installed as part of the Sybase Migration Toolkit (SMT). You can copy this file from the C:\SMT\Scripts folder on the computer running SMT to a UNIX client computer by using the ftp command. The db_ver.pl script requires that Sybperl is also installed on the client computer.
Note For more information about installing and configuring Sybperl, see Appendix A: "Development-Related Topics."
To test database connectivity to a computer running SQL Server:
Open the db_ver.pl Perl script using an appropriate text editor.
Locate the &dblogin function call and replace the parameters with your SQL Server user ID, password, and the name of the server entry in the interfaces file. The file should resemble the following:
#!/usr/local/bin/perl##require 'sybperl.pl'; use Sybase::DBlib;$x = &dblogin("sa", "p&ssw0rd", "DEV_SQL2000");&dbcmd($x, "SELECT \@\@version\n");&dbsqlexec($x); &dbresults($x);while(%dat = &dbnextrow($x, 1)) {foreach (keys(%dat)) {print "$_: $dat{$_}\n"; }}Save the file and close the editor.
Run the script from a shell prompt. For example, at a UNIX command line, type:
$ db_ver.pl
The db_ver.pl Perl script executes the SELECT @@VERSION SQL Server statement. The result set that is returned will provide information about the version of the computer that is running SQL Server. The following screen image shows the output generated by db_ver.pl executed on a UNIX client that is connected to SQL Server 2000 Developer Edition, Service Pack 3 running on Windows XP, Service Pack 1.
.gif)
Figure 10.5 Output generated by db_ver.pl
.gif)
Configuring FreeTDS
FreeTDS should be used in situations where Sybase DB-Library is not available or not appropriate. FreeTDS is useful in a number of scenarios:
It allows Sybase client applications running under UNIX to communicate with SQL Server, even if the version of TDS being used is not directly supported by SQL Server.
It provides an implementation of DB-Library and CT-Library that can be installed under SFU, providing a platform for Sybase client applications even if the Sybase client libraries and tools are not installed.
It supports all versions of TDS from TDS 4.2 onwards. Migrated Sybase DB-Library client applications can be modified to make use of SQL Server 2000 specific functionality and then switched to use TDS 8.0.
Although much of the core functionality is available, in Version 0.61.2 (the version current at the time of writing this guide), there are 67 unimplemented or partially implemented Microsoft DB-Library functions (out of 184), 119 unimplemented or partially implemented Sybase DB-Library functions (out of 234), and 57 unimplemented or partially implemented CT-Library functions (out of 90). If you decide to use FreeTDS, you should be prepared to either implement any missing functionality in the FreeTDS libraries that your application requires, or modify your application to avoid these features.
The file api_status.txt contains an up-to-date list of missing, partially implemented, and fully implemented library functions for FreeTDS. This file is located in the doc directory in the freetds source tree when you download FreeTDS. You can also find this information at https://www.freetds.org/api_status.txt.
In many cases, you will also find it necessary to edit the various C program header files supplied with FreeTDS, such as sybdb.h and cspublic.h, to add the definitions and common macros used by many Sybase applications — you can usually copy the appropriate definitions from the header files supplied in Sybase.
The procedures for installing and testing FreeTDS are described in Appendix J, "FreeTDS and unixODBC Installation."
Configuring unixODBC
The unixODBC library provides a connectivity solution for applications when FreeTDS is inappropriate or not feasible. The unixODBC library implements the ODBC API under UNIX and SFU. You will need to modify existing DB-Library and CT-Library applications to use it, but it at least allows you the option of running client applications in a UNIX or SFU environment. The procedures for installing and testing unixODBC are described in Appendix J, "FreeTDS and unixODBC Installation."
The unixODBC library also requires you to install an ODBC driver for SQL Server; the unixODBC Web site recommends using the Easysoft ODBC-ODBC Bridge Driver (see https://www.easysoft.com/products/oob/main.phtml). It is beyond the scope of this guide to describe how to install individual ODBC drivers.
Testing the Solution
Applications that are migrated to the Windows platform will need to be thoroughly tested to ensure that there is no loss of functionality. Redirected applications must be checked to ensure the reliability of the connectivity option being used, and to determine that there is no change in behavior from the original system. In all cases, testing should also be performed to guarantee the security and integrity of the new architecture, and that it performs in a manner that is acceptable to the users.
The Need for Testing
Testing is the process of intentionally finding errors. Testing enhances the integrity of a system by detecting deviations in design and errors in the system. Testing also adds value to the product by checking conformity with user requirements. You should perform formal testing of the application by using the test-plan that you generated during the Planning Phase.
Testing often comprises:
Lab testing to ensure that the system matches specified requirements.
Piloting to provide users with the opportunity to use the system before implementation and assist the development team in making sure the application meets user expectations.
Note It is possible that piloting can result in a change of requirements; user expectations are not always the same as the requirements originally specified. Although these issues should have been addressed at an earlier stage, often it is not until a system is piloted that user expectations can be fully understood. For this reason, it is worth taking an iterative approach to development and conduct a prepilot exercise.
Prepilot testing of a large and complex system is beneficial before performing a formal full-scale pilot. You can select a small group of technically-competent users to try out selected pilot components and gather feedback. General comments regarding functionality, performance, and security can be used as further input to fine-tune the migrated application before performing the pilot. Be prepared to provide extensive support to users who are performing the pilot by recording, analyzing, and correcting errors that are reported. The system should undergo thorough regression testing after each major update and before release.
Testing is necessarily a time-consuming and resource-intensive process. The Planning Phase should ensure that adequate time, materials, and funds are allocated, and the execution of the testing process must be carefully controlled.
For more information about the testing process, see the article "Testing Process" at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnentdevgen/html/testproc.asp.
Causes of Errors
Testing will inevitably expose a number of errors and issues. The most common causes of errors in an application that is redirected from a Sybase database to SQL Server include:
Connectivity problems between the client application and SQL Server caused by incompatibilities in the version of TDS being used, or by a misconfiguration of FreeTDS.
Connectivity problems between the client application and SQL Server caused by a badly configured installation of unixODBC and the ODBC driver.
Logic errors caused by the different behavior in Transact-SQL statements between SQL Server and Sybase. You can execute the sp_dbcmptlevel stored procedure in a SQL Server database to change the behavior of some SQL commands and functions to match that of Sybase.
Integrity errors caused by using a different isolation level in SQL Server than that used by the original Sybase database.
Syntax errors caused by the subtle differences in syntax between many Sybase and SQL Server Transact-SQL commands. Syntax errors can also arise from the differences in the lists of reserved words between Sybase and SQL Server — a valid Sybase variable name may be illegal in SQL Server.
Applications that have been rewritten to take advantage of the features in Windows will require additional testing because of the fact that developers will have produced new code. Although connectivity issues should be minimal in this scenario, the scope for programming and logic errors will increase. If the test results for the original Sybase application are available, they should be compared against the test results of the migrated application, which will help to pinpoint areas where the output of the two versions of the application differs.
The Testing Process
The testing process comprises a number of key tasks that are outlined in the following sections.
Developing the Test Plan
The test plan was created during the Planning Phase. To recap, the test plan should address the following areas:
Test strategy and scope
Phases or categories of testing (integration, stress, security)
Testing resources (software, hardware, people, facilities)
Testing schedules that detail the sequence of tasks that the test team will follow to accomplish the testing
Dependencies (technical documentation, facilities)
Creating Test Cases
The test cases were defined during the Planning Phase, although issues that arise during the Development Phase may require that new test cases be added.
Tracking Bugs
All members of the team should be able to record newly-discovered bugs. A bug tracking database and reporting tool is useful to help record and maintain information about the status of bugs. However, to maintain good control over the status of bugs, only the test lead, test staff, or project managers should be able to close bugs. Set a guideline for assigning severity to bugs at the start of the testing process.
Triage
In larger projects, it is a best practice to hold triage meetings on a regular basis to review reported bugs. For example, you might schedule triage meetings three times a week during the first test pass, and then daily as you approach the test completion deadline.
Reporting Results
After the test team completes a successful execution of the required test cases, the team prepares a test report that lists the remaining open bugs. The final test report is sometimes called the “Release to Production” report.
Ready to Deploy
After the project management team receives the Release to Production report, the teams involved in the migration project (development team, test team, program management, and so on) meet to discuss whether the system is ready to release to production.
Resources
Performing adequate testing requires that you plan for the availability of the necessary equipment, time, and personnel. These issues are discussed in the following subsections.
Testing Team
You must carefully select the members of the testing team. An inexperienced testing team may not be able to test the system thoroughly.
A tester should be familiar with the technology, the business, and the customer requirements. Testing SQL Server applications requires that the tester be proficient with the architecture of the database and its integration with Windows.
Best Practices
To implement a comprehensive and effective test system, you should consider incorporating the following best practices into your migration program and post-migration operation environment:
Prepare comprehensive test plan specifications and test cases for each level of testing. Supplement these with the test data and test logs. Test plans for system testing may involve operators because acceptance testing involves customers.
Design the test cases to test system restrictions, such as file and database size (that is, stress testing).
Develop the data to test specific cases. Copies of live files must not be used except for acceptance testing.
Do not use confidential data for testing without written authorization, especially in the case of acceptance testing.
Perform regression testing on each component of the system to ensure that no anomalies have crept into the system because of changes made by correcting errors.
Be sure to document and set up the test environment for each level in advance of testing. Test environments specify the preconditions that are required to perform the tests.
Specify the intended test coverage as part of the test plan. Test coverage is the degree to which specific test cases address all specified requirements for a specific system or component.
Test Implementation
Formal test cases should be scripted as much as possible to facilitate automation and reliable repetition. After the scripts have been generated, you should test the implementation. Testing using these scripts ensures consistency as you promote the database and application through the development, staging, and production environments.
Roles and Responsibilities
The following table lists the typical roles and responsibilities of a test team.
Table 10.1: Roles and Responsibilities of a Test Team
Role |
Responsibilities |
|---|---|
Test lead |
Defines test goals and creates test plan. Executes test cases and generate test report. |
Test engineer |
Sets up lab. |
Testing and Optimization Tools
Many tools are available to automate the testing process, and they should be used wherever possible. Automated test scripts can be executed as uninterrupted batches without the need for further human intervention. Analysis tools can examine the results and highlight errors reported during test runs. Reporting tools can also help to identify bottlenecks in performance and point out areas that might require further work to meet throughput requirements.
Component Testing
Client applications should undergo a variety of tests to ensure that they meet the user requirements both in terms of functionality and performance.
Unit Test Database Clients
Unit testing checks that each functional component of the client application performs its required task. Setup scripts should be available that populate the database with known values, and test analysis scripts should compare the resultant data in the database against expected values.
Integration Test Database Clients
Integration testing determines whether the various components that comprise the client application operate together without any unexpected side effects. After a single instance of the client application is known to function correctly, multiple instances can be started simultaneously to test the multiuser aspects of the system. Particular attention needs to be paid to items such as how contention for shared resources is handled, transaction integrity, and duration.
Database Testing
The data structures and code in the database will have already been tested as part of the database development. For more information, see Chapter 6, "Developing Phase: Database." It is possible that client application testing highlights weaknesses in the database or modifications that need to be made. In these situations, the database will need to undergo formal regression testing after the necessary updates have been applied.
Security Testing
Security testing is especially important in a migrated environment because the underlying authentication and authorization mechanisms have most likely changed significantly. (For example, the migrated system may now be using Windows-integrated security.)
At a minimum, you need to verify that only the users who have the appropriate authority are able to use certain security-sensitive features. Test scenarios should be defined for each user class to verify that they can perform security sensitive functions for which they are authorized, and that they are denied access to functions for which they are not authorized.
In some environments, it may be necessary to perform more extensive testing to verify that the network is secure from unauthorized users. The test manager must consider the level of hacking skill of the test staff and whether they would be able to create an adequate set of challenges to network security. Frequently, it is advisable to use outsourced specialists who can provide comprehensive security testing.
For more information about security testing, see "Security" at https://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001191.
Code Review
Applications that are rewritten for Windows should undergo a formal code review by a team of experienced developers who are familiar with the technologies involved. The code review process will identify potential weaknesses in the code that may not become apparent when performing automated testing. Code review also helps to ensure that coding standards are maintained, which is a vital consideration for ease of maintenance.
Interim Milestone: Internal Build Complete
The iterative nature of development and test of complex database applications lends itself to the use of interim milestones that help the team measure the progress of the migration process. Internal builds that focus on key functional aspects of the system (for example, core functionality and optional functionality) can be used to force synchronization of the development at important times. How many builds there should be and how often they occur will depend on the size and scope of the project.
Closing the Development Phase
At this point, you have built the solution according to the functional specification. From the application migration perspective, this means that Sybase applications have either been migrated to Windows or redirected to use SQL Server.
Key Milestone: Scope Complete
At the Scope Complete Milestone meeting, the project team, key stakeholders, and customer must agree that all solution elements have been built and its functionality is complete according to specifications. There will still be bugs, but the next phase, Stabilizing, will be dedicated to fixing them.
Download
Update Notifications
Sign up to learn about updates and new releases
Feedback