Buffini's Blog

Development models:

The text starts off with a description of the older style waterfall development model, quickly details its disadvantages (rigidity, unable to cope with changing requirements, assumes all design is nailed down from the start), and moves on to newer and much more useful models.

Incremental and iterative models are given as examples of more appropriate implementations. These models have the distinct advantage of being able to cope with changing requirements – in these models, feedback is provided constantly through the use of prototypes, whereby users can review the current work, alter their requirements to fit new criteria, and then proceed onwards with new ones.  It introduces the concept of risk management – if some of your biggest risks are changing requirements, then it makes sense to find a way to manage these, by reviewing and updating the requirements and expectations at frequent intervals.

There are various ways to implement these models – timeboxing (define a set time in which to complete a subset of requirements), prioritising (where requirements are prioritised and implemented in order), and others. For any project planner will need to decide which planning model is appropriate for their work.

The Unified Process is one of these. It advocates short time-boxed iterations – the advantage here is that a lot of functionality can be prioritised, implemented and reviewed in a short time, but it can also leave you open to time constraints if there are unforeseen difficulties with the work planned. A UP project has 4 phases – inception, elaboration, construction and transition. The correct use of these phases is what makes the UP a powerful tool.

Modelling and UML:

Next the problem needs to be modelled. The concepts of domain, specification and design modelling need to be discussed. Domain involves understanding the situation/problem we are trying to solve. Specification involves describing a system to solve the problem. Design is the low-level implementation of that system. One of the biggest advantages of modelling a system is the ability to use a defined language or process to lay out the design in precise notation. One such notation is UML. It allows a designer to specify the various levels of interaction within a system, such as classes, models, functions, etc… and all of the connections and dependencies between them.

Object-Oriented Development:

The concept of OO development was a natural outgrowth of the search for a better development model. On the surface it seems deceptively simple, create a system of interacting objects utilising tight cohesion and low coupling. It gives the developer an enormous amount of power though – you can use this simple idea to model alsmot anything you would come into contact with. Take the example of a car. A vehicle has X no. of wheels and an engine. It is your base object. A car then is an extension of this concept, being a more concrete example of a real world use case. A truck is another. Both of these inherit they’re base attributes from the base object. These objects have other attributes that they encapsulate, and can be interacted with, and can in turn interact with other objects.

This OO paradigm is the natural successor to functional programming. Functional programming would get the job done in most cases, but would not supply the power and simplicity required for large scale systems. For enterprise design this would have been essential. Extrapolating further from the concept of objects you now have whole hierarchy trees of branching, related objects, and looking a further level out you see that you can have networks of unrelated but still interacting objects. Communication across systems spanning various protocol levels are now much easier to envisage.

I won’t go into detail on the basics of how to explain, create and use samples of objects, other wiser heads have done a far better job than I could. Suffice it to say that by using this implementation you can achieve powerful results, particularly when aligned with object modelling, which can give you almost a 1-1 correlation from design to implementation, effectively speccing out the entire system from the very beginning.

Software Reuse:

Let’s say you’re tired of having to rewrite your software from scratch every time you need to use it. Perfectly understandable, nobody wants to do that. It has long been an unfulfilled promise of the software engineering discipline to provide frameworks of readily available software modules that can be clicked together in any configuration to build the required system. This has never really been delivered. A core ideal of software design is local reuse. This is great within the design of a single system, as it allows code reuse within a system to achieve a high degree, and encourages developers to correctly consider all of the design needs ahead of time.

But up until now this hasn’t really been applied from a larger scale perspective. Say you’ve designed this lovely system where not a single line of code is duplicated, nothing is unused, cohesion is high and coupling is low. Great. But it doesn’t click in as a module for larger products. Or you can’t break the constituents down easily into a bunch of plug and play components.. This is the long sought after reuse that has been promised but not delivered.  The idea of the product line comes in here – a set of base line objects that can be combined into any configuration such that the final system produced completely satisfies all of the user’s requirements. Hey presto, you have your Grail.

