Notes for 12/2/08

·        Summary of Issues

·        Clarification of points

o       Legacy Software:

§         Access?

·        Yes. To relevant ones.

§         Things that you would like to see transferred over

·        No. Take it as lessons learned.

§         Export to the legacy formats

·        New point of entry, just need to export to XML/SQL. Engineers can map the spokes

§         Able to translate from legacy? Yes, that would be ideal.

§         All new products created through our application. Phasing out legacy systems.

o       Questions asked and answered:

§         Can you give us a few examples of products from your current catalogs?

·        Any PAETEC services, equipment rental, backup, T1s. All inclusive (like Time Warner for businesses) hosting, anything we sell, toll free number, sold software.

§         Are we able access to your Oracle database? How can we do so?

·        No access to any live data.

·        We will get sample data for testing info.

·        No strict requirement for method of SQL output.

§         Could you give some examples of what a service, feature, attributes, etc. might be?

·        More services than hardware

·        Service and product are kind of synonyms. Service can mean dial tone, or an instance of a product. Service = Product. 

·        Service ordering digital cable

·        Feature non standard or HD channels

·        Attributes: which channels. Configuring blocked numbers

·        MRC Monthly recurring charge

·        NRC non-recurring charge

·        Usage pricing is like based on use, ( 2 cents per minute)

·        MRC and NRC apply to pricing and cost. 

§         When exporting data to an external format, should the entire catalog of products be exported? Is it necessary to support exporting groups of products or single products?

·        One at a time is the highest priority

§         When you say each entity should have its own ID are you saying that it’s unique in the product catalog and should/could be contained in multiple products?

·        Spoke systems work off unique id. Doesn’t mean it has to be central, but it needs to be assigned, not the same across systems.

o       Versioning

§         Versions of catalog, customers have different versions of the products at any given time. See differences; see changes like between 1.0 and 1.2.

§         Talk about this more detailed in future meetings. 

o       When we get license for blueprint it must be forwarded to non-RIT email, change to xml file when downloaded.

o       Everything is a strict hierarchy. Actual entities are unique, but a template would be good. There is not a good way to share features with services, etc. 

o       Synopses: we can put up a product charter, expectations from RIT and PAETEC. Basic outline and expectancies.

o       Blueprint:

§         They did get the license. They are monthly and will be resent licenses.

§         Call email support, but don’t want to spend a lot of time so filter trough the details.

§         Use cases, tie prototypes to them, cool features. Generate test cases off use cases.

·        Decisions

o       Other Two Metrics will be: lines of code, requirements met, use cases satisfied, or something along those lines. 

o       Come out to PAETEC next Tuesday at 4pm. Erika will send out an email with direction.

o       The user can interact as either a web-app or stand-alone. Design part of it without a decision. Flush out both options. People using have access to network. Stand-alone makes deployment much more complex. Many of PAETEC’s current tools are web-apps.

o       Set up Primary contact person.  To minimize the email.

·        Action Items (w/ person responsible and dues dates)

o       Research Telecom

o       Sign NDA

§         Assigned to Erika

§         Due 12/9

o       Blueprint License

§         Assigned to Nathan

§         Due ASAP (completed)

o       Project Synopses

§         Assigned to Phil

§         Due 12/5