Task 10.2

Gladwell’s video revolved around Howard Moscowitz and his impact on the food industry.

The issue was first noted when Pepsi came to Moscowitz with the aim of creating the perfect Diet Pepsi. As per traditional methods, Moscowitz went about his research by making large batches of Pepsi with different amounts of aspartame, asking people to sample them and plotting down the results in a graphical format to ascertain some sort of pattern. The problem however was that Moscowitz found no distinguishable pattern. While most researchers may not be bothered by this, Moscowitz was obsessed with trying to figure out why it made no sense.

A stroke of brilliance finally overcame him when he realised that the reason for those ‘messy results’ is: People have been asking the wrong question. Instead of looking for the perfect Pepsi, they should have looked for the perfect Pepsis.

Moscowitz finally got to implement this idea with Campbell and their spaghetti sauces. He created 45 varieties of spaghetti sauce according to all the different ways spaghetti sauce can vary from each other; sweetness, amount of garlic, sourness, ‘tomamoey-ness’, visible solids... From here he gathered people to taste the sauces and instead of finding the most popular one, he focused on grouping them into clusters. He found that Americans are fans of 3 main areas: smooth, spicy and (something that was not in the market at the time) chunky.

This method of collecting information is different from the traditional methods of asking people what they want. As Gladwell points out however, people don’t tend to know what they want. And even if they do, they don’t know how to communicate it.

Another popular marketing concept at that time was by creating hierarchies for products. In doing so, companies created the perception of luxury or higher standards for customers to aspire to. This concept of hierarchical marketing, Moscowitz points out, does not really exist; all products lie on a horizontal plane and can therefore only be segmented horizontally.

Overall there is no one perfect way to create the perfect dish. Moscowitz highlights the importance of moving from the idea of universals to understanding the idea of variability, and only in “embracing the diversity of human beings will we find a sure way to true happiness”.

This idea of diversity can also be seen in software development projects. No one program can be implemented to all systems and be expected to work very well. It is therefore up to system analysts to make sure that the system they develop is designed specifically to suit the needs of the users and their environment. The key to doing this is gathering the correct information during the analysis phase. Yes, this includes asking the correct questions so that analysis and recommendations can be formed according to the system’s capabilities as well as user requirements.

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.

Levinson acknowledges that testing is not only essential but is the most critical part of the System Development Life Cycle. The problem however, is that it is also:

• The most overlooked
• The most underfunded
• The most rushed

Levinson has therefore compiled a list of 20 tips that aim to improve software testing.

The first few points seem to revolve around social understanding:

1. Respect your testers
2. Raise testers’ awareness of their value
3. Collocate your testers and developers
4. Cross-train developers and testers in each other’s roles
5. Tell programmers to chill out

Firstly, it is important to make sure that testers are aware of the importance of their work and the impact it has on the company. Simply doing this can help improve testers’ morale. It is also a good idea to hire qualified testers (particularly those that have programming skills) as they will gain more respect from system developers which, as Levinson points out, is a good thing as it helps reduce the gap between these two. Testers and developers are often on opposite ends of a stick because of the fact that testers are hired to find faults in developer’s work. This brings us to Levinson’s 5^th point to “tell programmers to chill out”. Developers must be assured that if they are doing their work to the best of their abilities and continue to learn from their mistakes, then errors found in the code will not be held against them in performance reviews.

Another way to ensure better cooperation between testers and developers is by having them interact with one another face-to-face. Personal communication aims to reduce grudges against one another. Cross-training is also a good way to improve their understanding of each other’s jobs (thereby improving relations). Moreover this leaves each group with a better understanding of the larger system development life cycle and more importantly, the importance of what they do and its impact on the overall system.

Focusing more on the testing team now, Levinson proposes to set up an independent reporting structure, more specifically, independent of the development team. This prevents the development team from attempting to hide or deliberately keep errors away from testers in the hopes that they remain hidden.

Centralizing test groups and dedicating testers to specific systems allows them to share their experiences, stick to their own set of methodology and have an in-depth understanding on of each other and the system they are allocated to.

Getting stakeholders involved in some way or other is also part of Levinson’s guide to testing.