One way of achieving this reuse are design patterns – design patterns are open solutions to common problems: take for instance the Singleton pattern (there can be only one…) the Singleton is a pattern which defines a component such that there can only ever be one of it in existence at any time. This can be extremely useful for things like persisting system state and so on.. There are dozens of them out there, exceedingly powerful, and well worth consideration.

CASE Tools:

A CASE tool (Computer Assissted Software Engineering) is one created to assisst in the design of middle to large scale systems, or even small ones if you really feel the need. What it allows you to do is express your design in a modelling language in a structured way. There are a wide number of such tools available, some of them very expensive and useful, though the first does not neccessarily imply the second. Tools such as Rational Rose would be a good example of a CASE tool. Some of them allow for a creation of a model from first principles right through to the barebones implementation of the system itself, with just the code implementation details to be filled in after. However most of them are not quite that good yet, so some coding skills are still required

Related articles by Zemanta

• Interesting Resources to learn Object Oriented Design (woork.blogspot.com)
• Real Ultimate Programming Power (codinghorror.com)
• Model Driven Architecture: Feasibility or Fallacy? (tc.eserver.org)
• Back to Basics: Interfaces (codebetter.com)
• The Building Blocks Of Modularity (slideshare.net)

1. Decisions concerning software need to be regulated in areas affecting people and the environment

This is true of any area, but is only being properly adopted now. The example given of the Therac radiation machine is good, and serves to drive the point home. As engineers we can, and do, create products that can ave lasting effects on peoples lives. Embedded software for pacemakers, flight control software, nuclear reactor control systems, all of these things have an immediate and lasting impact, so regulation would be no small thing. Would you want your doctor practising on you after 2 years tinkering on the family gerbils?

2. Situations should be analysed ethically from first principles of moral philosophy

This is a sightly tricky one – as the text mentions moral philosophy has been hotly debated as long as man could bang two rocks together, and no definitive answer has ever emerged, nor, I personally believe, will it ever. With changing society, etc.. , how can one set of moral codes define behaviour for all time?

Leaving that aside, first principle analysis using some system, whether it be utilitarian or deontological, does at least provide some reference or framework to go on. Work out the implications, cost/benefits, for the fair treatment of all parties.

3. Sets of rules can be applied instead whenever pre-analysed situations arise

Fairly intuitive statement here. Applies to damn near anything really… The ground they’re attempting to cover is that canned responses can be used to apply to certain situations, i.e what to do if a safety critical app develops a major bug or something similar. The idea is to get across the point that there will be some form of backup I think…

4. Professional societies provide  set of rules as codes of conduct

Essentially correct. Every professional body that has ever existed (might be stretching things a bit here..) has had some set of laws that determine their actions, for both their benefit and their clients. They serve to protect everyone involved in the transaction, much like a social contract, and members must perform to the standard of these rules to gain admission and to safeguard their clients, and them, in return from the clients also.

5. Professioal societies support software practices through events and activities that share d promulgate best practices

An emergent property of the professional body or society is the code of conduct. A set of rules grows to become a code of conduct, a set of instructions for the member and org to work by. This is a fantastic development as it lays down the expected conduct of the member by the organisation, but where a lot of places fall down is enforcement. A code of conduct is absolutely no use if it is not verified and proven to be in use at any given time. For doctors, lawyers, etc… they can and will be dismissed from the professional group for lack of adherement to these codes, but there is currently no such failsafe for software developers, and there will be definitely be a need for one in the very near future.

6. Standards for software provide extra guidance, with ISO being increasingly important

Harping back to the last point – this is a step along the right road but not really far enough. An organisation can lose its ISO certification for lack of adherence to practices and guidelines, but thats about it.. They can still trade away happily without it, and quite likely retain a lot of their customer base. Some form of negative reinforcement for non-adherence will be required.

7. Process standards can be bureaucratic, displaying their military origins

I’d probably argue the point here about military implying bureaucracy, but lets continue. Oriinally this would have been true, as a lot of standards work would have come out of the military, being an area where quality was important. However, with growth and emergence of new memes such as agile processes, the bureaucratic emphasis fall away to leave a more process-centric process, odd as that may sound.

