Kindly discuss about following Assignment No 5 of CS-504 in comments...:) best of luck!!!
Objective
The objective of this assignment is:
- To assess your overall understanding of Software Engineering concepts
- To check your level of understanding for Test Cases
- How we create test cases for testing the certain functionality of the system
Note:
The assignment should be in .doc format. Assignment in any format other than MS Word format will not be accepted.
Reference
1) Healthcare Sales Management System given as Case study in assignment no. 1
2) Annex-1 (Annex-1.doc) attached with this assignment *
Summary:
In this module we will practice the test cases to test certain parts of the system. Please read the Annex-1 given with this assignment as helping guide. You will have to develop two test cases.
First one will test the module “Medicine Receive Module” of HealthCare Sales Management System against the functional requirement of “Enter Received Item”
Second one will test the module “User Accounts Module” of HealthCare Sales Management System against the functional requirement of “Edit User Account”.
Questions [Marks 10+10]:
1) Develop a test case to test the functional requirement “Enter Received Item”.
In order to add an item in the inventory, the user must have Inventory Management rights. To enter the received items in the inventory, the details of the item including the supplier name, quantity, and item receive date and expiry date of the item is entered into a form. The system then saves the item into database and gives the message for success entry of item.
2) Develop a test case to test the functional requirement “Edit User Account”.
In order to edit an account, the account should already exist in the system. Note that only the person having the account management privileges can edit the account. To edit an account, user selects an account to edit and gets a form containing already entered information for the account. The user may change some or all of the information for account. The system then saves the account information and gives the message for successful account edit.
Plaaa help
ReplyDeleteIn the interests of creating employment opportunities in the programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will guarantee yourself a lifetime of employment, since no one but you can hope to maintain the code.
ReplyDeleteLie in the comments. You don't have to actively lie, just fail to keep comments up to date with the code.
Pepper the code with comments like /* add 1 to i */; however, never document woolly stuff like the overall purpose of the package or method.
Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should, as a side effect, convert x to binary and store the result in a database.
Use acronyms to keep the code terse. Real men never define acronyms; they understand them genetically.
In the interests of efficiency, avoid encapsulation. Callers of a method need all of the external clues they can get to remind them of how the method works inside.
If, for example, you were writing an airline reservation system, make sure that there are at least 25 places in the code that need to be modified if you add another airline. Never document where they are. People who come after you have no business modifying your code without thoroughly understanding every line of it.
In the name of efficiency, use cut/paste/clone. This works much faster than using many small reusable modules.
Never, never put a comment on a variable. Facts about how the variable is used, its bounds, its legal values, its implied/displayed number of decimal points, its units of measure, its display format, its data entry rules (e.g., total fill, must enter), when its value can be trusted etc. should be gleaned from the code. If your boss forces you to write comments, lard method bodies with them, but never comment a variable, not even a temporary!
Try to pack as much as possible into a single line. This saves the overhead of temporary variables and makes source files shorter by eliminating new line characters and white space. Tip: Remove all white space around operators. Good programmers can often hit the 255-character line length limit imposed by some editors. The bonus of long lines is that programmers who cannot read 6 point type must scroll to view them.
Cd wrttn wtht vwls s mch trsr. When using abbreviations inside variable or method names, break the boredom with several variants for the same word and even spell it out longhand once in a while. This helps defeat those lazy bums who use text search to understand only some aspect of your program. Consider variant spellings as a variant on the ploy; e.g., mixing international colour, with American color and dude-speak kulerz.
Never use an automated source code tidier to keep your code aligned. Lobby to have them banned from your company on the grounds that they create false deltas in PVCS (version control tracking). You are now free to accidentally misalign the code to give the optical illusion bodies of loops and ifs are longer or shorter than they really are.
Rigidly follow the guidelines about no goto, no early returns and no labeled breaks especially when you can increase the if/else nesting depth by at least five levels.
Use very long variable names that differ from each other by only one character, or only in upper/lower case. Wherever scope rules permit, reuse existing unrelated variable names. An ideal variable name pair is swimmer and swimner. Exploit the failure of most fonts to clearly discriminate between ilI1| or oO08 with identifier pairs like parselnt and parseInt or D0Calc and DOCalc.
Read more: CS504 Assignment No 5 Solution & Discussion Due Date: 23-01-2012 - Virtual University of Pakistan http://vustudents.ning.com/group/cs504softwareengineeringi/forum/topics/cs504-assignment-4?commentId=3783342%3AComment%3A1078747&groupId=3783342%3AGroup%3A59359#ixzz1zBBbR0vl
Please read the question care fully that is "Guidelines to avoid un-maintainable code"
ReplyDeleteMean to say how we can make an attractive code....that a human can understand I believe that this is in lecture # 29 or 28......
Read more: CS504 Assignment No 5 Solution & Discussion Due Date: 23-01-2012 - Virtual University of Pakistan http://vustudents.ning.com/group/cs504softwareengineeringi/forum/topics/cs504-assignment-4?commentId=3783342%3AComment%3A1078747&groupId=3783342%3AGroup%3A59359#ixzz1zBBq8wRx
Guideline to avoid un-maintainable code
ReplyDeleteUnmentionable code:
We all have had experience of modifying the code that one has written, either to add a new feature or fix a problem in a module. The code which is hard to understand and modify by any other programmer is said to be un-maintainable code.
Detail:
Consider the following example to understand the above statement
Hard to understand code?
nY = (nTotal-1)/nX + 1;
Is this code fragment hard for you to understand? If not, then you know the technique being used. If you do not know the technique, then it is sure frustrating to figure out. This code is one way to implement the ceil function on the nTotal/nX value. He views your code through a toilet paper tube. He can only see a tiny piece of your program at a time. You want to make sure he can never get at the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely ignoreanything. Programmers are lulled into complacency by conventions. By every once in a while, by subtly violating convention, you force him to read every line of your code with a magnifying glass. Properly commenting your code is a good first step. However, keep in the back of your mind that someone else is reading your code and avoid obscure programming techniques unless they are fully commented and documented in the project. Much of the skill in writing unmentionable code is the art of naming variables and methods. They don't matter at all to the compiler. That gives you huge latitude to use them to befuddle the maintenance programmer.
Guideline to avoid un-maintainable code
1. Lie in the comments. You don’t have to actively lie, just fail to keep comments as up to date with the code.
2. Pepper the code with comments like /* add 1 to i */ however, never document wooly stuff like the overall purpose of the package or method.
3. Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named is Valid(x) should as a side a effect convert x to binary and store the result in a database.
4. Use acronyms to keep the code terse. Real men never define acronyms; they
understand them genetically.
5. In the interests of efficiency, avoid encapsulation. Callers of a method need all the external clues they can get to remind them how the method works inside.
6. If, for example, you were writing an airline reservation system, make sure there are at least 25 places in the code that need to be modified if you were to add another airline. Never document where they are. People who come
7. Never use i for the innermost loop variable. Use anything but. Use i liberally for any other purpose especially for non-int variables. Similarly use n as a loop index.
References.
http://www.schoolstuff.be/1stelic/so...table_code.pdf
How To Write Unmaintainable Code
Read more: CS504 Assignment No 5 Solution & Discussion Due Date: 23-01-2012 - Virtual University of Pakistan http://vustudents.ning.com/group/cs504softwareengineeringi/forum/topics/cs504-assignment-4?commentId=3783342%3AComment%3A1078747&groupId=3783342%3AGroup%3A59359#ixzz1zBC3YXVi