Project restructuring is the rearranging of integration
or system testing project members by converting directories into projects,
adding projects to, or removing projects from the hierarchy.
Many reasons exist for why sites decide to restructure
projects; the following are a few:
- The direction of your product has changed and you must
remove subprojects from the hierarchy.
- A project has grown too large, and you want to
split it into smaller parts.
- Your team added lots of new functionality to your
product, and you must add subprojects to the hierarchy.
- A different team now is responsible for part of
the software, and you want to move it into a separate project.
- Your team decided to wait and include a disruptive
change to your product in the next release. Now you must unuse a subproject
from the hierarchy.
- You want to add an external project.
- You want to add an installation project.
When you restructure a project, change the make files,
the build process, and all automated jobs to reflect the changes you
have made.
Apply the changes to both the integration
testing project hierarchy and the system testing project hierarchy. Update
the integration testing project hierarchy first. Apply the change
to your system testing project hierarchy by checking out any new projects,
then updating to bring in the changes.
Additionally,
when you restructure a project, perform an update and then rebuild
the project hierarchy to ensure the integrity of your application.
For the integration testing project, your usual short test suite suffices.
For the system testing project, the SQE team might retest your application.
Note: When
you restructure projects, update the integration testing projects
and perform an integration test cycle first to find and fix any problems.
Your changes are selected into your system test projects automatically
during the system test cycle.