Sunday, October 17, 2010

Task 10.2

My last blog of the semester and it is about the GREAT GLADWELL! I remember from last semester when doing FIT2001 System Analysis and Design (SAAD), Gladwell gave an interesting speech on "Armchairs" and how chairs should be made by manufacturers based on consumers requirements with special attention to comfort level. Once again i have a blog to summarize his useful and very INTERESTING speech.

Gladwell introduces "Howard Mascowitz", a personal hero of gladwell who was famous for reinventing the spaghetti sauce and was a reason for Americans to be happy for the last 20 years. Furthermore he describes "Howard Mascowitz" as a wonderfully exuberant person who had interest in measuring things and so was a "Psychophysicist" in profession. He set up a little consultant shop in white lanes, New York and his first client was Pepsi back in the early 1970's.

So Pepsi came up to him and asked him to figure out how much "Aspartame" must be used to make the perfect pepsi. They made his job easy by saying to use a band of 8-12% to figure out which was the sweet spot between this range as below 8% was considered not too sweet enough anf above 12% was considered too much sweet. They took a batch of hundreds of people for the experiment, had them taste pepsi of different degree of concentration, plotted the results on a curve and took the most popular concentration. However, to Howard this seemed messy and meaningless data. He was a man of high intellectual standard and could not make a fair judgement out of the results. So after long and deep thinking, Howard realized that pepsi was asking the wrong question, they should not look for perfect "Pepsi" but perfect "Pepsis."

At first people rejected his idea and thought he was crazy however one day he got a breakthrough when Vlasic Pickles came up to him to help them make perfect pickle. Dr.Mascowitz came up with the idea that not only do they need to improve their regular but should create "Zesty" pickles. Similarly, Campbell Soup, owner of Prego, was struggling in the sphagetti sauce industry against Raghoo and asked Howard Mascowitz to help fix them.

First, Howard went about making 45 varieties of spaghetti sauce which varied from sweetness, sourness, level of garlic, tomatoeness, tartness and visible solids. Just simply any possible way you could imagine spaghetti sauce to be done was made. Now he took a huge sample of these spaghetti sauces and went to Los Angelos, Chicago, New York & Jackson. There he brought in a truckload of people into a hall and made them taste them for 10 different bowls of spaghetti sauce. At the end of testing, he got them to rate each bowl from a range 0-100. Later after a few months he had a ginormous amount of data. Then he decided to group them into clusters and found out that what Americans felt about sphagetti sauce. Mascowitz found that there were 3 groups of that people like about spaghetti sauce: Plain, Spicy and Extra Chunky.

However, at that time there was no company serving the needs of one-third of Americans who were craving for extra chunky spaghetti. Campbell soup changed their spaghetti formula to meet this need. This immediately and completely made them take over the spaghetti sauce industry for the next 10 years. This is were Howard Mascowitz value was realized which led to the making of 14 kinds of mustards, 71 different kinds of olive oil and eventually Raghoo hired Mascowitz. Now in a good supermarket outlet you would find Raghoo available in 36 kinds and 6 varieties: Cheese, Light, Robusto, Old Bowl Traditional and Extra Chunky Garden.

Howard Mascowitz just fundamentally changed the way the food industry thought of making people happy. Before the food industry use to make this 3 assumptions. First they would think that the way to find out what people want to eat or what made them happy was to ask them. This was wrong. People don't know what they want. My favourite quote of Howard Mascowitz was "The mind knows not what the tongue wants."

Second assumption was that food products can be at the top hierarchy. Food industry thought they could make products that were more expensive, more sophisticated and culturally meaningful like remake the italian tomatoes sauces. This was another mistake. Howard Mascowitz introduced the phenomenon of "Horizontal Segmentation". There is no good or bad mustard, no perfect or imperfect mustard. Its just that all mustards exist in the same horizontal plane and different kinds of mustards are made to suit different kinds of people. Simple as that!

