INF417/INF450

We are aware what is the same and what is different between these two modules in how it is presented and its content.

The question is: What do you say? How do you perceive it? What is relevant and what is not? If you are in practice, which one adds more value? I want to hear what you say.

INF450, which I did last year, was a good overview of systems development frameworks. My feeling though is that unless you are starting greenfields in a company with a lifecycle methodology it is of limited pratical use as you generally have to conform to the existing framework and there is rarely much scope for including alternate systems development approaches. INF417, on the other hand deals directly with the way that solutions are built and this can differ on a per project basis as there is a lot more scope for trying different approaches at the project level. If you are thinking of dropping one, I would say that 417 is of more immediate pratical use in the workplace. Depends on what your motivations are though.

My R0.02

They are both ok eventhough they overlap in certain areas.I find them valuable at work.

Of more importance imho is "if you drop one, what should it be replaced with?"

If I can vote (and I suppose I can!), it would be for something between 450 and 482. 482 is high level software specification techniques in a formal manner - but I think there is scope for another module dealing with technical writing / structured english. Something allowing developers to communicate with clients.
Architects and civil engineers use models, IT can only rely on either prototypes or in detailed, easy to read, concise, clear, informative, non-ambigous documentation.
This latter is needed in our discipline.

Yes, something about writing proper technical documentation would be useful, especially SAD's

Hi Mac,

I am a big critic of this entire Hons degree level. I see very little advantage having this qualification. Supposing Hons Bachelors and Bachelors [undergraduate] get integrated for the sake of best value for students. We are in the age where integration has become a driving force in all undertakings. Phasing out Hons and introducing a better 4 years undegraduate degree program could yield better value.

Anyhow, INF417 and INF450 are no different from each other. However, I find INF450P being more of a subset. I suppose the whole intention was to have students get a detailed understanding of metholodies, tools and techniques used in software engineering. But the prescribed textbook for INF450 isn't well structured to advise students in an appropriate sense of it. Maybe finding another textbook could make INF450 more sensible.
INF417 is more practical as addressed by the author of the prescribed textbook. I get much understanding of INF417 when consulting the prescribed book for INF305(software engineering). The author indeed explains the concepts of software engineering much better with lots of practical experiences that are vital when learning a subject. I suggest the two modules get integrated but I would favor retention of INF417.

Regards

Thanks so far all who responded. Interesting thoughts.

Software engineering is a complex and challenging undertaking. Teaching software engineering is even more complex and challenging. There are many terms and concepts, and it is easy to reduce a software engineering course to a course in engineering terms and concepts.

What is clear to me is that software engineering education is generally unable to put such concepts into practice in industry – specifically when it is a large-scale development project. The question for me becomes a matter of what must students be taught to enable them to both retain the information and empower them to apply it in industry?

In my opinion, a common problem in industry today is the believe that software engineering reduces to the generation of paperwork, rather than presenting a process of analysis and modeling. The essence of modeling and analysis is crucial to creating well-structured and useful software. It is therefore critical to teach modeling objectives and how information flow from one model to another until sufficient detail is generated to produce the source code.

One aspect to consider when comparing INF450 and INF417 would be to realise the differences between these two modules based on the perspective views on software engineering provided by each. How can “perspective views” be used to do that? To answer this, consider for a moment the SDLC and more specifically, one possible goal of the analysis phase for a typical development project. The goal may be to acquire sufficient knowledge about a software system to allow the development thereof to evolve in a disciplined way. How can this knowledge be acquired? There can be many ways in which to do this. This is where the viewing of the problem from a different perspective comes to the rescue. In my opinion both INF417 and INF450 aim to establish those foundational principles with the student. The authors of the prescribed textbook for INF450 discuss software engineering from an almost philosophical view based on their definitions and understanding of terms such as:
• Themes
• Techniques
• Methodologies

This view differs from the approach taken by Schach, where – again in my opinion – he addresses software engineering more from a "quantitative" approach, explaining for example the different forms of cohesion and coupling that may be encountered. In either case (i.e. INF450 an INF417) the approach to teaching software engineering is different. It is differences like this that adds value to the make-up of the software engineer. For me, personally, the course content was one of the key considerations to enroll as a student at UNISA rather than at any one of the other universities in Gauteng.

I agree that there are both similarities and – in some cases – subtle differences – between the content of INF450 and INF417, but one way to treat those differences and subtleties is to allow the students to explore it for themselves. Surely, this is what is required at post-graduate level? If a student does not learn to do that while studying, how will such issues be solved once they are confronted by development issues in industry?

