COMP3530 Learning Portfolio

Welcome to Damien Beard’s Learning Portfolio page.  This portfolio will be updated each week, with the intention being that it draws upon the readings, Panels and Workshops to create a cohesive analysis and reflection for each week’s topic.
This Learning Portfolio will also contain videos I have created, which will be based on the topic presented in that week. The videos will go for a few minutes each, with the intention being that the videos contain my initial, raw attitude to the topic, and the written reflection will summarise, build upon and source references form the video.

• I would like to be exposed to an array of different software engineering projects and products, in order to see the types of areas I could be working in once I finish my degree;
• I would like to get to expand my perspective on where software fits into the world, and get a deeper understanding on how software engages with the system as a whole;
• I’d like to expand my understanding of systems engineering in order to make myself more employable when I am looking for employment post-graduation;
• And I would like to obtain a high grade in this course

This week in the course it has been emphasized, through the readings, talk from Lawrence Cram and the discussion in the Workshop that firstly, Software Engineering is concerned with people, and secondly, software exists in a complex and dynamic environment, and should be treated as such. Both of these ideas seem intuitively true, the former simply through our previous experience at university (working in teams, getting graded by tutors and lecturers etc.) and the latter through my own experience with software (whether it be on my personal computer, software on a cash register or even on a server at work). I’m looking forward to being exposed to more examples of these points throughout the course (and all of my courses for that matter).
Finally, in the video I introduce an example of when Software was blamed for the death of eight (though possibly up to 18 (Borras 2006, p. 173)) people in Panama City due to exposure to large doses of radiation at the National Cancer Institute. The physicians made unauthorised changes to the software (Garfinkel, 2005), which in turn caused the deaths, however at the time, the original software itself was blamed for the extreme amounts of radiation given. It was found that the physicians were supposed to manually check the amount of radiation given to the patients, and they didn’t, so now they are standing trial for second-degree murder (McCormick, 2004).

References 

This week looked at modelling, endogenous systems vs exogenous systems and Systems Thinking. I have covered the first two points in the video, and a review of Systems Thinking in the blog section below. Below I take a look at Analytical thinking vs Systems thinking, provide an example of a recent problem I encountered which (eventually) involved systems thinking, and the context in which Systems Thinking is used.

Analytical thinking seems to me to be the inverse of Systems thinking. Systems thinking is about seeing a collection of components (be it a computer, some cabling, perhaps a software application) and seeing it as a system (like a network), and seeing how that system fits inside of an even bigger system, and so on. On the other hand, analytical thinking seems to be about separating a system into its separate components, viewing each part essentially in isolation. From these perspectives, you can understand how one seems like the inverse of the other.

A problem I’ve had to deal with recently was my car (Charade, 1993, also known as ‘Shirley’) being broken into (it happened last Saturday night). Both the driver side and the passenger side locks were damaged so badly that my key wouldn’t fit in either of them anymore. Originally my first approach was to unlock the boot of my car (it’s a hatchback), and lean in and unlock the car from the back door. The problem with this was that I was constantly getting my work clothes dirty (from my dusty car), and in the rain, it was totally inefficient, I would get wet because it took me 45 seconds to get into my car once I arrived to it. After a couple of days I got fed up (I am getting the locks replaced by the way), and decided that instead of working against the boot (and climbing over it every time I had to get into the car), I’d use it to my advantage. So I tied a piece of string around the back lock, up through the coat hanger, and put a weight on the end which I put into my boot. Now, until my locks get repaired and installed, I simply pull on the string, and my car unlocks.
I initially started off with an analytical approach, assessing what the goal was (to unlock the door), and how to achieve it (by physically pulling the lock up). It wasn’t until I started viewing the car as a system in itself that I realised that my goal was not to unlock the door, but to get into the car. This mind shift was enough to get me thinking about how I could work with the car to make it happen. So over the course of this problem my thinking from an analytical approach, to a much more systems thinking approach, which ultimately gave me a much more feasible workaround.