• Giving testers business training for instance gives them a better understanding of the system they’re testing.
• Involving business users in testing help ensures that the system meets their requirements.
• Involving network operations can help identify performance issues that may originate from the way a hardware or software is configured.

Having tests in a locked-down environment and/or building a lab that replicates the business environment are also ways of improving testing techniques. A closed testing environment can prevent unwanted people (such as developers) from interfering. Having a replicated environment of course means testing in situations as close to the real situation as possible thereby reducing the number of errors.

Testing the old system with the new is one way of determining how much better the new system is in comparison with the old. As Levinson states, “some new projects may contain the same functionality as previous projects.” This can also help ensure that codes still work properly in spite of new features. Moreover this helps identify where new test cases need to be added. Ensuring that test cases are run against any code that developers have changed or added (or code coverage) is another way of reducing error rates. Code coverage tools can be used to track the number of new or modified lines of code that have been tested thereby giving an idea of how effective the testing is.

Other tools are also available to, for instance, scan source code for known problems like the fact that doing one thing a certain number of times always leads to the same problem; or to identify patterns in data to identify the root cause of certain problems.

Establishing quality checkpoints or milestones throughout the entire development life cycle can also help reduce errors as it brings about a culture of quality within its development and testing groups.

A mathematical technique called class partitioning can also be used to identify additional functional requirements as it provides testing a clear picture of the type of test cases they need to do.

And lastly, despite taking all the extra steps above, it is always best to also develop a Plan B. Preparation in particular, for the worst case scenario.

Task 2.3

And the blogging begins! Again :)

Task 2.3 asks us to write a blog entry discussing the nature of your team. Do you have a good team? Why? What makes a good team, what will you have to do as a group to be effective? How will the team make the decisions? How will you work together, how will you communicate?

Our group consists of myself, Archana, Kaviness and Abdur Rehman. Having worked with two out of the three other members, I knew this was one group I would be comfortable with; something I believe is important in every group as it helps avoid the 'awkwardness' that can halt progress.

Initially (with some people in the class still not having a group) we actually debated whether to add another group member or not. Yes, this was the first decision-making we did as a group. Unfortunately it was a 50-50 agreement. Half the group did not mind having another member as it meant more of the workload would be split up amongst us. Moreover, they said, we won't be at a disadvantage to those other groups that do have 5 people. The other half on the other hand were more concerned with how this could affect the coordination within the group; "the greater the number, the harder the coordination", they said. Plus, as this was someone none of us had worked with, they questioned the quality of their work. Or whether even they will do the work!

Because this decision affects the group as a whole and their 'comfort' levels, we ended up having to decline said person.

This is what a good/effective group should be able to do; communicate and compromise. And I am glad that we managed to resolve that in a civil manner.

Hopefully future decision making will also be done in a similar manner (as a group) and hopefully differences in timetables and schedules will not be a huge problem. Even if it does, we've made sure that we are able to reach each other through phone, SMS, email or chat :)

Week 12

I’m late again. So here I am writing up my Week 12 entry in Week 13. It was another busy week anyway and I’m glad it’s over! Assignments are finally all done! Now it’s time to focus on exams~ Which was exactly what I was trying to study for just now but got distracted and staring working on this blog instead hehe! Hmm.. my last blog entry was also a result of being detracted from work wasn’t it..? Oh wow, I get distracted way too easily.

Anyways, moving on to Week 12’s lecture.

The lecture was entitled ‘Design: System Interfaces’. This basically talked about how user interfaces have to reflect the structure or and database designs implemented within the system. This requires a thorough understanding of the inputs, outputs and data (or types of data) stored within the system. The diagrams created earlier such as the structure charts and sequence diagram can also be a useful tool in identifying these.

Another important consideration when designing the user interface is any help or customer support facilities. The system designer is not only responsible for creating the interface but also any sample reports and diagrams that the system may output. Integrity (among them input, database, output and fraud prevention techniques) and security (to limit and manage access roles, data security, digital signatures and certificates and ensuring secure transactions) controls should also be taken into consideration.

Multi-tier Applications looks at the presentation tier, business tier and data tier, the interfaces of which, should be designed separately yet complimentary to each other. The advantage of this multi-tiered approach is to reduce dependency among layers, thereby making it easier to make any changes.