Third Assumption, the food industry was creating a sense of feeling that there is a perfect way to make a dish. Again this was a big mistake. Howard took over and changed the thinking. People believed more in univerals rather than variables. Example of Universals was to provide culturally authentic dishes like italian sauces would maximize number of satisfaied people whereas variables was basically making dishes in different ways to suit different tastes.

And this was the most important and splendid lesson taught by Mascowitz was that people are different in all aspects and through development and breakthroughs in genetics it has been proved. The tomato sauce needed to realize that this revolution is taking place and by only embracing the diversity of human beings will certainly ensure true happiness.

This ends another exciting semester and i did enjoy writing the last blog. Gladwell was very inspirational with his words and his stories.

Thanks to everyone (especially my followers) for reading my blog
.

Best of Luck FIT2027 Students for the EXAM!!!

Task 9.1

A recent CIO magazine podcast featured a discussion by Meredith Levinson discussing her top 20 tips for software testing. Follow the link on the week 9 panel for the unit and listen to the podcast. Make a critical summary of Meredith Levinson's top 20 tips on software testing (3 value points, 5 individual points, 5 implementation points). Post the summary on your blog.

Through the podcast Meridith Levinson gives an in-depth insight into the best practices for software testing. The podcast begins by telling that testing is the most overlooked, underfunded and most critical aspect of software development lifecycle. Testing is vital to developing high quality software to ensure smooth business operations. Businesses put themselves under extreme risk of substantial losses when they fail to effectively and adequately fail to test software for bugs and performance issues or determine whether software meets business requirements.

There are 20 tips proposed by Meridith Levinson on the best ways to go about doing quality software testing and will go through this in some detail.

Firstly, Meridith mentioned the importance of recruiting highly qualified testers who know about the code in detail will help earn the respect of software developers. Similarly, it is important to highlight the tester’s work and their impact on the company to increase their morale and make them more diligent in their work. Another tip is to merge the developers and testers to have some sort of personal interaction on a regular basis so they can remove any communication gaps between them.

Cross Training is another concept that helps to establish firm understanding between testers and developers. Levinson emphasizes that developers need to be given assurances that despite them making a few mistakes they would not get negative performance reviews as long as they are diligent in their work and are willing to learn from their mistakes. This helps to ease frustrations of developers who take pride in their work to understand that the tester’s role is to find faults in their work to make it better.

The sixth tip is to let testers report to a group who is independent of the developers group so problems are revealed and fixed instantly. It is also essential to centralize testers into one group rather than a particular application area to ensure testers share best practices and lessons learned after completing a project. Next, testers need some on-the-job training and strong focus towards more specific systems to deepen their understanding of the system which helps identify problems that were not shown before in the test documentation. Moreover, involving network operations experts in the testing phase allows actual implementation to be done smoothly.

Furthermore, Levinson mentions in her tips that its necessary to have your own test labs to mimic the same business environment and testing must be done in locked environment, to ensure minimal interference from developers. Likewise it is essential to have old and new systems running simultaneously in the testing phase to integrate good features and eliminate the bad ones. The podcast also introduces a new concept “Code Coverage”. Code coverage basically keeps track of the number of modified or new lines of code tested to check the effectiveness of the testing as modified code often leads to bugs. Other alternative ways to search for defects in code such as scanning the source code thoroughly for any potential problems and using pareto tools to identify root causes of defects in software. Besides detecting defects it is vital at the same time to establish checkpoints and milestones to foster a culture of quality among its development and testing groups.

The Last two tips Meridith metioned about were: Apply equivalence class partitioning and Develop Plan B. Equivalence Class partitioning is basically a mathematical technique testers can use to identify additional functional requirements that users and business analaysts might have overlooked whereas Develop Plan B refers to a contingency plan to be in place in event system does not work the way it supposed to be in spite of the best efforts of testing group.

All the above mentioned 20 tips lead to this conclusion that testing is a rigorous and critical phase of the software development lifecycle. Thus it is important that all people involved in the testing phase must collaborate, communicate effectively and be considerate to the needs of each group to forge a healthy relationship that will result in successful software being developed in future.

Sunday, October 10, 2010

Task 7.5

