FIT2001 week 7: wrapping up analysis on the run

I noticed with great excitement that analysis is finishing up this week and that we’ll be getting into the design next week. This week seems to be very similar in content to Project Management. I also heard on the recording that POD had just written the exam for the subject, so if he says something “might well be on the exam” it would be good to listen up!

This week I didn’t manage to listen to the lecture on Friday, as per my usual schedule, but listened on the go with my iPod during a youth group scavenger hunt: I was a leader and the groups had to find me as I moved around the Ringwood/Eastland area. I was annoyed to find out that my “video ipod” didn’t actually play the video podcast that played fine on my computer. Oh well, I got the “no slides” version of the lecture, but managed to listen and take notes in 4 different locations while ‘hiding’ from scavenger hunting teenagers.

Actual Thoughts on the Content
Of course, we are taught Analysis first and then Design, but in real life they often run semi-concurrently. This weeks lecture also talked about when Analysis isn’t the precursor to Design, but the precursor to a Request for Proposal, which is a big list of requirements with an introduction for the system that you want to buy from some one else.

The “end of analysis” is gearing towards a massive report (much like our Assignment 1b) that a Senior Analyst and Project Manager would discuss with each other and present to Senior Management and major stake-holders, who have the power to decide the future of the project. The report consists of lots of diagrams. The big part of the report is prioritising the requirements and deciding the Level of Automation.

The Level of Automation is a good one to look at first- basically it is deciding how much the computer is going to be involved in that component of the system. There are, of course, advantages and disadvantages to automated (computerised) systems. It sounds like any time you automate something you need to take care, because of course, Computers are Stupid (only doing what they are told to do.) For example, the Monash Swipe Card security system relies on user honesty as well as the computer reading the barcode/chip on the ID card. If security was really important a tough human security guard would be a better bet. Sometimes automation makes a work flow really simple, easy, and cheaper. Or it could make the system really complicated and expensive. That is why we do Analysis, to find out which.

As well as working out how much we need to automate the different components, we also need to look at whether it is worth building the components at all. No project has an unlimited budget and unlimited time, so no project can implement all of the features that it wants. So, we need to limit what the system does (Scope) so we can complete it. Scope Creep is when the client (or Analyst!) keep changing the scope of the project by requesting more, well, Bells and Whistles, usually. If something comes into the system, something else usually has to go, or be less automated.

Of course, all this info needs to be communicated to the Senior Management (by the Project Manager and Senior Analyst) so they can make decisions. So while we’re thinking about the technology now it still is at a high level so we don’t confuse the boss. All compromise is political and the big IT companies make sure to network with the Board members and Senior Management.

We also talked about scoring systems to make decisions, which is also covered in Project Management (FIT3086.) What you do is have different categories (such as price, quality, time, etc) and for each category assign a “weight” (maybe price is more important to you than, say, colour), and for each option assign a score under each category.

Option Price Quality Time
A 1 4 4
B 2 4 3
C 5 4 1

The Assignments
I found out that my tutor has marked my assignment and is just waiting for the nod to release the marks on Moodle. It was good during the tutorial to discuss my event table. I had mistakenly said “the end of analysis” in my little blurb at the top of the assignment- of course the Functional Requirements Specification marks the “end of analysis”. I was a little confused as to what the first assignment was for beyond practising the Event Table, but I think it was a “touch base” kind of thing with the client, with the major report to come in Assignment 1b. Now I get why they are 1a and 1b.

The Quiz
The quiz shows me what I knew before I learned it, this is what I didn’t know.

I like how Dilbert seems to be on the Systems Analysis and Design wavelength, maybe there is some conspiracy theory there! Does POD look like Dilbert (a little) without the curly tie? I haven’t posted Dilbert in a little while, so here is another one:
Dilbert on Vendor Comparison.

I’ll be posting some resources useful for the assignment (such as links to tutorials on how to write a business letter) as I get around to it.

April 24, 2010 | |



Comments RSS

2 Responses to “FIT2001 week 7: wrapping up analysis on the run”

  1. Glenn on April 25th, 2010 1:03 am

    Going all out on Dilbert this week! Two comics in a week!

  2. Glenn on April 25th, 2010 1:05 am

    BTW ERP in my opinion is not another term for turnkey.

    Turnkey can be a standalone product like MYOB that the payroll department use. It doesn’t integrate into much else apart from what the payroll department use it for.

    ERP and systems like SAP are supposed to be used enterprise wide for all sorts of information system requirements. Its a big mammoth thing that large companies/organisations like Monash love (or the executives of large companies anyway)

Leave a Reply