New database Posts

Create documentation directly from legacy Paradox system. We have a suite of PDoxDos and PDoxWin analysis tools which create our data models, data dictionaries, file inventories, and searchable reference databases. This documentation is used to create the new database as well as to extract many data driven business rules. This step includes setting up the legacy system with data in our development environment so developers can exercise the legacy system anytime needed throughout both steps of our 2-step process.

Deliverable: Saved as PDFs on drive P as well as sent to the client in an email.

Step 1 of 2: Discovery

• PSDP Feasibility Phase: Setup legacy system for coders. Document legacy system using automated tools.
• PSDP Requirements Phase: Identify forms and reports to convert. Document terms, actors, and identify use cases. Identify enhancements (if any). Identify tables in use.
• PSDP Design Phase: Build new database. Initial screen design mockup. Document business rules and additional documentation of use cases.

Step 1 deliverables usually include a project plan for the Step 2 of 2 build-it phase which serves as the requirements, a new database, and a GUI mockup. Each form and report becomes a task in step 2 of our 2-step process along with other known tasks such as build data migration program, build MVC Shell Application, user subsystem, and admin forms for maintaining users, lookup tables, etc.

Step 1 of our 2 step approach is used to start a project with discovery. Step 2 is build. The goal of discovery is to document known requirements, some initial design, and a project plan. Step 1 of our 2 step includes at least the following tasks: Gather Requirements, Build GUI Mockup, and Create the Initial Database. The Requirements task becomes the project plan for step 2, Build.

Discovery can include additional tasks such as documenting an existing application, data cleanup, and even a task or two from the initial coding phase such as implementing our Prestwood ASP.Net MVC shell which includes some initial design, and member management.

If this ticket is not authorized, the printed version of the Project Plan is the Project Proposal for Discovery. Once authorized, the tasks of this project are completed. The requirements task is completed by creating a Step 2 of 2 project ticket which becomes the project plan and/or the proposal for Step 2, Build.

Feasibility Phase, which is part of Discovery, can include converting any existing documentation into our system, or we can just get started by kicking off a Requirements+Design project.

Time Estimate: Although it depends on many factors, feasibility usually ranges from 0 to 16 hours, but each client varies. Our recommendation is that we kick-off a Requirements+Design project ASAP.

Goals:

1. Define any initial feasibility tasks the client wants done plus propose any that come to mind.
2. If appropriate to do a longer Feasibility Phase, then initiate a Feasibility Phase project.
3. If client is ready to proceed, define 2-Step approach, initiate Step 1: Requirements+Design (What+Why) with minimum tasks of Requirements Document, Initial Database, and GUI Mockup.

Note: For the best chance of a successful project, limit version 1.0 to as few features as reasonable.

Usually includes screenshots with text, access to physical database for reference, or we document existing database. Other documentation might include creating videos of old app focusing on walking through of various use cases.

1. Create app record in Enterprise Modeling, complete 100%.
2. Create Old Requirements Document project. Usually best to stick with one task/artifact per screen. Skip General Requirements because that applies to new projects.
3. Add App Specific Actors.
4. Add App Specific Definitions.
5. [Optional] Document old app General Design.

Feasibility Phase, which is part of Discovery, can include documenting existing system, establishing scope of new application (meaning document what is in old app that is not needed, plus minimal needed additional features).

Time Estimate: Although it depends on the complexity of the old application, feasibility usually ranges from 16 to 40 hours, but for larger complex applications, they can be several hundred hours.

Goals:

1. Define new project as a Strict Technical Conversion with few additions, or define as a Technical Conversion with Additions.
2. If appropriate to do a longer Feasibility Phase, then initiate a Feasibility Phase project.
3. If client is ready to proceed, define 2-Step approach, initiate Step 1: Requirements (What) with minimum deliverables of Requirements Document, Initial Database, and GUI Mockup.

Note: For the best chance of a successful project, limit changes to as few as reasonable.