8. Internationally approved technical standards should be consulted and used in procurement and

development work

This is really just an extension of what went before – the implication that professional bodies exist coupled with codes of conduct and standards means that these should now be adopted internationally also. Not doing so, considering the global status of many of todays major suppliers, is braindead.

9. Overall processes can be certified that they comply with the relevant standards

Once both the process and the standard are sufficiently then yes I’d agree with this. The problem is that there is potential for fluffiness, vague generality creeping in here and there, interpretation of meanings and so on, which will essentially render you standards and the ceritification related to it meaningless.

Related articles by Zemanta

• Are You Agile? (feld.com)
• Combining agile development with customer development (startuplessonslearned.blogspot.com)
• The App Economy (bbc.co.uk)
• The Core Skills All Software Developers Need (basilv.com)

1. Legacy software is essential software that cannot be changed at the speed which the user organisation requires

From a management perspective this is true. From a developer perspective this is largely false. The developer will know that there are often times when you can develop system updates, new architectures, etc.. at a speed that will largely satisfy most people. The problem arises with the users/market. The market will not be ready for the latest and greatest a company has to offer in the beginning, and frequently this will continue until a certain software maturity has been reached. The cost and risk factors also play large roles here. Spending, when weighed up, contrasted with all of the relevant factors and so on, will usually fall back to “If it ain’t broke….”. It frequently just isn’t cost/risk effective to update to the cutting edge, when the investment for the dull hammer has already been made and still works just fine.

2. Unless work is applied to counteract the appearance of legacy symptoms, any business-critical software is likely to become a legacy system sooner or later

Basically this statement boils down to two items: it can be maintained, or it can be evolved. Maintenance will involve fixing little bits and pieces, keeping things ticking over. Evolution will take the existing processes, tacit or otherwise, and create a newer, leaner, meaner and keener beast out of it. Its the football equivalent of keeping a team chugging along with the same players because they get along ok, and nothings reeeeeeally broken… whereas evolving the tem with new players, new trining methods, new coach, etc… will make it a world class competitor.Wrapping legacy systems, acquiring FOSS, modular development; all of these things are good and will, but its down to corporate mentality as well.. willingness to change and evolve will be core here..

3. Wrapping legacy software and it’s integration with newer software should be considered when replacement is too risky or too expensive

I’d agree and disagree here. Yes, wrapping should be considered if absolutely necessary, but NOT at the risk of compromising the system – from my point of view this would mean not wrapping if there is a reasonable justification for re-engineering the system/process/whatever, extracting all of the lessons learned from the current implementation. There should be some sort of bias in the judging system towards a new implementation, obviously backward compatible with the old junk, but this should nearly always be the best option. Preserving the old stuff for the sake of it or for penny pinching, etc, is just wrong.

4. In COTS-based projects the requirements are limited, shaped and conditioned to what the COTS vendors can offer

5. Component-based development provides value through cost efficiencies and trhough the emergent properties of the integrated applications

6. There are still limitations to the wide use of components, including issues of reliability, risk, trust and lack of support for the future evolution of the component

7. Successful open source acquisition and deployment requires tapping into other diverse sources for support and this requires a more diverse approach than when depending on a single supplier

8. Acquisition of open source software can be primarily motivated by a cost reduction strategy and not by the availability of the source code

9. Outsourcing beefits from a number of economic and technical efficiencies. However, this option may lead to a client’s loss of control over the software

10. Advances in methods and process capability of software organisations expand the types of software activities that can offshored

11. Instead of owning or licensing the software to run on your machines, you can rent time using it at some service provider

12. Software acquisition as a service (e.g. web services) requires adequate resolution of issues of responsibility, trust, risk and security

13. Software provision does not end with the selection of a source and the acquisition of the software and its documentation

14. Software acqusition consequences go beyond the immediate decision: they may have far-reaching impact