Time to blog again and what an interesting topic i have got to talk about! .... :)
My topic to discuss is about Monash University Library Catalogue Usability Study. The purpose of this study is to to provide data to assist with the redesign of the catalogue’s user interface. The aim of the redesign is to add some new functionality and improve both the usability and aesthetics of the library catalogue. Thus participants are recruited through advertisements placed on noticeboards in Monash University Library Branches and other locations in Australian campuses, through the library website, notice in Monash Memo and via email discussion lists. The payment for participants taking part in this study would be a $50 book voucher given at end of usability test.

By users taking part in this study will help the Monash University Library and Web Resources and Development improve the design, making it easier for staff & students to use.
The Usability Test consists of the following components: Methodology, Facilitator Script (Testing Script), Background Questionnaire, Consent Form and task lists. Now let me take you to each component in some detail for better understanding.

1) Methodology: This is just like a plan or itinerary as to how would the usability test be conducted. It mentiones about the objectives of the test, the testing environment, types of users involved, summary of tasks/ activities to be done, recruitment of participants, data collection method, data security, particpant greeting, etc.

2) Facilitator script: introductions, objectives of test, what activities/ tasks to be done, and some advise and instructions to be followed.

3) Consent form: Basically asking permission to video tape user actions during the usability test for research and analysis purpose. This form also mentions that data will be retained in Information Technology Services (ITS) Division for protection and user can access that information at any point in future and users are free to ask questions and leave test at anytime.
4) Background Questionnaire: A set of questions ranging from mcqs to comments must be filled by users to get feedback on test and improvements required in system. It comprises of sections such as general information. computer experience, internet and web experience and familiarity with use of library catalogue.

5) Task lists: 7 tasks are listed down for users to complete in 2 hours. The tasks will cover the basic concerns that Monash Library Stakeholders have regarding the catalogue system which are: Catalogue Terminology, Search Behavior, search interface, search limits, search results screens,saving, emailing and printing,loan or book requests and managing loans.
After thorough reading of the materials of the Monash Usability Study, i observed lots of repetition from one component to another. That makes it quite annoying for the person reading the materials and even the user could be confused as which oen to follow and might face information overload. For example the usability study objectives, introduction, payment of participant, study/ testing environment, data storage (in consent form) or data security (in methodology) all are available in each component of the usability study and is repeated. Sometimes it feels like one component has less/ more information to the other component. Similarly i found the questionnaire sections to have some irrelevant questions which are not justified like internet usage and eyesight questions. Lastly i would like to criticize about "thinking aloud protocol". Personally i feel that thinking aloud may create a noisy environment and users might feel awkward. This type of method would be more useful if its done for one user at a time and this was not mentioned in the usability study components. Because "thinking aloud" with many users in one room means making noises and creating distractions for users to concentrate and express themselves freely.
Besides that the usability study materials look professional and shows how professionally it is going to be conducted by Monash University Library and Web Resources and Developement. the usability study sample materials were so useful that i used it as a good reference and foundation for my usability test for moodle.
Hope you enjoyed my blog! .... :)

Monday, October 4, 2010

TASK 5.4

