Finally, I’ve put down my pen for the last time for Semester 1, 2010; now I can relax and enjoy a few weeks of holidays. Before I archive my uni stuff, I thought I would do a short review on each of the units I have taken this semester.
My lone arts subject this semester, Introduction to Critical Theory was the unit I chose because I could do it at third year level without any pre-requisites, I need a certain number of third-year points to graduate. I also could count CLS3000 as an elective for my Spanish Major. There is a lot of reading in this subject, but it’s really interesting stuff. Sometimes it was a bit hard to grasp the ideas, but the class discussions were always fun. I really enjoyed writing my final essay. At first this subject seemed really difficult, but in the end it was one of my favourite units.
My last-ever second year level unit, Systems Analysis and Design is probably the best unit I have taken so far in terms of student support. The resources available in the forums, Moodle site, Study Guides, Lecture slides, podcasts of lectures and podcasts of interviews, chat rooms and more! were made even more useful by the active involvement of Peter O’Donnel (aka POD), the Caulfield lecturer and chief examiner for the unit. Being friendly with the students over twitter, we could ask quick questions very easily. Sometimes the topics covered were pretty boring, but POD fought hard to make the lectures, tutorials and assignments interesting. I found that the best way to tackle the assignments was to have a go, then get the tutor to tell you what was wrong with your diagrams. My tutor was very helpful. Rocking up at the student consultation sessions was well worth it. A helpful tutor is basically giving you free marks when you ask questions! In the end, I think I know that a career as a Systems Analyst isn’t really what I’d like to pursue, but I wish more subjects were like FIT2001. Even having lecturers and tutors hang out in the forums before an assignment is due or before the exam would be a good first step. Speaking of the exam, the format of this subject’s exam was great. A good mix of confidence building easy questions and questions that stretched you.
The project was to create a design document for a website and then build it. This was worth 30% of the mark, which makes sense because it was group work. 30% is understandable as you don’t want to be pulled down too much if you’re lumped with a bad group. I found working in a group frustrating but we got it done. The assignment marking system was interesting, with a system of ranking by peers. I think this was useful to see what everyone else was doing.
The low 30% assignment mark made the exam a scary 70% of the mark. Due to the really broad nature of the subject, the exam was hard to study for and required lots of memorisation. The format of the exam was also annoying, with heavy black lines ruled through the question answering space. I prefer either thin lines (like in the separate answer book) or no lines (like the FIT2001 exam), not lines that cramp my writing. I also was annoyed that “look up in your own time” stuff was examinable, so you had no idea what really was going to be on the exam. Part of good exam revision is preparing for the exam format as well as for the kinds of questions, so the sample exam wasn’t as useful in that regard. The exam was out of 145 marks, not 100, which is a bit weird and awkward for time planning.
The tutorials were optional, and were like Q&A sessions, and could have been vastly improved if they had been held in a computer lab. The exercises provided were good, but there was no real incentive to try them. Having a piece of code on a screen to say: “it’s supposed to do this, but it does this” is better than having to demonstrate your code projected on the wall!
To improve this subject, I would make the exam worth 60% of the final mark, the two group assignments out of 30% and add a 10% tutorial component. Basically an easy 10% where you would get marks full marks for completing the exercise, half marks for attempting the exercise, and one mark for turning up.
Project Management. Before starting this subject I thought it would be pretty ordinary, but the first lecture got me interested. I really enjoyed some of the exercises: crashing networks is like a sudoku puzzle. However, the lectures soon became incredibly difficult to sit through. The tutorials were good, my tutor was really professional and helpful. The second assignment was pretty ordinary and annoying. Being forced to wrestle with Microsoft Project was pretty annoying also. The exam was ok, I hadn’t reviewed ROI but overall the exam was ok. It could have been made a bit clearer and less ambiguous- I’m sure language and learning would have been able to help. This subject has great potential, but it falls short. Because it has the potential to be so good, it’s sad that it’s terrible. I’ve heard that you can knock this subject over in two weeks during the summer semester.
Next semester I’ll be taking:
- SPN3730 Dictatorship and Democracy in Contemporary Spanish Fiction
- ENH3360 Fairy Tale Traditions
- FIT3080 Artificial Intelligence
- FIT3036 Computer Science Project
But for now I’m going to enjoy a well earned break!
So, you’ve sat down and written out a detailed use case description for the first part of the case study. You’ve drawn your Use case diagram with cute stick figures and bubbles for the use cases. (Not forgetting the automation boundary of course!) Now you’re moving on to the next question.
A Sequence diagram (oddly the 2006 exam seemed to think that s was a vowel- “an sequence diagram):
- Remember, this is the one with the boxes for objects, an actor on the left hand side, and vertical dashed lines (lifelines) descending from each one.
- Remember that the time scale is vertical, so if a message is passed before another one, it needs to be above it on the diagram.
- Look for the messages (methods) that will be passed: look at the flow of activities in your Use Case diagram.
- What objects do you need? It’s a first cut sequence diagram for the exam (I think) and the 2006 exam is a full 3 layer sequence diagram so you won’t need Data Access Objects, but you will need a boundary object (interface) a handler and other objects.
I’m attempting to drill this Detailed Use Case Narrative into my brain (but I know I just need the vibe- still, every bit helps) by blogging it- something about using both hands to type seems to engage the brain more.
- Use Case Name: Fairly obvious.
- Scenario: Maybe we’re using the same use case in slightly different situations, such as a web order and a phone order
- Triggering Event: what starts the use case
- Brief Description: Can be taken from your original brief Use Case description
- Actors: People or external systems involved
- Related Use Cases: What other use cases might be involved?
- Stake-holders: perhaps departments that need to provide information/stuff
- Pre-conditions: What must exist for this use case to happen
- Post-conditions: What will be created/changed at the end of this use case
- Flow of Activities:
- Actor: what the actor does (numbered)
- System: what the system does in response (1.1, 1.2, 2.1, etc)
- Exception Conditions: what happens if something doesn’t work right: maybe an item is not in stock.
So that’s a detailed use case description.
Edit: perhaps the sign of a tired mind, but here’s a fun saying to help remember them:
Uncle Sam Tells Big Dog About (Really Something Pretty Preposterous): Flying Elephants.
This lecture was a bit different to the other lectures I’ve listened to so far: I was in Clayton, watching POD in real time and in real life, no UStream, no 1.7x speed podcast recording! The lecture also was a bit shorter than usual being a revision lecture.
POD spent some time going over the fundamental “vibe” of the unit to give us some input in where our degrees are taking us, and where our heads should be in approaching the exam. IT is an arrogant industry- it is true that we know more than the business when it comes to some things, but it’s really important to not portray that too much and approach designing their system understanding their mindset and perspective. We break big problems into small ones and solve them. This is the age of Information Technology, so we are learning about the systems that RUN THE WORLD. This is pretty mind blowing.
Anyway, on with what will be on the exam.
The exam is in three parts:
- Part A is multiple choice (20%)
- Part B is short answer (40%) (8 questions)
- Part C is a case study with modelling questions. (40%)
The useful things to look at for exam preparation are the weekly moodle quizzes, the questions in the textbook (which may be oddly familiar when sitting the exam) and the unit objectives at the beginning of each lecture.
The marks indicate how much time to spend on a question. 1 case study = 4 questions = approximately 18 minutes. Use Case: try and memorise the use-case narrative, but the vibe is more important, don’t freak out too much! Make sure you draw the use-case that is asked for in the question. The SSD will be the first cut of that use case. Will need to know a Domain class model.
POD then went over how to take an exam. This is always good to go over before starting an exam period.
- Stay calm.
- Read during reading time. (Make mental notes, read backwards, read the case study)
- Compose your first answer in your head ready for the start of the writing period
- Write in pen. (drafts ok in pencil)
- if you feel confident knock off the hard questions first while you are at your best, mop up the easy ones later.
- If you are not confident then do the easy ones first to build your confidence.
- Have rigourous time management. If you get bogged in a question, leave it and come back later.
- Answer every question.
- Stay until the end of the exam. (You never know when your brain will finish ticking over the information you’ve given it, if you leave early you might leave before your brain has properly sorted something out.)
Only four people showed up to the tutorial, which meant I was able to ask lots of questions about my assignment and what I could improve for the exam. I’m a little concerned as to what my assignment mark will be and of course I should have asked these questions BEFORE I turned in the assignment. I just have to wait for my assignment mark (come on tutors!) and chill. We also looked briefly at implementation.
This was also a different way to take the Quiz, it was a revision quiz and I also took it after listening to the lecture. I did well, only failing when I double guessed myself and chose “None of the Above” for one question. I’m going to re-take all the quizzes to see where my gaps of knowledge are.
This is my last (maybe!) blog post for FIT2001, I was intrigued at the beginning of the unit about the blog. I am a blogger and blog for fun, and these posts gave me something to blog about again. I noticed that a lot of people didn’t keep blogging after week 6, I suppose assignments do get in the way of something that is only worth 3%. What I really like about this system is that it forces me to summarise my notes. I’ve seen in past units that if I summarise the notes pretty soon after the lecture, adding keywords and fleshing out the notes, I do really well at the exam/test. I think it’s something about telling your brain that you’re serious about laying down those electronic pathways. I wish all subjects had a 3% incentive which would “force” me to summarise my notes each week. Or I could just up my motivation.
All the best for exam revision students, and teachers: all the best with marking!
Woops, it’s not really week 12 any more… I skipped this lecture because of the crazy week 12 assignment load. I did attend the week 13 lecture in person before listening to this lecture, but I’ll keep the order for the sake of nice looking web archives.
This week’s lecture is on system interfaces, that is, places where your system talks to other systems/things. Last week we covered Human Computer Interaction (HCI) but this week our focus is on removing the human as much as possible because humans spew errors every time they touch a computer. We can make the system accurate by leaving the human out of it and focus on electronic things talking to each other. I’m not saying “computer to computer” for a reason because a computer-based system may talk to a not-computer system, like a temperature probe or other kind of sensor. (An example of this is something fun I’d like to play with: Home Automation.) When electronic devices talk, what they are doing is passing data around. We need to make sure we format the data we send and understand how to read the data we get. We can find out where the system interfaces are by looking at the Automation Boundary on our DFD or structure chart.
The other big focus here is the Database. Systems need to store data, and a database (DB) is the way to go. While Object Oriented Databases exist, Relational databases are the industry standard, the big names are Oracle Sybase, DB2, SQL server, Ingres, and MySQL is really big on the web. (MySQL is where this post gets stored, where the comments get stored, and WordPress pulls the posts out when it shows you the website.) We learn about Databases in FIT2010 (or FIT1004) and for me that was a few years ago, so I needed to review some of the key concepts in order to understand a bit better.
POD really emphasised how important it was to at least know the names and the trends to help us in our jobs, (at the very least to impress the pointy-haired management, or clients), so I’ll point out something interesting: NoSQL Basically SQL can be pretty nasty if you’re trying to build a web application that scales nicely (that is, grows from a small user base to a large one without loss of performance or functionality.
(twitter had visible issues with this in 2007, particularly around big spikes of traffic such as MacWorld, some bloggers pointed at Ruby on Rails, others at the database. coding horror’s take, radical behaviour.com interview with Alex Payne of twitter and Ryan Tomayko (of GitHub) says it must be Twitter, because he doesn’t have issues with Ruby+DB.)
Back to NoSQL: it moves away from the relational database model to effectively deal with a more “write-heavy” environment that comes in a more social media world. Paul Stamatiou has a good link collection about NoSQL in his write up about a NoSQL conference in Atlanta. (conference recap.)
Let’s get back to FIT2001, eh?
The other big concept in this lecture was that of SECURITY. This includes the obvious like encryption, passwords, (which users hate) etc, but also checking the data. We’ve got:
- integrity controls (ie customer is real person?):
- field combination control (you put “USA” as your country, your post code isn’t going to be a four digit one, but a five digit one),
- value limits (oldest person alive today is just under 115, so age shouldn’t be 300 for a living person)
- completeness (everything there? house number, street, suburb, post code?)
- data validation (is your phone number 8 digits long, not missing digits)
- output integrity
We can also detect things like fraud by looking for patterns. This isn’t error-proof though, as you card can be cancelled if you inadvertently trigger a pattern. My bank always rings me if I book a holiday-related thing such as a flight, hotel, etc, or if I make a lot of online purchases at once, which is nicer than cancelling my card point-blank!
The big hint with security is to think about it at the ANALYSIS PHASE, and to not try and tack it on just before the system is delivered. The other hint is to know enough about security to ask a real professional when you need to.
POD also referred to UML design patterns (such as the 3 layer business model) which are important to know about for the future. I think Clayton (and Sunway) students get to meet design patterns again in Software engineering: architecture and design.
Reports! Reports are a really really important system output and help the managers understand what is happening and keep their business turning over a profit. We’ve got to care about formatting the reports, presenting the data graphically (or not), what data to present, and making the report GOOD. (Security wise these might be printed to a secure printer.) Reporting is where IT gives real tangible value to the organisation, and is an important field.
The tutorial was a bit crazy. I wish I had more of my assignment completed to ask questions about, as it was I was swamped with two other assignments. I wish I had done this as going over my assignment for revision purposes in week 13 was a bit scary, as I couldn’t change anything! I didn’t attempt the tutorial exercises but will probably use them as exam preparation.
I had a good go at getting the multi-choice answers correct based on my existing knowledge, a few terminology questions on reports let me down a bit. EDI (electronic data interchange) was something I didn’t know, it is just the “structured transmission of data.” A little bit of confusion about “completeness control” that I’ll need to be careful of remembering for the exam. Oh and I didn’t guess “smart card” or “access control list” but I know them now.
This was a fun lecture. I liked the video from Apple, crazy to think that the stuff they were dreaming about back then has (kind of) come to reality. This is an area that wasn’t so important to the “sit down and draw a diagram” part of the unit, but it is important information to file away for the future.
I don’t know if this topic is nicer than last week’s topic, or that I forgot to take a proper “stand up and walk around” break between the hours during the first listening of lecture today, or the fact that I had 4 slides per page lecture notes (rather than nicer 1 slide per page lecture notes) for lecture 10, or that the happy-sense of catching up to where I need to be is colouring my view; but I liked this lecture better.
A lot of what is covered in this lecture is also covered in another class I’m taking this semester: FIT3084 Multimedia Programming and the WWW. Check out the lecture notes (not slides, it’s a web based subject) on Human Object Interaction and Human Computer Interaction for some more information on affordances, etc.
Alison’s paraphrase of the lecture:
To the user, the interface IS the system so we need to design it so they don’t think our system is bad. As David Pogue said: Simplicity Sells. (Thanks for showing us that POD. Also recommended is David on the Music Wars.)
We need to care about what the user will Use (physical aspect) see/hear (perceptual aspect) and know (conceptual aspect). The user interface extends beyond the screen and input device, to ergonomic details as well. (I hadn’t realised that the lack of a camera in the iPad could be because the way people hold an iPad most naturally means the camera shoots up your nose!)
HCI, or Human Computer Interaction, has lots of fields that influence it. I thought there was a small dig at Multimedia people “who claim they’re experts in design” which was amusing. I think it interests me because it is a broad field, and I’m a broad kind of person with my literature/language/children/computers/etc interests. Or Double Degree.
Metaphors are very important in User Interface Design, because it will dictate how the system looks and how the system interacts with the user. The main metaphors we use are:
- Direct Manipulation metaphor like Photoshop or visio
- Document metaphor like the World Wide Web and word processing (just wrote an essay on hypertext for Critical Theory)
- Dialogue, where the system talks with the user, such as in installers. “Where do you want to install this?”
Metaphors give us power in design because we don’t have to start at square one in making the interface user friendly, by following standards. (I liked what David Pogue said though- intelligence trumps consistency. If it makes sense to break tradition, then break it.) Users should only need to learn something once and then be able to transfer that knowledge: file-save is an example of this. (Broken by Balsamiq because of a limitation to the medium, perhaps.)
So what are visibility and affordance? Visibility is the concept that you should be able to see all the controls and get feedback that something is happening when you do something with the system. Affordance is designing things so that how to use them is obvious by looking at them. A door with no handle but a metal rectangle instead is clearly for pushing, not pulling, for example. These two concepts sum up the eight principles of design, which are:
- let user know you’re finished (dialogues to yield closure)
- simple error handling
- easy reversal
- user feels in control (internal locus of control)
- reduce short term memory load (label things, group things, keep it simple.)
Similarly, here’s another list of this gelled down into six principles of interface design that I compiled for FIT3084.
Be aware that the user perception of the system differs from the analyst/designer perspective of the system! Don’t scare the users, pick a standard (for fonts, colours, etc) and stick to it. Play with screens, story boards (user flow diagrams), prototypes and UML diagrams (the UML diagrams not so much. Know they exist but pick a cooler way of designing interfaces for your own sanity.)
Be careful with just sketching stuff on paper as you might be designing stuff that’s really hard to implement: an example of this is the FIT3084 multimedia assignment: we designed a slider into our interface, only to find that HTML doesn’t have a slider built in. Using a tool helps limit you to what’s available.
Designing for the web is harder than designing a straight software interface because it takes more effort to implement what you want, there are no standards to follow to keep the user happy, and the tech that you choose isn’t identical across all your user systems. (Designing for the web is fun though, and might be the future?)
I definitely will try and get a copy of “The Design of Every Day Things” by Donald Norman to read, but maybe after the exams are over.
Was a short tutorial, lots of time spent looking at the the assignment 2. We’re focusing on the “attempt quiz” use case. I didn’t look at the exercises at all, but will probably scope them out when I’m working on my assignment.
Lots of stuff I already knew or could guess the answers to.
- The Visual Studio question was a bit specific.
- The formal study of Human factor engineering (ergonomics) started during World War II, so it’s really old!
- The multiple choice choices for the question about the dialogue metaphor are pretty amusing. “c. need for computer-generated characters in movies is so great” ha.
- Repeating information sounds important, but it’s not one of the eight principals of interface design.
- Surprisingly, windows forms don’t use html.
- Dialogue design happens concurrently with design and analysis.
- the open-ended questions threw me, System Interfaces is what we’re talking about next week.
Hooray, caught up with blog, with the lectures, and have made good progress on my homework. Still got three things due next week, but oh well, such is uni life.
So week 10 was a bit of a nightmare, with the Assignment 1b due for FIT2001 kicking things off, followed closely by Project Management 1b and 1c due (thankfully extended from Monday to Thursday) and a large essay due for Critical Theory (extended from Wednesday to Monday) as well as a Girls Brigade camp (horse-riding in Daylesford) that I was going at the weekend! I had to write the essay while on camp (and into the wee hours of the morning as Sunday turned into Monday.) I enjoyed writing in the country air, it was actually kind of fun. To top all that busyness off some inconsiderate soul had ventured into public while infected with a cold (ARGH) and I happened to pick it up. (Seriously people, take one for the team and stay home if you’re sick.)
Hence my blog post (and catching up with the lecture) for this week have been pushed back, and now I have to do double time to catch up.
Thoughts about Lecture
To be honest I wasn’t blown away with the lecture this week, perhaps because I’m not in the routine of listening having skipped a week, or perhaps because it actually wasn’t that exciting. It boiled down to Object Oriented (OO) stuff we’ve covered before and System Sequence Diagrams which we’ll need for the assignment. I suppose the OO stuff would be very exciting if you hadn’t encountered it before, but we’ve been steeped in OO since we walked into the first Computer Science (sorry, Faculty of IT) lecture.
The system sequence diagrams look logical which is good- I’m a bit anxious because POD says we should practice them or they won’t make sense, but hopefully I can squeeze some practice in.
Design is about taking the abstract stuff we made in the analysis phase and turn it something more concrete that we can give to a programmer. This means that the design document will be much more technical than the Functional Requirements Specification.
UML (aka ugly messed up language) uses the same kind of diagram for the class diagram for both the analysis and design phase, with slight variations on how you use it. Use caution when you’re looking up examples that you’re looking at Design examples.
Focus on the Use Cases, take each one on in turn. Packages make the diagram prettier, but have a purpose. We divide out the view layer and the data-access layer from the domain layer, these will probably be implemented separately anyway. In the real world often people just glue interfaces to databases and don’t focus too much on the domain layer.
Well, I was sick, so didn’t make it in.
I know the OO stuff (with just the new wrinkle of Navigation Visibility) which is no big surprise.
POD didn’t refer to guillemets by name, they’re those angle bracket pairs. << >> Easy process of elimination there for the quiz- “I know what all the others are, must be this one!” guillemets indicate << entity >> << control >> << boundary >> << data access >> stereotypes and of course we saw guillemets before with << includes>>.
Lots of UML notation to learn here, which is a bit depressing.
On to the assignment, the other assignment, the other assignment, or the week 11 lecture!
This week I was reminded of the best and worst of university. The best: being inspired and excited by ideas. The Identity 2.0 presentation at the end of POD’s lecture was great. (Claytonites and other non-Caulfielders: you can find all the videos on the Caulfield Resource page in Moodle.) Of course, the worst of university comes with a lot of work and not much time. I neglected my “learning” a little this week, leaving listening to the lecture to when I was tired and grumpy on Saturday night (yes, I have no life. During uni, anyway) and focused on getting my assignment (the first of 8 due in the next 3 weeks) finished. I finished it off, even having some fun with a letterhead and fake signature for my cover letter. Still, working on assignments is not a process I look forward to.
This week is important to know but not to do, which is nice. We might encounter some dinosaurish systems that are based on Structured Design, or we might encounter some dinosaurs as our bosses who think that Structured Design is the best way to design software. In any case, Object Oriented Design appears to have evolved out of Structured Design, so it might be good to start understanding stuff here.
The old: “jargon means you get paid more” theory has resurfaced, with Cohesion, Coupling (misheard as “cuddling” the first few times on the recording), flags, central transform, and afferent and efferent data flow!
The key concepts
Our goal with design is to take the analysis and build software that does what we want it to do in a way that works and works really well. Hopefully the analysts have done a good job and we can use the existing diagrams and reports to build our design documents. The big things we need to do in Structured Design are:
- System Flow Charts
- Structure Charts, and
There are two ways of doing this: Transaction Analysis and Transform Analysis.
In Transaction Analysis, we draw an Automation boundary and work out what transactions are happening- what data is going in and out of the system. (We can also break this down and look at what data is being sent over subsystem boundaries.) A nice thing here is that we can know what interfaces are needed and send them off to dedicated design teams and so divide up the labour (getting things done quickly by doing them in parallel) because we know what data they need to get and display.
In Transform Analysis, we take the diagrams and turn the bubbles into squares. We don’t get paid much for saying that, so we call it the CENTRAL TRANSFORM (cue booming voice, thunder roll). Basically we take a high level DFD (not the context diagram, DFD level 0) and turn it into a design diagram.
Modules = procedures = functions, it just depends on what you learnt and who taught you. These are the squares with names in them in the diagram. While we’re talking about modules, let’s talk about cohesion and coupling. We want low coupling and high cohesion. Coupling means when modules rely on each other, so if you change one module it affects the other. This can lead to nasty and unforeseen consequences when you make changes, so it’s a good idea that the modules are as lowly coupled as possible. Cohesion is talking about internal cohesion, not the cohesion between objects. Basically it means that we want each module to focus on one thing and only one thing, and be solely responsible for that thing. Low coupling, high cohesion. (Think school camps- we had a policy on school camps of “joyful glances only” – it was a conservative school. Low coupling. High cohesion- everyone responsible for their own selves but getting along nicely.)
On the cohesion note, I’ve heard some coding style guides suggest that methods should be a screenful size, to help with understandability and also the “just one thing” idea.
Control flags are variables that are booleans. (0 or 1, true or false) lots of them can indicate poor quality code, but they can be useful.
While analysis carefully separates out the different data stores needed, the Designer can simply things by lumping them all in a database. It’s good to have modules that deal only with handling the SQL. Colour coding is good to indicate the 3 Layers. When writing pseudocode try and think what language you’re going to use to implement this so that you don’t make life hard on yourself. Write pseudo-java, pseudo-lisp, pseudo-C, pseudo-PHP, etc, so that you can easily convert it into real code when the time comes.
I found this week’s tutorial really interesting, not that we looked at the actual tutorial all that much- I guess we’ll have to catch that up as we’ll be using it for our assignments. It was good looking around the room and seeing everyone working on their assignments, seeing some diagrams like mine, and others that weren’t. I find the questions that others ask really useful to my own thinking. I also really really appreciate the dedication of my tutor who had a Clayton consultation and also helped me out with my understanding in the tutorials- it was good to say “is this what we’re supposed to do” especially because Visual Paradigm doesn’t have 100% matching with the names of the diagrams. Having a two phase process of asking what I needed to do and then checking I had got it right was important. I put a lot of effort into a high level DFD and had to cut it right back for the context diagram: but I’ve held on to the high level diagram and hopefully I’ll be able to use it in my second assignment. Fingers crossed that things don’t get changed totally for OO Design. I’m pretty happy with my assignment, just have to wait two weeks until I get my marks! However hopefully I’ll get some good feedback from my tutor before then.
The quiz showed that this week is all about vocabulary, as it caused me to stumble a bit. I think I’ve covered everything that threw me in in the lecture and reflection, so I’m pretty happy to leave this until revision time. These are the words that I didn’t know:
- central transform
- control couple flag
- module cohesion (means internal cohesion)
- afferent data flow
- efferent data flow
- data couple (example: global variable)
The great Moodle Incident!
It all started with an unhappy student who missed the simple left hand navigation bar. A complaint on twitter made me start to notice. A forum post about the South African weather meant that POD posted a quick screen cast on how to minimise campus information. Bingo- our screens were different. Clayton students didn’t have a quick navigation tab system, just a long plain page of html. Screenshots, twitter comments and a bug-fixing POD all helped to get us our tabs. Why didn’t we complain in week 1? I found the site usable, a sight better than Blackboard, and didn’t know there was anything missing. I’m guessing the frustration with an interface builds when you are actually trying to use it for something important: in this case, Assignments. I guess a screenshot of what Moodle should look like would have helped test the system more extensively (Clayton students missed out, but all staff and Caulfield students had the tabs, but no one knew there was anything wrong.)
This blog post complete, I’ve now caught up to my usual schedule. Three big assignments still due next week (one is really a two-part assignment because both are due at the same time) and an icky essay that still needs to be tackled (involving an expedition to the library (Matheson) to hear the hum of the books!) so I won’t be devoting too many brain cycles to FIT2001 until next week. Thoughts with all the people still cranking away at their assignments, if you’re procrastinating by reading this post: get back to work!
Still reading? Well, being born only a few years before Dilbert was started, we haven’t had a chance to enjoy some of the earlier strips. The dinosaur image in this blog post is actually Bob the Dinosaur, who wasn’t extinct, he was hiding in Dilbert’s house. Start here at 17th of July 1989, and read about the next 7 to 10 comics. Be warned though, Dilbert is very addictive. Maybe finish off that assignment first.
Well, the main thing I’m working on this week is the Assignment 1b Functional Specification Report. I’m glad the things I learned in ENH1260 Introduction to Professional Writing and FIT2043 Technical Documentation for Software Engineers are coming back to me, so I’m pretty happy that I can format my report and make it look business-y. Unfortunately I last took FIT2010 Databases FIT2008 Networks in 2007, so I’m going to need to brush up on the Diagrams for the Assignment and Terminology for the Design lecture! I’m still struggling with converting my event table into a Use Case diagram, so I just have to do the other diagrams and then ask lots of questions in the next tutorial. It just feels bad and wrong every time I attempt it, so I’m a bit discouraged there. Anyway, on with this week’s topic.
Good design involves creativity. While you can just put in tech solutions with the goal of meeting the Acceptance Test document, that isn’t really design. Design is a creative process where the designer (perhaps the Information Architect) makes IT solve problems in really efficient and useful ways, to inspire the business to use IT to add value, not just as a problem solver.
So let’s think “Blue Prints” so the designer can tell the programmer (either another person or their own future-self) how to build the system. Design works at both high-level and low-level. Of course, while Analysis works out what the system should do, Design looks at how the system should do it. There are three big areas that System Design focuses on: Network, Software and Database, which are inter-related.
The main points of the lecture were: Networking (enough to talk to the networking specialist) Application Architecture, User Interface (muck it up and the users will hate your system), System to System Interfaces. Database is a big deal, because a system is basically a Database with a graphical front end.
Security: besides passwords and encryption, also include Audit trail and logs.
Client Server Architecture is important. Having multiple servers lets us separate the different components of the system out.
3 Tier Architecture
- View Layer: user interfaces, etc
- Business logic layer: applies all the business rules, contains programs that do this
- Data Layer: interacts with Database.
Middleware is the glue that holds the layers together and lets the different software objects in the layers talk to each other.
This week I didn’t do well on the quiz: showing there is some specific knowledge to pick up here, rather than apply existing knowledge to new problems.
I managed to guess the answers involving stuff I already knew, such as LAN, distributed architecture, cluster, intranet, extranet, database relating to the Data Layer as well as the questions about the Analysis phase.
However, this is the stuff that I missed:
- Project Schedule: important to co-ordinate activities
- CASE Tool: used to record and track project information (used in a lot of places)
- System boundary: identifies what is in and out of the system (automated and manual processes)
- User Interface: (I think I went general and said system) first thing: think of user dialogue with system, inputs and outputs.
- Network Controls: obviously control the network, protecting communication
- System Interface Controls: make sure other systems don’t harm the system.
- Application Controls: make sure that transactions and other system work is recorded correctly.
These were all Free form answer questions, and I think I could have improved my score by reading the question more carefully, or if I had been asked to define each of these rather than guess the word that matches the definition.
- Design Phase = breaking complex components into smaller, understandable components (ie, top down.)
- When designing prototypes, ask: “Have we specified in detail how we can be sure that:
- the system operates correctly and
- the data maintained by the system are safe and secure?”
The most memorable thing from the Tutorial? “What is the internet?”
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.
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 shows me what I knew before I learned it, this is what I didn’t know.
- A Turnkey System is one you get from a vendor and just “turn the key” ie switch it on and start using it.
- facilities management contracts are very expensive apparently.
- ERP is another word for Turn Key
- A Request for Proposal is so we can buy another company’s services for the product after we’ve worked out what kind of product we want/need.
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.