Summary Points – The itemised summary of Section 1 given in the course material. What I will do is list the summary points here and give a brief analysis, interpretation and example of same. I plan to do this for each section in the course, so a reasonable overview of the material will be produced.

1. Software may not have brought about the economic benefits nationally that we could have anticipated

One of the understatements of the century, no matter what perspective you look at it from. Software is generally touted as the all-singing all-dancing answer to all of life’s prayers, but frequently falls short of user/stakeholder expectations.  Coming from a developer’s point of view I can easily understand this. I know how my software works, the limitations and capabilities, technical caveats and so on, but a non technical person could have real trouble. “Why doesn’t it do this?”. “Because of XXXXXX”. “… Thats a bit rubbish isn’t it..?”.

An example given is of productivity vs investment in IT over time. Studies by Landauer and others show that there was a marked drop in productivity as more and more investment in IT rolled out, but doesn’t really give much more on it than that. One thing we can infer here is that if we can make the graph go the other way, i.e. productivity rising, then we can safely assume that correct methods of software design, production, and equally as importantly use, have set in.

2. Software can fail in service often with disastrous results

Also very true. In service here meaning any production environment. If software is not correctly designed, requirements not properly and systematically elicited, if production is sloppy, testing non-existant, and without input from all relevant stakeholders, then failure is assured.This is a no-brainer. It will happen, no ifs buts or maybes.

The example given is of the Therac Radiation machines, but I prefer this one: The great Zune fiasco of 2008. Whereby someone in Microsoft had coded a specialised calendar check into the Zune software, and basically forgot about the existence of such things as leap years. In this case I’m not (solely) blaming the coder, that snippet should have been reviewed ten ways form Sunday, especially considering there’s already a trolley load of date and time functions out there.

3. Software is important in the automation of clerical functions, justified by the saving of labour costs and the increased accuracy and reliability of results

No, really? Software is not important, its critical. Not just for the automation of tasks, but for the error checking that comes with this. One tired and bored clerical officer can do the same process for the same set of files 4/5 times and come out with different answers each time. Machines don’t have this problem. If the software is told how to do it right the first time, then it will do it right the first time, and the second, and the third…

Its not so much that the cost of is justified, more that is essential..

4. Software offers new opportunities for enterprises to deliver their services and products more effectively and more efficiently, and even create new products and services

This is true – in the modern world the average business or even home cottage industry type person can get themselves online and trading away with world wide exposure for about €100. And that includes the costs of the web hosting. Without the services built on software, they wouldn’t be of particular use, but them they are invaluable.

5. Stability cannot be relied upon – change is always with us, but has become more intense the advance of technology and the globalisation that accompanies it

This is a good thing rather than anything else – the more the market/industry/scene/whatever changes, the more we will see new and innovative ways of creating and using software, often in ways never dreamed of before. Software, automation, call it what you will, it has busted its way on to the scene and has now taken complete control. It is at the core of every business (or should be), and the world economy would collapse without it.

6. Rational and scientific approaches to developing software have their limits, limits that are matched in other areas of human activity and marked as postmodern

I consider this a bit of a contentious one – there is always a lot to be said for the human approach, etc, but at the end of the day it should still all boild down to a rational approach to your process. If your methods or results can’t be analysed in some way (and I’m including as yet uncovered methods of analysis here..) then I would think that it probably isn’t all that effective. I’m not a big believer in the “limited” idea.

Decided to sign up to NaNoWriMo, a novel writing competition type thing. Its an interesting idea, and something I’ve wanted to do for a long time. Basically the idea is to produce a 50K work in one month, November, without editing, rewriting etc., just get the words out.

Should be fun and extremely painful, specially considering thats the month I start my Masters as well. Ah well, they say the best thing to do is pile on the work, helps motivate you to get going at it. also, posting my intention publicly is an added incentive to actually write the damned thing, as terrible embarrassment would ensue otherwise…

Thinking of a fantasy type thing, because I have this strange idea that it would be easier than writing a Sci-Fi novel. It will be fun coming up with the ideas and plots anyway. Blogger has very nicely provided me with links to various book writing tools I see… Fun…