As for systems thinking in general, to me it looks like systems thinking isn’t just the way we’ll be looking at this course, but we’ll need to start looking at all aspects of our academic and professional lives if we want to succeed (particularly the Software Project, COMP3500). We need to look at the question ‘How and why does this fit into the larger system?’ A software engineer who can look at a situation this way I think will not only be a better engineer, but also a better manager (which is a position I would like to hold later on in life).

References 

This week Systems Engineering was covered, in both a broad sense, and by breaking down the stages involved in the different methodologies of Systems Engineering. When looking at the lifecycles, I immediately (as I’m sure most people did) recognised them as being virtually identical to the various Software lifecycles we have covered throughout our whole degree (we’ve covered them in one form or another in COMP1510, COMP2500, COMP2130 and COMP3120).
Typically the Software Lifecycle has looked at each stage in quite a modular way. So when we were doing testing and verification stage, we would be doing that testing to make sure implementation stage had been completed successfully. This makes sense to me, because that is what we do as software engineers- we take a problem, we break it down recursively until we have bite size manageable pieces that we can understand it, modularise it, stick it into a function, and call it when we need it.
Systems Engineering on the other hand seems to be less concerned with the stages themselves, and more concerned with why they are completing that activity. For example, take Testing again. The Systems Engineering approach to Testing is that you are doing the testing, not simply to check that the implementation was successful, but to make sure that the system fits in with the wider environment, serves its purpose, and satisfies the client’s request.
The techniques are the essentially same, for example, take the Spiral Method. The model Spiral Model for Systems Engineering Derek presented us is above on the left, while a Spiral Model for Software Development provided by IBM is below on the right, and as it can be seen, there is a lot of crossover. It is the mentality and purpose behind that seems to be different, and from what I can tell, a Software Engineer who can modularise the steps without losing sight of the bigger Systems picture is going to be very valuable to anyone who wants to employ them.

References 

Requirements Engineering was the topic for this week, and if I were to use an analogy of a car for this topic, I would say that while I have seen and had experience with all of the parts, I have never seen them assembled in such a holistic way before. The actual technical side of gathering, identifying and refining requirements was covered quite extensively in COMP2130 (Software Analysis and Design), and as for a Systems Engineering approach, we’ve obviously covered that earlier in this course. This is the first time I’ve seen these two practices overlayed and working together.

It was really demonstrated to me this week that engineering requirements is not only important when creating a system- it’s absolutely fundamental. If you think about it, the requirements are as important to the system as the code it’s dictating, or the hardware on which the code will execute. If the requirements aren’t gathered properly, the client is misinterpreted or some parts are missing, then this is going to create serious problems for your project- indeed, by simply screwing up the requirements, you could deem the whole project a failure! It’s simple enough to swap a broken motherboard out if one happens to break, but trying to rework fundamental requirements after the system has been developed would be a very expensive and time draining task.

So with this view in mind, requirements are another cog in our ever growing system perspective. It should be clear that if you attempt to gather requirements with this system thinking in mind, you should acquire much more satisfying requirements than if you go in thinking simply about the software alone.

References 

This week was our facilitation week for the Workshops, so we have been researching this topic for a few weeks now. One of the useful resources we found was Ian Sommerville’s book ‘Software Engineering, 9th Edition’, the first chapter of which can be found here.

• What does it mean to be a Software Engineer?
• What does it mean to be a Software Engineer inside of a Systems Engineering Team?

The first part relates to the actual role of being a Software Engineer in society. Ian Sommerville states that Software Engineers must operate in a social and legal framework (Sommerville 2010, p. 14), and that we must abide by a set of ethics, however this is discussed in more detail in this week’s video. As Software Engineers, it’s expected that we can develop software to a high standard, software that is well tested and software which does what it’s supposed to do. In short, Software Engineer differ from ‘programmers’ because we must give our stamp of approval that what we are developing is of a high quality. For this reason, in my eyes, the role of a Software Engineer and the ethics of a Software Engineer do more than just sit beside one another. They are completely intertwined. After all, if you are designing software for a life support system, or to keep an airplane running, how can you develop it to a high standard without investing your ethics into the system? And conversely, how can you build such systems ethically (i.e. so that people won’t die while using your systems) without building them to a high quality? It would be impossible!