Week 12’s tutorial.

We spent the class with Mr Yeap. Or rather, he spent it with us. He came in to discuss more on how to move from the analysis phase to the design phase. And to answer any questions we may have regarding Assignment 2 which, I’ll admit, (with all the other assignments also due on the same week) I had barely started on at that point.

And finally, Assignment 2. I managed to finish by Sunday, on the actual due date. Was SO happy to have completed it! Was SO relieved that assignments are all over! :D

Week 11

Busy week! I went off my usual ‘Monday = New blog entry’ equation! (Am supposed to be working on an assignment right now.. got distracted so here I am updating this blog instead hehe) But at least I’m updating this while it’s still week 11 :)

Okay then, just a short entry for today (yeah right! That’s what I said last week huh).

Week 11’s lecture still discussed the design stage.. Hang on.. *thinking*

Backtrack. The first thing we did in the lecture was finish off the Week 10 lecture slides because we didn’t manage to finish them last time. We revised through the first-cut sequence diagrams then proceeded to look at collaboration diagrams and design class models. Our lecturer was determined to ensure that we really understood these concepts because this is an important part of Assignment 2. And I have to admit, it really helped.

The second half of the lecture covered the slides for Week 11, entitled Design: The user interface. This lecture talks about the importance of being able to identify the various inputs and outputs relating to the system and selecting an appropriate interface for users to interact with the system.

There are three aspects of the user interface to remember:
1 – Physical aspects: Devices touched by the user
2 – Perceptual aspects: Things that the user sees, hears or ‘touches’
3 – Conceptual aspects: What the user knows about the system and the logical functions relating to it

We then proceeded to discuss the actual user interface and how to go about designing it, and the concept of a good HCI design.

Despite being sleepy (due to lack of sleep throughout the week, not because the class was boring or anything :D) I found the tutorial to, yet again, be extremely helpful. Not just for exams but also to drill all that we learnt in the lecture into our heads. Those Additional Exercise Questions covered most, if not all, the important concepts related to the lecture. Having us spend the class looking for the answers ourselves was indeed useful revision. What’s even better was discussing the answers at the end of the class instead of emailing our solutions. In this way each student can contribute any additional points they may have. What’s more, knowing that we’ll be discussing the solutions at the end of the class encourages us to find more points and finish as quickly as we can.

And lastly, we had a short photo session. Mr Ramesh wanted a class photo for memories sake which was a very good idea indeed. I want those photos! Both of them! The high-quality ones! :D Sad though.. our last class. The semester went by really quickly! I feel like I’m still trying to get to know my classmates and tutors.. Sad to have to say good-bye just as we’re all getting acclimated.

... Why am I getting so sentimental? It’s not like this is truly good-bye! I’ll still be able to see everyone around campus! I hope :) Thanks for everything everybody. And a HUGE thank you to Mr Yeap and Mr Ramesh!! Make that a SUPER HUGE thank you :)

Week 10

Hello :) Monday is upon us again and based on that equation I’ve been following since the third week of this semester: Monday = New blog entry.

The last few days have been quite.... (what’s the word I’m looking for..) ...hectic ? Well, busy anyway, as I - and every other FIT2001 student I’m sure - raced against time to tackle Assignment 1b. With assignments piling up and being due at around about the same time, I’m starting to find myself struggling to keep up. Last week and this week don’t seem so bad though; it’s the thought of these upcoming two weeks that scare me; 3 assignments to be submitted in each week. Week 11 assignment submissions: Wednesday, Thursday and Friday! Even thinking about it makes me feel like crying! *sob*sob* One step at a time. Or so I tell myself.

(Now that my rant on my assignment schedule is over..) Assignment 1b covered the Analysis Phase of a project, the results of which were submitted as a Requirement Specification. This contained an executive summary, a definition of the system scope (using a context diagram), a discussion of the system’s problems, opportunities and limitations, event tables, use case diagrams, use case descriptions (both brief and detailed) and analysis class models. This assignment gave me a little taste of what it’s like to be a systems analyst *wondering of whether I’d enjoy the profession or not*