UNISA provides a sufficiently well-stocked library and easy online access to academic material. In most cases, the authors of the prescribed text books (for the two courses considered here) supply comprehensive references to the original publications covering a specific topic. In my experience, accessing those original publications through the UNISA library facility is very easy and therefore allows students to address their uncertainties for themselves. That is, if the differences between the two modules is really relevant and important. I don’t think so. What I do value a whole lot more is the knowledge that both modules provide to me, the student, through their different perspective views on software engineering. Is this knowledge which I am referring to really that important, you may ask? Let me answer this with a case in point: I have yet to see students straight out of university (and in most cases – experienced practicing software developers) that appreciate the difference between properly architectured software and the Visual Basic style of rapid programming which served to turn software development on its head. Architecture and design certainly is not built around a user-interface that is literally “developed” in minutes.

Should the two modules be merged or one of them dropped in favour of the other? No, I don’t think so. Each module will add a different layer to the knowledge of the software engineer. Let the students resolve the differences between INF450 and INF417 for themselves. If they cannot do that, then perhaps the lecturers can provide some guidance on solving such issues. Perhaps, one way to address the solving of such issues is to put up a special assignment question where the student must address the differences and similarities between the two modules.

I think that removing an obstacle (such as the perceived overlap and/or differences between INF450 and INF417) simply because it provides some unwanted hindrance which can be easily resolved, is not correct. A professional software engineer that learns to solve conflicts by discarding one of the presented options, rather than attempting to understand its impact and appreciate the potentially different view it may present on the problem at hand, will experience difficulty developing industrial strength software systems out there in the trenches where project schedules and customer satisfaction dictate.

Good response You are correct in that we want students to explore it for themselves - that is what postgrad is all about. Form and defend opinions (with current research where possible). The question that remains: are two different perspectives justified in a course schedule that perhaps needs to be streamlined? Perspectives that are lost when discarding one can be corrected with a more pertinent focus on current research articles and movements? E.g. google for the SEMAT vision.

Quote

accessing those original publications through the UNISA library facility is very easy and therefore allows students to address their uncertainties for themselves

I could not agree more. The library is crucial to success, especially if one aims for high marks and not just a pass.
I plan to go through relevant articles from the texts once I have completed the text book.


Mac, I do not think the course work needs to be streamlined - we should not be looking at "making things easier". If something needs to be dropped, it should be replaced by at least something of equal value.

I, for one, would have taken a course in PM from an HR or psychology perspective. We are constantly told that PM is mostly people skills of one or other sort, but INF425 only spends a chapter or two on the psychology behind it - and this is a fascinating aspect.

Streamlined not as in easier - but as in getting rid of "duplication" but more importantly, getting in line with what is relevant, topical and industry-related.

These are just ideas thrown into the pot to stimulate debate:

Is it possible in an IT stream to do that (streamline)? Also, is it the right idea? Let us examine those two ideas quick:

If we look at the texts we have, they are fairly old (in IT years). Schach is mired in the past in terms of his philosophy and weltanschauung. Yet, despite this, his work is relevant in other areas. We need to know what does not work so that we can either avoid it, or deal with the issues having prevented it from working. Particularly if the "point" of Hons is to provide a platform for Masters and beyond. We (the students) need the platform of what has come before.

Secondly, the ability to learn far outweighs what has been learned. To put this more clearly, I would rather hire someone with a demonstrated desire and ability to learn, than someone who "knows it all" and "does not see the value in learning". Even if UNISA taught "current ideas", and could keep pace (no more text books, just a subscription to ACM!!), by the time the first year has passed post graduation, those ideas will be "old". We are not accountants with a fairly stable BOK, IT changes hourly (quite literally).
How do we develop for the cloud across cultural barriers with different HCI target groups?
Who are our users?
What roles does prototyping play now?
Is it evolutionary? Throw away?
How do we even begin to develop a multi-cultural UI for a cloud computing app - the issues of icons representation (google: culture ui for more than enough to keep you going!), display sizes (netbook vs notebook vs lcd vs crt), user impairments (inf420 as a start) and language orientation (left to right, right to left, up>down, and so on).

All of these issues are barely touched on in requirements elicitation and prototyping in either 417 or 450. Yet Schach makes a huge deal about it. How does this compare to what we "need to do" in today's world.

Even just with desktop applications in SA, we have many of those issues - there was an exploratory article from a Durban uni on using cultural specific icons like the calabash instead of "office icons" like a floppy disk. I will try and find it later. OpenOffice has spell checkers for African languages - again these are ideas we need to explore in Requirements Elicitation and analysis and design - but not ideas touched on by authors writing text books for "first world" countries with "homogenous language".


What do the other disciplines do? Ones like "Pharmacy" where the BOK also adapts at lightning pace? *Maybe* IT needs a 2 year compulsory "refresher" course to keep the degree relevant .