Software Engineering, like all factions of engineering, has strong roots in our society. A civil engineer may look at a large highway, or a new building, and see a great achievement for civil engineering. A chemical engineer may look at PVC and rubber, and see a great achievement for chemical engineering (Flavell-While 2010, p. 52). In the same way, Software Engineering has many achievements it can be proud of, including (but not limited to) the World Wide Web, the software in cars and airplanes, Smartphone ‘apps’, powerful search engines, popular gaming systems and even things on a smaller scale, such as getting cash registers to work, websites to run or facilitating the electronic transfer of money. The common thread for every single one of these achievements is that the software does not exist in isolation- in each example it is part of some bigger system.

It is beneficially to the Systems Engineering Team (in my opinion) to have a Software Engineer as a team member, because they can offer a perspective which is unique from any other engineering discipline. Stepanek (2005, p. 22) argues that software is different to all other engineering products due to several key characteristics, including (but not limited to) the complexity of its design, the fact that it is the most abstract part of any project, and the fact that expertise with software is quickly out-dated, so most specific skills are learned on the job. Because a Software Engineer is already familiar with these complexity and unique issues, it allows them to bring a fresh perspective to the engineering table, which is something that a Systems Engineer (who needs to consider all aspects of the system) would find invaluable.

During the Workshop, we simulated the role of the ‘Software Engineer’ through the use of the ‘Scissors Engineer’, when building paper towers. I’ve attached photos of this activity as part of this week’s Portfolio entry.

References 

This week the panel revolved around system safety, of both software systems and systems from other engineering disciplines. The questions that were posed to us during the Panel included; How safe is safe enough? What techniques can be used to demonstrate safety? Why do we need safe systems? Can we predict the safety standards of the future?

This week, like so many of this course, has highlighted how different Software is as a discipline compared to other engineering disciplines. I think it’s a fair assumption to make that a ‘general’ software project would not simply be extending another system, but is more likely creating a new product from scratch. This makes software completely different, because other engineering principles are trained to extend from previous designs (be it something as simple as a table through to a Boeing airplane). This also makes testing the safety of software an incredibly difficult task compared to other disciplines, since there’s going to be so many extra variables every single time you need to assess a new system. A classic example of this, as presented by David, is air navigation systems (such as FANS, which is used by airbuses, Boeing 747s and Boeing jets), which typically take between 6 and 8 years to sign off.

I agree with David that safety is subjective, especially when designing software. And how can we have one standard that suits us across the spectrum of software engineering, when safety of a spread sheet Software System is going to be incredibly different, and have almost no correlation to the safety of a rocket system (e.g. the ARIANE 5 disaster). It’s got to be a tough job, and when you look at it from this perspective, it makes sense that safety testing takes such a long time for our field.

David talked about getting direct evidence of safety (such as through testing). Another way you could support the idea of safe systems is formal verification techniques, like those covered in COMP2600. Hoare Logic and Weakest Precondition calculus could both be used (granted they would take an incredible amount of time) to formally verify the work of components in isolation. This has been the first time since doing the course I’ve noticed a practical application for these techniques.

Ethics is discussed in the video this week, and I think it’s clear that this is a very ethical field. I guess the answer to ‘How safe is safe enough?’ for me is to do everything within your power to ensure the system is as safe as possible with the resources you’ve been given (and if that means resigning a job because you don’t want to ethically be involved with something that could harm people, then so be it). Assessing the safety of software would be a hard job, I personally don’t think I could do it (I’m not nearly patient enough), and I tip my hat to those that do.

