Friday, 20 December 2013
Documentation
When your system is fully installed, documents have to be issued.
We have the technical documentation & user documentation. You can think of them as manuals. Detailed information about a system's design specifications, its internal working & its functionality are found in documentation.
* User Documentation: It is provided to users to help them operate the newly implemented system. It can also take the form of a tutorial.
* Technical Documentation: It is provided specifically for the systems analyst & the programmer to help them in further upgrading & improvements
1st: The user documentation is issued to familiarize the system & its various components to the user who have no idea on how to operate it. It also saves the analyst's time, as if the documentation is effective, he/she won't be contacted on a regular basis. The user documentation includes:-
- Screenshots as well as descriptions regarding the operation of the system.
- Purpose of the system
- Input & output formats and what to do when errors arise.
- Hardware & software needed
- Troubleshooting guides and a list of FAQs
The technical documentation is also split into two parts:-
* System Documentation: It provides a detailed overview of the whole system. It includes:-
- Test plans & test results
- Results of system analysis (including elements such as DFDs)
- What is expected from the system
- Overall design decisions such as the choice of hardware and/or software.
* Program Documentation: It is produced for the pieces of program code that have been written. It includes:-
- A description and the purpose of the software.
- The input & output data formats that have been used.
- Program flowcharts that were produced.
- The program listing
--- This will help any future programmer to make modifications to the system ---
- A description and the purpose of the software.
- The input & output data formats that have been used.
- Program flowcharts that were produced.
- The program listing
--- This will help any future programmer to make modifications to the system ---
Saturday, 30 November 2013
Friday, 22 November 2013
ISBN Calculations (Check Digit)
During the design stage, the designer has to limit the chances of inaccurate data. Therefore, validation checks have to be established. These checks include:-
1) Range Check: Checks whether data is within acceptable boundaries.
2 ) Length Check: Checks if the data is entered with the required number of characters
3) Character Check: Checks that the data entered doesn't include invalid characters
4) Picture Check: Checks that data is entered in a specific format.
5) Limit Check: Similar to "Range Check", only it has one boundary.
6) Presence Check: Checks that data is actually present.
7) Consistency Check: Checks that data field tie up with each other
8) Check Digit: Performs complex calculations on a range of numbers, then compares them with the check digit. (We'll go into this more deeply with the ISBN calculations)
- Take the first 12 digits of the 13-digit ISBN
- Multiply each number in turn, from left to right by a number. The first digit is multiplied by 1, the second by 3, the third by 1 gain, the fourth by 3 again, and so on to the eleventh which is multiplied by 1 and the twelfth by 3.
- Add all of the 12 answers.
- Do a modulo 10 division on the result from step 2. (Don't know what a modulo 10 division is? It's easy. It's just the remainder from a whole number division by 10. I bet you learned to do that in junior school, before you even learned about decimal fractions.)
- Take that remainder result from step 4.If it's a zero, then the check digit is zero. If the remainders isn't zero then subtract the remainder from 10. The answer to that is your check digit.
Let's take #9781861972712# as an example:-
9 x 1 = 9 7 x 3 = 21 8 x 1 = 8 1 x 3 = 3 8 x 1 = 8 6 x 3 = 18 1 x 1 = 1 9 x 3 = 27 7 x 1 = 7 2 x 3 = 6 7 x 1 = 7 1 x 3 = 3
Add the results
9 + 21 + 8 + 3 + 8 + 18 + 1 + 27 + 7 + 6 + 7 + 3 = 118
Modulo 10 the result
118 modulo 10 = 110 remainder 8
Work out the digit
8 doesn't equal zero, so check digit = 10 - 8 = 2
Evaluation
There, the system has been fully installed and it's up & running. The users of the system are to evaluate the system. During this stage, two key questions will be asked:-
Q1) Does the finished solution meet its requirements?
Q2) Does it solve the problem?
What's the point of a solution which doesn't solve its corresponding problem? Nothin' right? So when these key questions are answered positively, then the system has succeeded. If otherwise, then it was a waste of time & resources.
Further to those two questions, the evaluation considers:-
* Lessons learnt from the problems encountered, so the next project will be even smoother & successful.
* Any maintenance and support needed in day-to-day running of the system
By now, the analyst will have determined the success of the new system, that is by getting feedback from the users. He will also have seen if the users are satisfied. He will have recorded the extensions suggested to the system based on the users' opinions. This gives him a clear idea about the limitation of the system.
Once these limitations have been identified, the analyst now has to interview the users and collect their opinions, suggestions regarding the limitations and further extensions. They will have to decide whether the good features of the system can compensate for these extensions. If not, then the analyst will have to analyze the new system and see where the extensions should be included. The system life cycle goes on...
Implentation
At this point, the system is designed, tested and is ready to be implement it. The thing is, how to do so? Knowing that there are four ways in which you can implement the system. So, which one is the best choice? Like with the methods of recording info back in the analysis stage, there is no black & white rather than it's all shades of grey.
1) Parallel Running: Both the old & the new system will work simultaneously and then the new system gradually dominates.
* Pros: Workers can be trained to use the new system while it is being implemented. If there are any problems with the new system and it has to halt, the old system will still be there as a backup.
* Cons: Two sets of workers have to be paid to keep both systems running. It takes a lot of time to be fully implemented. Actually, it is the slowest method of implementation.
2) Phased Implementation: Implementing the system one part at a time. This is like buying a fixed asset with monthly payments (Hire Purchase).
* Pros: If one aspect of the system fails, the other aspects will remain unaffected. Workers will have time to get used to the new system.
* Cons: It is a slower method when compared to direct changeover. If the new system fails, there's no hope to revert to its predecessor.
3) Direct Changeover: From the name itself, the old system is replaced instantly with the new system.
* Pros: Only one set of workers have to be paid, so it doesn't cost as much as in parallel running where two sets have to be paid. It's the quickest way to fully implement a new system.
* Cons: No backup is there. So if the new system fails, you're done for. It can be difficult to make improvements to the new system and keep it working.
4) Pilot Running: The system is implemented in one branch of the organization whilst the other branches carry out with their existing one.
* Pros: If the system doesn't work properly, the other branches won't be affected. The later branches benefit from the mistakes made in earlier branches.
* Cons: It is a slow method of implementation.
Development & Testing
The data structures are now designed and now we can move on to the next stage. Let's start with "development". After the data structures have been designed, it's time to create them using the software or programming language recommended by the analyst.
Now that the system is created, what if things don't work out. What if the created system failed to meet it's goals. One thing for sure, it won't look good in the programmer's resumé. This is why the system has to be tested thoroughly before being implemented. So, how to test it?
First of all, a test plan has to be produced by the analyst. This plan will contain the test data and the expected ones to be produced by the system. The analyst will then note the 'actual' data. Those data or the ones 'actually' produced by the system. The analyst will also make comments on the data produced and how they differ from the expected results.
Going deep into test data, it is of three types:-
1) Normal Data: The data valid & acceptable by the system.
2) Abnormal Data: The data invalid & rejected by the system.
3) Extreme Data: Note that this type of test data is only found where a range of data is input. Extreme data is the either the maximum or minimum data.
Don't go anywhere, just not yet. There is another way of testing a system and that is by using the live data. This is the data that has been used in the existing system, It will be used because the outputs are already known.
Subscribe to:
Posts (Atom)






.png)
.jpg)









