# HG changeset patch # User František Kučera # Date 1376220144 -7200 # Node ID c18b33cc832968a0940cd426de6f89f86f6dc7b5 # Parent 1c0eb6a70c2a6ae4ce8bde5c73703ebedb349e09 data: hot billing, SMTP, CR, DT, TT, URS, SRS, indentation diff -r 1c0eb6a70c2a -r c18b33cc8329 data/dictionary.xml --- a/data/dictionary.xml Sun Aug 11 13:16:50 2013 +0200 +++ b/data/dictionary.xml Sun Aug 11 13:22:24 2013 +0200 @@ -44,10 +44,13 @@ for pre-paid subscribers the standard way to charge services is online - – subscriber's balance is checked and if sufficient, the service (e.g. sending a SMS) is provided, otherwise the service is denied; - if the billing system is not currently available (so we can't say if the subscriber's balance is high enough), we can provide the service and try to charge it later + – subscriber's balance is checked in the billing system and if sufficient, the service (e.g. sending a SMS) is provided, otherwise the service is denied; + if the billing system is not currently available (so we can't say if the subscriber's balance is high enough), we can provide the service anyway and try to charge it later; + this feature requires saving state (transactions which weren't charged yet) in some persitent storage (CDR files, SQL database etc.) + and can be done at the billing gateway or directly at system like SMSC + charging @@ -80,7 +83,12 @@ - specific kind of MOAT short message which is used to donate money to charity or some organization; the donation is charged from sender's pre-paid balance or in his monthly bill alongside the fees for placed calls and sent SMS + + + specific kind of MOAT short message which is used to donate money to charity or some organization; + the donation is charged from sender's pre-paid balance or in his monthly bill alongside the fees for placed calls and sent SMS + + messaging @@ -149,6 +157,7 @@ a text-based client-server protocol for sending e-mail messages + uses TCP and standard port is 25 (STARTTLS or unencrypted) or 465 (SSL/TLS) or 587 (STARTTLS or unencrypted for Message Submission – RFC 6409) computer @@ -1496,28 +1505,68 @@ computer - - + + + + a request for changing a software – new features or modification of existing ones; + when one or more CRs are developed, they are delivered as new version of software product; + CR is requested by the customer (mobile network operator) and is delivered by the development team; + CR consists of one or more DT which are assigned to particular developers + + computer - - + + + + a task assigned to a software developer; + one or more DTs together usually forms a CR; + it is also possible to have an internal DT which is not linked to any CR (e.g. some refactoring or fixes or maintenence which was not requested by the customer); + each commit in the versioning system should be linked to a DT + + + computer + + + + + + a request for fixing something in the production; + requires some investigation and then can be solved by changing the configuration on site or by fixing the software (development) + + computer - + + + requirements on a software product or its particular change; + is written from the system's point of view + + computer - + + + requirements on a software product or its particular change; + is written from the user's point of view + + computer - A build of a software product which was not done according to regular procedure and processes. Might be used only for testing on site or during development – not in production. Such software is often delivered as a tar.gz or JAR, WAR etc. file to be patched into existing installation, not as regular package (RPM, DEB etc.) as production version. + + + a build of a software product which was not done according to regular procedure and processes; + might be used only for testing on site or during development – not in production; + such software is often delivered as a tar.gz or JAR, WAR etc. file to be patched into existing installation, not as regular package (RPM, DEB etc.) as production version + + computer