References 

This week’s topic addressed the task of architecting within a complex system environment. We looked at some of the tasks of a System Architect, the correlation between traditional architects and System Architects, some of the tools at a System Architects disposal, and the complexity of the tasks an architect has to undertake.

In the Panel, John explained that architects co-ordinate a system, they will design many of the intricacies of the core of the system, then abstract the system for other stakeholders, and finally advise developers on how the system must be implemented. In this way, they operate in very much the same way a traditional architect does during the construction of a building.

One point that John really hammered was that ‘standards’ are one of an architect’s greatest tools. Entities such as the IEEE produce standards surrounding system architecture, which is beneficial for two reasons:

1. It means that globally, the work that architects do should converge to a common standard, which also helps with communication (having a common language) and dealing with replacing team members.
2. It simplifies the work for an architect. If they have to operate within a particular framework, then they already have some direction with what they need to accomplish before they even start. This is good for the architect, and the stakeholders, because it allows everyone to track the architect’s progress in a quantitative way.

John and Phil explained to us that architects want high visibility of their work. In fact, for them, the more people who can see their work the better- it means that more people have a common understanding of the system and increases communication between the architects and other parties involved with the development of the system. After hearing this tip from them, I did some research, and found Human Resource Expert Susan Heathfield’s techniques for creating high visibility of yourself at work.  While this guide is given with the intention of creating higher visibility to your boss as an employee, many of the principles given can be translated over for an architect to their stakeholders.

I think that being an architect would actually be a very difficult job (which is probably why they get paid a lot of money, according to John). The difficulty would be in understanding complex systems. Dr Sean Seefried explains that the human brain struggles with understanding complex systems, because it is not equipped (and has not evolved) to understand complex systems (Seefried, 2008). They are relatively new compared to our own existence, and as such, we are yet to evolve into creatures that are built to deal with such situations. Manchester University has gone as far as to publish examples of how some systems and situations are indeed too complex for human understanding. It’s for these reasons that I think being an architect of a complex system would be an incredibly difficult job to get your head around.

This leads me onto my final point. Another tool which John highlighted to us was a System Architect’s ability to abstract a system. My general of abstraction is that it’s used to hide the details of the system, and instead only includes the essential features needed for the intended audience. This ability to create abstractions of the system would allow a System Architect to explain to the client, upper management, developers and any other stakeholder exactly what information they need, without any extra details which could distract or confuse them (this could be done with documentation, or visually, with tools like diagrams). For me, this is the most important tool in the System Architect’s tool belt. It allows them to remove the complexity of the system for their audience, which has been established to be one of the biggest hurdles for people to overcome when it comes to complex systems.

References 

This week looked at Model Based Systems Engineering (MBSE), what exactly a model is, why models are useful in Systems Engineering (and other engineering and scientific areas), and the differences between Model Based and Document Based Systems Engineering approaches.

The Oxford Dictionary generically defines a ‘model’ as “a three-dimensional representation of a person or thing or of a proposed structure, typically on a smaller scale than the original” (2013). The idea of a ‘model’ for Model Based Systems Engineering follows this same generic pattern, however it is not inherently three dimensional, and allows simulation of the system. Specifically, for MBSE the model should describe the system and relationships within the system, allow for simulation, be automated, and allow for documentation to be generated.

In the Panel, Prof John Hosking raised the point that when creating a model, you do not simply create one ‘thing’. You may have several diagrams (Class, Entity, State etc.) as well as physical models and code which simulates that which you are modelling. In the Panel, Dr Clive Boughton made particular mention that often class diagrams get over complicated (often beginners will model ‘attributes’ as entire classes). I did some investigating, and found Robin Beaumont’s UML Class diagrams: tricks and tips page, which gives explicit instructions on how to reduce the unnecessary complexity of Class diagrams. Some tips that Beaumont recommends includes avoiding loop associations and try and reduce multiple level relationships within your class diagrams (Beaumont 2011, p. 4-5).