So anyway, moving on to this week’s materials..

After my disappointment on the shortness of last week’s study guide, I’m pleased to say that this week’s study guide is 14 pages long! :) A fun read. And as usual, I found it easier to understand (and more fun to go through) than the lecture slides. This week’s topic is still part of the design phase and is entitled: Use Case Realisation. This basically explains that the design stage is about building up on what we did in the analysis stage. It is about adding more detail to give the programmers a thorough enough understanding of the system for them to actually build it. It is about bridging the gap between the business side and the technical programming side.

The lecture covered:

• the development of design class diagrams and interaction diagrams (sequence and collaboration diagrams)

• coupling and cohesion - these are basically about making classes as independent as possible thereby making them easier to maintain

• use case controllers, as an intermediary between the outside world and the internal system

I don’t know whether it’s because I just got used to drawing and developing diagrams for Assignment 1 or something but seeing the step by step development of the sequence diagram kinda looks fun! :D Overall it was a fairly long lecture.. we didn’t managed to go through all the lecture slides. Even so, I think we’ve absorbed enough information for today.

Today’s tutorial revolved around data flow diagrams. More specifically, being able to identify the system boundary, dividing them up into program components and converting them into a system flow chart. It was good practice. I always appreciate these class exercises because we get a chance to apply what we learn in the lectures into more practical context. What’s more, it gives us a chance to clear our doubts with the tutor. We didn’t manage to finish the Additional Exercise Questions during class though, so he has asked us to email him our work. In the meantime, going through the questions will give me a chance to further clear my doubts. Hopefully.

Lol! Odd how I planned on writing a ‘short’ entry (so I can proceed with the Additional Exercise Questions and get it completed today) and ended up writing this much!

Week 9

"Week 9 already??" These were the words that popped in my head as I was downloading this week's lecture slides. Plus one extra exclamation mark. But really, the semester’s gone by really quickly! But you know what I realised today? These blog entries really are helpful! In today’s tutorial for instance, we were working on Activity Diagrams and Sequence Diagrams, and I remember us being given an a question on Activity Diagrams before.. in one of the Additional Exercises. A quick skim of my previous entries (and entries of a friend who I distinctly remember working hard on that question) revealed that the Additional Questions were given to us in week 4. And I also remember that the actual lecture slides I was looking for (the first time we were introduced to Activity Diagrams) was one week prior to that :) Lovely isn’t it?

The Sequence Diagrams were even better: ‘Where have I seen those stick figures before...?’ It took only a few scrolls for me to find my enthusiastic comment regarding the colourful diagrams and stick figures from week 6 :) Same thing when I’m trying to work on the assignment.

Move on to today’s lecture.. Another colourful set of slides by the way. But I’m starting to think too many similar diagrams in one lecture is too confusing for me. I mean, I understand that the next few diagrams were only trying to show the different depths or level of detail but still... hang on~ *backtrack* Perhaps I should talk about what the slides were actually about before starting my rant :P

Today’s lecture was entitled: Structured Design. This is about the traditional approach to designing i.e. NOT object-oriented. This refers to methods such as Data Flow Diagrams (DFDs) and System Flowcharts. We also learnt about the Automation System Boundary which covers the need for being able to identify the manual and automated processes within the system. This is useful for the creation of modules. Structure Charts are also useful as they are simple, help describe functions and show the relationships between the various modules. There are two approaches to developing a structure chart though: Transaction Analysis or Transform Analysis. Transaction Analysis is more appropriate for upper-level modules that process multiple input or transaction types. Transform Analysis on the other hand uses DFD fragments as inputs and is therefore more appropriate for designing programs that converts inputs to outputs.

We also covered Evaluating the Quality of a Structure Chart: through module coupling (measuring how the modules are connected) or module cohesion (measuring the internal strength of modules i.e. performing one defined task). Lastly, we talked about Pseudocode, a form of module algorithm design, and the Three-layer Design, which consists of the view, business logic and data layers.

Yup, that’s another week’s worth of lecture to be drilled into our brains. The study guide was very short though!! I’m disappointed.. I look forward to those study guides each week! I guess that’s a hint for me to stop neglecting the textbook for additional reading..