This task is to summarize the research paper "Automatic Transformation from Data Flow Diagram to Structure Chart". Researcher, Minyi Guo, emphasizes the importance of transforming data flow diagrams into structure charts during the software design phase.
This paper not only highlights the importance of the transformation but also the difference between data flow diagrams and structure charts and how they use transform and transaction analysis to bridge the gap thereby ensuring a smooth transition between software development phases.
From the paper, we understand that a data flow diagram is a natural tool for the analyis phase of the software life cycle. It is also a graphical network representing the processes and data interfaces of a system. On the other hand a structure chart is useful in design and implementation phases and is also a graphical tool for descibing the hierarchy of modules to be implemented as well as algorithmic relationships and communication links among them.
Guo then describes transform and transaction analysis in further detail. The main definition i captured from the paper was this:
"In transaction analysis there is a transaction center which captures an input transaction, determines its type and then processes it in the appropriate branch of the center while in transform analysis the input and output data streams of a data flow diagram are followed to determine the central portion of the system responsible for main transform of data."
Guo also mentions about structured analysis and structured design being the most popular and successful software development methodologies used in most CASE (computer-aided software engineering) environments.
However despite these methodologies being successful and popular, the process of transforming from software specification to design document is not only complex and diffcult but cannot assure correctness. Thus, a tool called CAST (Computer-Aided Specification Transformation) has been constructed to automatically translate requirement specifications into design specifications during the development phase of the software life cycle.
CAST consists of a description language, a rule base and an automatic transformation system. It accepts a software specification expressed in terms of data flow diagrams as input. Then the researcher mentions about how the CAST system actually works. In brief, data flow diagram is inserted, then translated into a structured language representation. After this is done, it is determined whether transform or transaction analysis would be used to produce structure chart. Once that is decided, a structure chart is formed, evaluated and finally displayed to Sc_file.
Now last main point discussed in paper is about problem identification. The paper emphasizes about the improvements that need to be made to the proposed techniques of using structured specification language and transformational algorithms. The main areas needed for improvement are efficient use of semantic information to improve quality of transformation and better description of structure chart evaluation criteria.
That's all....
It was a long article to read and took me time to understand. Hopefully this summary is good enough to cover the main points of the paper... :)

Friday, October 1, 2010

Task 2.3

Now it's Semester 2, 2010 and blogging begins again. This time for FIT2027 System Design & Implementation (SDAI).


For this task, I have been asked to answer a few questions. Questions regarding the nature of my team such as do i have a good team and why? What is required to be done as a group in order to be effective? how will team make decisions? how will you work together and how will you communicate?


Firstly, I believe that i have a good team. The reason being that it was my first choice team and i was glad everyone agreed to be part of my team. I consider my team to be a group of smart individuals who come up with bright ideas and have the relevant business as well as I.T skills required to do a good job for this unit. My team comprises of 4 people: Archana, Abdur Rehman, Farhanah and Kavinesh.
Moving on, I think as a group we need to be very frank with each other and be very helpful to each other so everyone feels comfortable in the team environment. Based on my experience of working with my team, we always look to divide work according to a person's level of ability and at same time provide guidance if they are stuck in some part of the task assigned to them. This requires each member of our team to be patient, considerate and compromise whenever possible.


For instance if one member has some other commitments or other priorities he needs to give attention, we postpone our meetings to a reasonable extent to accomodate their needs. Basically we have a good rapport with each other since we know each other and we know each one of us are responsible people who will do their work.
In order to be an effective team, we need to have good time management skills and be committed to doing the work for the unit. By time management skills i mean proper planning of how much each individual member can realistically give to do their parts, be available for group meetings and research to give valuable input to the team's final work. Because the amount of tasks to do for this unit can be tough at times so self motivation or motivation from team members is required and luckily my group members have those characteristics. Confidence in each one's ability and knowing strengths and weaknesses of each individuals helps to divide work appropriately, which means less conflicts and wastage of time.
The team will make decisions based on majority votes. We usually consult everyone about a decision in our meeting and first know about our member's opinion regarding a particular topic. Then we have a voting process and majority votes wins the argument and everyone respects the decision. The hardest decision so far our team had to make was this one situation when we voted and it was a draw. 50% agreed and 50% disagreed. We ended up convincing each individual of the team to change their opinion to make the majority votes win. This situation was about adding another group member or not to have 4 members or 5 members. Members agreed because it would have brought new ideas and workload would be reduced whereas members disagreed since it would lead to more conflicts and co-ordiantion problems especially since all members did not know the standard of work that the added member does. In the end after a thorough discussion our new voting results were 75% disagreed and 25% agreed.
Our group would usually communicate over the phone, via SMS messages and e-mails. We would book discussion rooms or work in labs that are less crowded to have more focus and discuss in peace. We would have meetings on days when everyone were not so busy with other commitments and when it was required to meet a deadline soon.
So far everything has gone smooth with my group and i am truly grateful to have such a group... :)