While in my opinion I think that it’s pretty clear that the benefits of a Model Based Systems Engineering approach outweigh the benefits of using a Document Based approach (as presented in the Panel and the Workshop, such as the advantages of enhanced communications, improved quality, increased productivity and enhanced knowledge transfer), however I don’t think that the Document Based approach can be written off at all. There may be upper management who are comfortable understanding a document based approach, and it may be part of the policy for the particular organisation that you work for that you follow a document based approach. If this is the case though, then I think that documentation should be kept succinct and to the point, and at best, you should try to adopt a hybrid approach between document and model based. Of course, a Model Based approach does not omit documentation- it merely shifts the focus away from the documentation itself.

In my workplace (I work in an applications development area), we develop prototypes, which certainly act as models of the system we intend to build (they generally don’t include all of the functionality of the intended final system, we can run simulations [tests] through them, and we can \ generate documentation from them). In fact, over the past few weeks I’ve been developing one (a tool which is going to be part of a bigger system), for which the intent is to show that an end-to-end solution can work. This prototype doesn’t need all of the functionality of the final product, it’s main purpose is to show that a tool like this can be made, and to show management that it’s viable investing the time in such a tool.

We have also used models in COMP3500 (the year long Software Engineering project) for the first two assignments this semester. The first was to create a prototype of something to do with the system (and if it’s viable, the team will build on your prototype), and the second is to create an artefact (however, this too can be a prototype, which is the case for our team). Our team is modifying an XML Parser for the open source application XMDS2, and if the clients are happy, we will fully develop and implement our solution. This prototype also includes several diagrams, which further contribute to the model, and allows the client to visually process how the artefact will work. This parallels the advantage of being able to use a model to demonstrate your solution to upper management in the workplace.

References 

This week, we looked at Human Error in Complex Systems. The Panel was delivered by Robyn Clay-Williams, and I personally found this Panel one of the most interesting and thought provoking Panels of the semester. Robyn discussed why we study human error, the impact of an individual making an error, the impact of a mistake stemming from the work of a small group, and the big impact errors that can accumulate as a result from a series of smaller errors or mistakes within a larger system (such as the death of Vanessa Anderson at Royal North Shore Hospital in 2005).

Robyn presented several techniques used throughout the aviation industry, and increasingly in the medical industry, to reduce the likelihood of mistakes occurring. Some of these techniques included:

• Standardising phraseology. This has been administered throughout the aviation industry (due to the Flight 401 disaster), with a high rate of success.
• Ensuring that there is allocation of tasks (for example, one person must always be in charge of flying the plane, even if that just means monitoring the autopilot). This method is trying to be introduced into hospital systems, particularly in the operating theatre, when the surgeon may be too focused on performing the operation to properly direct the rest of the team.

Robyn highlighted that the key to reducing mistakes is communication. If we can harness the power of communication (such as in both of the above to example techniques), then we will dramatically reduce the number of mistakes made in industry.

I have seen plenty of mistakes made in my workplace, including several from myself. My ticket submission for the Workshop this week discussed people sending e-mails to unintended recipients, which I have actually done in the workplace (thankfully, with very limited consequences). At my previous workplace (the-frozen-dessert-parlour-in-Belconnen-formerly-known-as-‘Rubees’) I saw people misread orders, misunderstand customers, put down an order then forget to actually make the food, and several other mistakes made. In my experience, these mistakes usually stemmed from tiredness, being stressed, distractions, a lack of training and/or a complacent attitude towards work. Several of these indicators were discussed in the Panel, and I can see in my new workplace how steps are in place to try and reduce mistakes happening from these external factors (including resilience methods, monitoring, re-designing devices to make them easier to use and providing training for employees).

I’ve certainly made mistakes during both our Group Project (in COMP3500, Software Engineering Group Projects) and in other courses throughout my degree. One of the most notable is losing work that I’m working on (I’ve closed programs without saving in COMP2300 [rPeANUt], had old computers crash in first year, and left my laptop on the roof of my car during a COMP2310 assignment). While trying to not do such stupid things as the latter (it was after pulling an all-nighter in the computer labs), I also changed the design of the way I work at university now. I’ve installed Dropbox on both of the laptops I work on, which backs up my work in 3 places every time I hit ‘ctrl+s’ on my keyboard. In this way (apart from trying to obtain common sense), I’ve designed my devices to try and minimise my chances of making a similar mistake again.

References 

Welcome to the final blog for the semester. I’ve decided to break this post up, in that the video will address the individual topics covered in Weeks 10, 11 and 12, and the written blog will provide a final holistic summation on Systems Engineering.

First, I want to look at why we would want to study Systems Engineering, and what we get from Systems Engineering as a discipline. At the end of the day, Systems Engineering is about the creation of the best systems we can make. We’ve seen that if we can look at systems using a holistic standpoint (with Systems Thinking), we can strike a balance between delivering value to our clients, building safe systems (as Systems Safety is a concern of the budding Systems Engineer) and systems which actually do what they’re supposed to do. Learning to build systems using a Systems Engineering approach means we have the best chance possible on saving time and money (by having a holistic view of the system sooner in the development lifecycle) and saving lives.

By studying Systems Engineering, we are able to create standards for the discipline (such as those discussed with Systems Architecture). Having standards simplifies the work we must do, and as demonstrated throughout this whole semester, Systems Engineers have to deal with complexity- so the simpler we can make our tasks, the better!

While we have spoken about the benefits of Systems Engineering this semester, I do think it’s important to step back and recognise the limitations of some of the things that we do. For example, in MBSE and Systems Dynamics, we can only create simulated models of real systems, and as such, there are going to be limitations and faults in our simulations. This isn’t necessarily a downfall of Systems Engineering. On the contrary in fact- if we can have a look at our own abilities and weaknesses with the holistic view (such as that demonstrated in Systems Thinking), we can then maintain a realistic view of ourselves as professionals, which will help us to understand what we can deliver, and to manage stakeholder expectations (something with is addressed quite extensively in COMP3120, Managing Software Development).

I expect that in the future, Systems Engineering will be incorporated into any type of development work (well outside the scope of computer systems). It was highlighted during the ‘Big Picture’ panel that there is really no scope outside of ‘Systems Engineering’, because every single entity can be represented as part of some system. I think that as the world gets more and more complex, we’re going to see the ideas presented in COMP3530 used not only for engineering, but for any discipline in life which deals with complexity, and interrelating systems (such as physics, economics, chemistry, business, psychology etc.). We’ve already seen how Systems Engineering can improve the quality of areas such as Sustainability through to saving lives (through the reduction of Human Error), and I am confident that we’ll see the scope of areas touched by Systems Engineering expand rapidly as time goes on, and graduates with our training are released into the world.

In this course as a whole, probably the most valuable skill I’ve been exposed to (and started to incorporate into all of my other subjects, particularly COMP3500, Software Engineering Project) is the ability to step back and take a holistic view of whatever I’m doing. I’ve found that if you can figure out why you’re completing a task (‘What value does this line of code bring to the program, and the system, as a whole?’), you can work smarter, contribute ideas with more confidence and ensure that all work is helping the project go in the right direction. I personally could definitely see myself going into a Systems Engineering role (although not for well over 10 years, I need some experience under my belt first). The other path which I’ve taken an interest in is System/Solution architecture. I didn’t even know that role existed before starting this course, but I could definitely see myself looking into that role as a future career choice.

Overall, Systems Engineering has taught me about the importance of perspective, communication, dealing with complexity, and never underestimating the power of people. These lessons have been derived from all of the different topics presented, and much like a Systems Thinking approach, I have been able to gain more from this course on a holistic front than simply from the sum of its parts.

References