Deliverable 5 - Part 1

We met today at our normal time to finish our project. We had code changes, a presentation, a poster, and various other things to be done. This enabled us to have a nice division of labor for completing things simultaneously. I personally tried to work mostly on the final document that was to be handed in.

We got everyone started on their part of the final project. Most of the presentation was planned, the document was mostly done and outlined, and the poster progressed greatly. We plan to meet again on Tuesday to finish up everything and do our practice presentation runs.

Final Meeting on Deliverable 4

This meeting we are finishing Deliverable 4 and the patches to deliverable 3 required. We tackled the problem with ordering of file names easily, as we did with getting the html output file to open automatically. All of our tests were already created, so that was done. Our output still isn't that pretty, but it's readable. We're gearing towards deliverable 5 already by planning everything out.

Meeting on Deliverable 4

We met again on Sunday in order to do the bulk of our work on Deliverable 4. Deliverable 4 was simple in principle - fix the problems with the third deliverable, and add another 15 test cases in order to obtain 25.

We started to develop a majority of the code changes to deliverable 3 that we had previously sketched out. We fixed our documentation for deliverable 3 and finished most of the documentation for deliverable 4. If the code we plan to implement doesn't work properly we'll have to go back and fix these changes, but at the moment it is theoretically sound. Coming up with the extra 15 test cases wasn't difficult at all - we incorporated another method that compared strings (by checking if the second string was an exact component at the beginning at the first one). We went back and added two test cases to our previous method as well. We'll meet again before our deliverable is due to solidify any code changes that haven't been finished by then and rework any documentation that needs to be gone over again.

Chapter 24 Thoughts - Quality Management

Having a good structure for a quality assurance plan seems important to the process. Without documentation it's harder to keep the same level of quality assurance constant - it is unlikely the entire quality assurance team is going to have the equivalent of a modifiable document memorized.

Having clear requirement is obviously important to the quality management process. Without requirements there isn't a measuring stick for quality assurance processes and standards to measure up against. Speaking of standards, software standards should be met whenever they apply to the situation.

Inspections and reviews was an interesting section to go over. It's more than just normal testing and seeing if the project works within specifications - it's about potential problems and measuring quantitative relationships and statistical information on the code itself.

Impromptu Meeting To Fix Deliverable 3

Today Nelson, Crendall and I attempted to fix at least some of our deliverable 3. The fixes we included were changes to the code and generalizing the test generation, as well as changes to the document. Changes to the document included things such as names, date, context, and filling out in greater detail how our tests work. Test cases requirements were specified further than reference,  and the how-to section was revamped all together to specify how to add and remove tests as opposed to how to run the framework in general.

Some Thoughts on Chapter 22

None of the important easy to see goals nor the problems of managing a software engineering project listed were surprising. We know by now that our projects are intangible, unique, and always changing, and actually doing what we say we will do is important to keeping customers happy. None of the responsibilities of the project manager were particularly surprising either.

That being said, risk management, managing people, and teamwork are all very important to the success of a software project. On some levels I feel like the management of people will lend itself to having certain elements of teamwork. Someone who is good at managing people is going to facilitate communication especially. While most of the important points in teamwork and people management seem obvious, they are obviously important and not always done correctly despite this.

Deliverable 3 Complete

All of our members showed for our last meeting before deliverable 3 was due, which was nice. Together we targeted different parts of the problem, such as the pdf file, oracle, test specification templates, and the script itself.

We encountered some problems getting it to compile correctly at first, at least having it do so automatically. We soon passed that first problem using the java compiler, and ran into other problems actually executing everything. Unfortunately these setbacks with java and the java compiler set us back quite a few hours.

While some of us were tackling that problem we were able to complete the other parts of the project and conceptualize what was needed to be done.

Unfortunately while we've sketched out the rest of the program this one problem proved rather difficult and as of the time of this time of posting is still a roadblock for us.

Chapter 21 - Aspect-orientated Software Engineering

Aspect-orientated software engineering certainly seems useful. We've looked at a number of software engineering projects that failed due to poor organization, planning, and communication. Aspect-orientated software engineering seems to directly combat that by identifying relationships between requirements and components, beyond the level of a simple T chart or a bunch of circles connected with lines.

The separation of concerns concept is something that we've been taught since the beginning, as methods and subroutines do exactly that. We were taught to make each function do one thing, and if something in a program appears multiple times, we should probably make a subroutine out of it. And while it may be more time consuming to piece together a puzzle with smaller pieces instead of big pieces, you can get a much tighter and problem free fit from the smaller pieces.

Updating Deliverable 2 and Onward

Before the weekend our team met and updated our previous deliverable, which included the test plan for our project. Our tests were planned more specifically with expected input and output, as well as a clear mapping form test to requirement being tested. The system testing area was entirely cleaved as we're focusing on one method out of a class for the moment, with many other methods in that class needing multiple tests. Instead of only having the required 5 tests for deliverable 2 we devised 5 additional tests after fixing the previous 5 bringing our total up to 10. Our focus for the next meeting is intended to be on deliverable 3, as this meeting was to ensure that we can hit the ground running for the next meeting.

On Sunday our team met again to start on deliverable 3. This meeting we created the first 10 test files we intended to use and sketched out the scripting file, as well as the overall plan. We ensured our repository had the necessary file system and our conceptual design for the rest of the deliverable was sound. With the completion of the test and us already knowing what the oracle should contain the script is the only piece that is really left.

Chapter 18 - Distributed Systems Issues

A distributed system is defined in the book as "...a collection of independent computers that appears to the user as a single coherent system." This makes me wonder if a system that allows the user to pick from which server to run, such as a video game, is considered a distributed system or not. Would it depend on whether or not that server was actually on several boxes, or would it not be one if it was one box per server?

The advantages and disadvantages of a distributed system seem obvious. More redundancy, more compatibility, and scalability. While response time may be an issue, these seems like issues that can be solved with good design or scalability - though like in all systems, security is an issue.

In the discussion of peer-to-peer systems, it is mentioned that Intel and Boeing have implemented a version of them to work on hard computations. It's mentioned that this software runs while the workers have gone home, but I wonder if they run whilst the normal business day is going? Does this adversely affect the performance of the individual local computers if so, or is the priority set very low?

Chapter 17

Component-based software engineering makes a lot of sense from an economical and even an efficient perspective, which I heartily respect. All of the component characteristics defined are characteristics that anyone at this stage would have discussed previously. The exception could be composable - which means all external interactions must take place through publicly defined interfaces - but this is an easy enough concept to grasp.

The concept that a component has two interfaces - the "requires interface" and the "provides interface" - is something I hadn't really thought about before. I'd certainly thought of the provides interface - as ultimately that is what I'm interested in. Obviously I had considered that I had to provide input to the component to get appropriate output, however I think I was stuck in the idea of providing it in the signature that I expect to get my output back from. Providing it beforehand, especially if the input is a large set of data such as a database, makes more sense efficiency wise. I'm sure these are thoughts that I've had before, but they were gleaned over and I never thought of the concept properly.

Team Meeting for Deliverable #2

Unfortunately our team meeting on Sunday did not have all of our members in attendance. Me, Brendan, and Crendall managed to physically be there, though J Roth did manage to aid us and communicate through the Google document where we constructed our deliverable. The construction of the deliverable was not particularly difficult, though we had to negotiate schedules and what tests we first wanted to do.

Initially we went to page 209 of our book as instructed. The page didn't detail any structure for our plan like we hoped, and the link it sent us to was dead. Instead we used the link you had and based our structure on that. I made the document and while we all discussed it I typed, and later Crendall was the one who uploaded it to svn after saving it as a pdf. We know most of our resources will be sunk into deliverable number 3 since that's where the scripting will come into play, and we know we have to research how to manually get the project to compile.

Legacy Information Systems

I was previously unaware that legacy information systems were so important to so many people. When I hear of a legacy system I normally think of an outdated system that's been in use for a long time and is still in use even now. I imagined that most companies had at least a slightly updated information system at their back end to keep everything running. Of the three solutions to the problems of legacy systems, I hadn't previously thought of migration. I suppose it just seems similar to wrapping to me - I'm curious how it's possible to move the system to a more flexible environment while keeping everything the same without simply throwing a wrapper on it.

It's also interesting that if a system can be maintained within an acceptable budget then the system isn't usually considered a legacy system - and given that most companies apparently have legacy systems, that's a lot of companies over-budget in this one area. It seems like this big problem would have gathered more interest and work in the field.

It seems to make sense that lazy people who aren't terribly concerned about the long-term make wrapping the most popular choice of solution - especially given it seems to take the least work in comparison. Migration work is an in-between between redevelopment and wrapping in a way I didn't expect - it seems to be essentially copying the system over with everything wrapped in the actual code. You're just fitting the old data in a new form. It comes at no surprise that testing is important and may take most of an engineer's time.

Interim between Deliverable 1 and 2

This weekend I was personally in Atlanta for Anime Week Atlanta, a trip which I'd been planning for roughly a year. As such, I wasn't able to do much on terms of our team project - though I did keep loose track of what was going on. Most of my work for the class this weekend was invested in studying for the test on Tuesday. However, I did note that my group has been working on getting the new project up, compiling, and running. We were debating switching depending on several factors, so they were testing whether the candidate we voted to be the new one was viable to replace the one that we previously got to compile.

Thoughts on Chapter 15

Chapter 15 mentions that critical systems require advanced testing due to the costs of failure and validation of dependability attributes (you may have to prove that you tested it and it works). Personally I find these two things to be thoughts that haunt me as I develop regardless, and couldn't imagine releasing a critical system without rigorous testing. Rockets shouldn't fail in launch or orbit due to a simple, basic test that was never run due to laziness or oversight.

Static analysis comes across as the basic overlooking and viewing that happens as you write the code, as well as the simple code checkers and peer review. A necessary first step, one that covers a lot of basic and disastrous conditions but still overall not too complicated.

Reliability testing is something that's important as it seems like it can uncover some real problems going on under the hood. Things go wrong for a reason - if the reliability of your system is really low - a simple change or stomping of a subtle bug may really improve it and lead to a better user experience.

Security testing is definitely more important now than ever before. Though I'm not experienced at all in the area of security, I recognize it's importance and I'm interested in it. I'm personally up in the air which is more important to me personally - reliability or  security. On one hand having a reliable system that's vulnerable means that those who get unauthorized access have correct in formation - on the other if a system is unreliable, can it really be secured if the security is part of the same design?

Process assurance seems to reaffirm something that we've been taught in general in life - products made of better materials generally make better products.

Deliverable 1 Personal Experience Report

Our team ran into many problems in getting the code to download and compile. None of us had previous experience with bazaar, which was used as version control, and most of us hadn't done Mavis before to compile information. Our first meeting was wrestling with that alone, however we only had 3 members for the first meeting. Our second meeting everyone was in attendance and we got it working relatively quickly. The source code took 15 minutes to compile, which was quicker than expected, but still gave us an idea that this was a bigger project than anything we've dealt with before. My laptop seems to have a problem running the distributions of Linux I've tried to use on virtual box, and having Windows 8 makes it more difficult to set it up to dual boot. This means I haven't been able to do anything other than look up information and process it while others have the code on their computers. I still have Ubuntu on my desktop though, so I'll still be able to do so from my own home. We previously didn't realize that we would be selecting a module as opposed to doing the whole thing, as the website didn't give us the impression that it was separated quite as such. We selected the web commons module to work with, as it had previous tests, which all worked properly. It seems like the tests use Junit, and while none of us are intimately familiar with it, we understand it's rather easy to deal with.

Reading Reflection on First Testing Reading

I think it's rather sad that more programmers don't like testing and test designing. While I don't feel especially thrilled about learning about test design per say, I do like running tests on things to make sure they work – whether they be things that I'm going to be graded on or things that I'm giving others to use. Not only do I want the grade and I want others that receive my help to agree that I helped, but I have a sense of pride when I work hard on a program. Testing is vital this to make sure that it meets requirements – and who doesn't get a ping of pride when a test, especially a rigorous one, is passed by one's creation? I don't feel guilty when I test and make sure my creation works. I don't feel guilty because I know I may have messed up – I know I'm not perfect, and scoff at those who think they are.

I was intrigued by the notion of using testing to prevent bugs, not just to catch them. It seemed foreign at first, but after a thought this seems to be tied closely to test-driven testing, and not so unfamiliar.

I enjoy how he broke down the "phases of thinking" on testing. The fact that it's impossible to test to show that software works is an important thing to remember and should be stressed more. Similarly phase two's objective of "show the software doesn't work" is also an infinite war between testers and coders, though at least it gets us farther than just trying to prove that it does work. Phase three – to reach a certain degree of quality – is probably as far as most companies go. I somehow doubt that most companies try to get their testers to do further research into testing as a discipline – they probably just test their things, assuming they having any dedicated testers at all.

Though I didn't particularly enjoy re-reading, say, the definitions of an ORACLE, it's good to know that things that I've been taught are also mentioned and important in real applications.

Reflections on First Team Meeting

Our team assembled at the agreed upon place at the correct time without incident. We quickly got to work and agreed upon trying to find projects made in languages with which we were all familiar. Given that we had all used Java before, and all but one person had used Python, we looked for projects that were in Java, and had Python projects as a not too bad backup. We quickly discovered quite a few projects were no longer active, and that some of the links were dead. We also endeavored to find a project that wasn't too difficult, yet wasn't too boring - we weren't looking for the simplest things possible. We eventually all-together found 3 projects that were in Java, not too difficult or easy, and still had some level of support by other users. We all agreed on three differing projects, all of which were discovered by differing members - it was good to see that my team-mates didn't select the first three that met all of our criteria, but ones that they wanted to do out of a pool of acceptable ones. Overall there were no problems and the meeting was quick, it certainly seems like we're all capable of communicating and I look forward to the rest of our project going as smoothly (hopefully).

Homework 9 – Software Engineering – CSCI 362-001

I suppose previously I hadn't considered the four areas of “The Programming Systems Product”, aka the program, Programming Product, Programming System, and Programming Systems Product. I'd always been aware that when someone was toting about having made some amazing program that's cheaper and works better than those that are commercially available that it was probably missing a great deal of something – though I hadn't really considered that maybe it was a different type of product all together.

I agree that turning non-tactile thoughts into real results is something that is is one of the most enjoyable things about programming. I also agree that there are quite a few things that seem to make it frustrating – always working for others, always being outdated, spending large amounts of time finding bugs. I also find that optimism in our craft is...silly. It would seem to me that you want to be cautious about what you guarantee and you want to be 100% sure you can give what you promise – if you're an optimist or take their approach, you seem to be shooting yourself in the foot in that regard. Especially in something where you have to test repeatably to see how often it's reliable – why would you assume something is fixed or done before you've tried again?

I think overseers of software development projects don't always understand what is going on to make their project happen. Needless to say it's rather agreeable to me that any month and any man are interchangeable. Not only is each person different, each month a different length with different variables, but the problems and progress that needs to be made is different at each different point in time.

Communication seems to be one of the biggest reasons for software failure – though this book gets into some detail about why communication isn't just “easy”. It also goes into why adding people to a failing project is a bad idea – not all problems can be solved with more people, and if communication is already bad, more people are only going to make it worse since far more has to be done to keep more people up to date.

I'm not sure how most schedules for software projects usually are planned, but lots of testing time seems important. It seems most failures are because of poor design and not enough testing – it seems logical that these areas are given the most manpower when planning allocation.

Better, smarter, smaller teams being preferred over larger more mediocre teams is also something that seems like common sense and has been something taught to us over and over. More people means seaming together more partitions, more training, less responsibility and more effort in communication. While it's true this means really large systems won't be completed in time for them to be used or useful, I imagine there are a lot more smaller projects being designed and developed than extremely large ones.

Mill's way of splitting up work and getting a project done sounds like it's...very neat. Neat in a sense of organization and responsibility, which I enjoy. That being said, this team, especially with the “surgeon”, sounds very risky – consequences could be severe if he was to quit or leave. I'm not sure how more business manages are willing to risk in regards to this – it's very much like putting all your eggs in one basket.

Homework 8 – Software Engineering – CSCI 362-001

At the moment, I think programming and software engineering are headed in a direction where they will "take what they can get" in terms of advancing their field. While everyone seems to agree that some degree of automation to the process would be greatly beneficial, it doesn't seem like this is about to pop up. On the other hand, small features help a little bit and come up every once in awhile, but aren't the "one big thing" that really propells either field forward. As a result, I don't see everyone necessarily "dog piling" on one particular grand idea that will revoluntionize everything – everyone is simply trying to improve.

I think that as the age draws near where anything and everything from lights, doors, locks, appliances and the like all have embedded systems, that some rough form of "accepted default plan" will emerge for the software to run certain systems. For instance, it's possible "pool lights" will have a very loose minimal content package that will provide a bare minimum of functions to be implemented. I imagine similar things for revolving doors, the gates on the subway, etc, to prepare for a time where everything has a computer in it, but still needs to be specialized to some degree. That there is some rough base to start off of ensures that no "basic" feature is simply forgotten – it is omitted by choice. They could imply a methodology of design or just a really basic shell of code that is easily modified.

As for the programming environment shown off in Future of Programming, I'm unsure. While convienience is something that comes to mind, security seems to be a big issue. A college student doing homework with a group may really find this useful – especially in regards to installing software he'll only use for one class – but big corporations getting into this seems unlikely. The very notion and basic idea of this project means that your data is in the hands of someone else – and if you're making something big and secret for you're company, the kind of people with access to this system would be the kind of people who could make something out of any information gleaned. They also mentioned that you could ssh into other servers you own from the command prompt in the software. If this feature is utilized often, then they have data to access other data that isn't even on their servers.

While it does some have nice features that let you put all of your code into "scope" – zooming features, tracing, etc, I somehow doubt these will "revolutionize" much of anything in programming. In addition, these features are something that is doubtful to remain exclusive to their system for long. And while the program may work on their systems, the programs must still be taken off and compiled in order to be tested to run on other target machines. How will the servers stand up to heavy load, either by a multitude of testers or a manageable number with huge projects? Will it simply slow, or will data be destroyed?

I think that their project definitely has a place – somewhere. I doubt it's in the hands of every programmer though. The video supplied was released on June 29, 2012. Over a year has passed and before now I'd never heard of it – if this was going to be the next big thing now, I would imagine I'd at least heard a whimper by now.

Homework 7 – Software Engineering – CSCI 362-001

I'd heard previously about the 7 +- 2 rule. I heard that it meant someone could only do around 7 things at once – though I wasn't told this was between 2-3 bits of information. It certainly seems interesting that short term memory isn't based on bits but by chunks – certainly encouraging people to specialize instead of being a jack of all trades.

In regards to failures in cloud computing, I suppose I previously always defined “uptime” as time that the service is available and working correctly – though I suppose this time frame may differ depending on the software. I think the distinction between accessibility and availability is an important one. Having a feature that presents a users with a descriptive screen of what's going on when the service is not available can be critical to keeping users content, happy, and informed.

Degradation instead of failure is a wonderful idea. Nothing is perfect and everything will fail eventually – it's better to plan for these events. This also helps encourage a healthier state of mind and development practices – to not assume you're design is perfect. I've always felt that redundancy of middle-tier equipment has had an edge over singular high-tier equipment – it's less presumptuous and gives multiple failure points. The points on being able to detect failures was basic but important.

The point on making sure a “re-try” is included in exception handling seems obvious but probably often forgotten and critical. I hadn't previously thought of all the uses of request-buffering though – I'll certainly try to remember it for later projects.

Capacity buffering seems like a basic good design, and dynamic resource accessing seems like a good idea if even for security reasons. Automating responses to failures as much as possible seems like a normal step as well – as does seeking out problems and solutions which may pertain to your system.

After reading the title of the paper on tire's and mandatory wireless service, I'm immediately concerned. I don't particularly desire for my car to be communicating with anything else other than me physically – that way I'm more secure from being remotely screwed with. It seems rather obvious that a particular network can be tracked with some work – while not a particular concern for me at the moment – could easily be for others. Another rather disgusting feature is the mandatory requirement for it as opposed to letting it be voluntary.

I'm not sure if I should be proud or concerned that some of the experiments done concerning privacy were done somewhere I drive regularly. While I wasn't shocked to learned that the range of picking up packets was large, and that it was not difficult to force trigger and capture it – I was concerned. There seems to be very little to no security on the system as well – which is even more concerning. The later experiment that forced warning lights to go off brought everything into perspective – you could force someone to stop in order to render them more vulnerable.

Homework 6 – Software Engineering – CSCI 362-001

4.5– Using the technique suggested here, where natural language descriptions are presented in a standard format, write plausible user requirements for the following functions:

An unattended petrol (gas) pump system that includes a credit card reader. The customer swipes the card through the reader then specifies the amount of fuel required. The fuel is delivered and the customer’s account debited.

The petrol pump system shall dispense the amount of fuel specified after ensuring that the bank has approved the withdrawal.

The cash-dispensing function in a bank ATM.

The ATM shall dispense the amount of cash specified after ensuring that the bank has approved the withdrawal.

The spelling-check and correcting function in a word processor.

The spell-check function should underline all words it does not recognize and allow users to right click and view spelling suggestions.

4.6 – Suggest how an engineer responsible for drawing up a system requirements specification might keep track of the relationships between functional and non-functional requirements.

Functional requirements used to enforce non-functional requirements could be recorded and tracked by having a diagram with functional requirements connected to non-functional requirements by lines.

4.7– Using your knowledge of how an ATM is used, develop a set of use cases that could serve as a basis for understanding the requirements for an ATM system.

Withdrawing money allows one user to withdraw money from their account. The user inserts their debit card, verifies their identity via PIN, and specifies how much money they would like to withdraw. The system deducts that amount from their account if the machine has enough to dispense, and does so. The transaction would close and the card would be returned.

Depositing money allows one user to deposit money into their account. The user inserts their debit card, verifies their identity via PIN, and specifies an amount to deposit. They then select what form the amount will be deposited be – cash or check. The check or cash would then be collected and verified as being the correct amount and legal, and the transaction would close. The card would be returned.

Creating my directory on Subversion

My first mistake when attempting to create my directory on SVN was when I sat down and decided to do it. I assumed I had to ssh in, and after I started typing in the command, realized I wasn't provided a port and that I was an idiot.
After typing "svn" into my terminal, it took very little time to install. I had looked up the command to actually create the directory earlier, mkdir, and recalled it was similar to how other file systems on Linux work.
Unfortunately, after a quick perusal of the staple SVN commands, I thought that the "checkout" command would give me what "ls" would normally - this turned out to be wrong. Luckily enough though, it did allow me to login to the server so that I needn't be bothered when running other commands, so it wasn't a complete waste - and it did show me that someone else had beat me to the punch.
I quickly found the command I was looking for, the list command, with the reasoning that even if I make the directory I was looking for, I would need to verify it's existence in an easy way. Besides, I was curious to see how many other people had completed the assignment as well, just in case checkout was reporting oddly.
Unfortunately while using mkdir, in my confusion, I may not have properly logged my actions when prompted - however, upon using the list command, found that I was indeed successful.

Homework 5 – Software Engineering – CSCI 362-001

The software problems that caused the aerospace accidents seem like things that should have been easily avoided to us now, but perhaps then not so much. I don't know how the schooling was for the engineers, nor the common procedures – we seem to have a process for trying to cover as much as possible nowadays and a better standard for making decisions on what should be included and making sure it works. I was most troubled when it was mentioned that software was apparently assumed correct until proved faulty – as if they were just going to see if a program worked on a cheap replaceable computer instead of launching hardware into space.

The lack of responsibility in these projects shocked me as well. I thought people in higher up agencies at least tried to make sure someone else could take responsibility – even if it was due to simple paranoia for their own skins. The fact no one was doing certain things was also baffling; certainly checking whether something was done or at least basically tested would be on the checklist? It seems odd to have more software and procedures than necessary on something that once deployed would be essentially unmodifiable. The old adage less is more should hold some weight when applied to something where everything must go perfect – and who isn't willing to specify exactly what they need when they're going to be shipping the thing off to space?

The Sentinel and Virtual Case File articles disappointed me. As a kid I always assumed that the government was always listening and constantly keeping up to date with information and how to manage it – it seems like the FBI should have a better system than paper to keep records. The fact they don't seem able to communicate with those it has working to make a more up to date system is also baffling – certainly they should be harassing those who work for it for constant work updates, if nothing else? These agencies are usually thought of as more capable – or at least more capable of intimidation in regards to getting others to do something they want. The fact that security was apparently an issue was also appalling – for any system for the government I would imagine security would be the top priority.

The situation with medical equipment – radiation emitters specifically – seems like something that should have happened at most with one device. I would expect more caution from anyone working on a medical device. Furthermore, I would think that the makers would be more paranoid about lawsuits or being held responsible for their product malfunctioning so horribly. It seems all of the systems did not have nearly enough feedback, and attempted to be way too complicated – offering features such as auto treatment when something so life threatening should be given instructions very discretely. For the Therac-25 it seemed like a horrible legal and PR move to deny knowing of other accidents at one point – especially when evidence existed to the contrary.

Homework 4 – Software Engineering – CSCI 362-001

11.4 – Giving reasons for your answer, suggest which dependability attributes are likely to be most critical for the following systems:

An Internet server provided by an ISP with thousands of customers – Availability and reliability so that the thousands of customers can get the services they pay for.

A computer-controlled scalpel used in keyhole surgery – Safety, reliability, and security so that when the scalpel does perform, it does so correctly and does not cause damage. Security is involved in this so that the system is not compromised and used to murder patients.

A directional control system used in satellite launch vehicle – Availability, reliability, and security are paramount. This is so that the satellite can be moved out of the way of debris at any time without worrying about malfunctions, and security so that it isn't used for terrorist purposes.

An Internet-based personal finance management system – Security and reliability are the most important. The finances should not be compromised at any cost, and accidents involving the finances should not occur.

11.7 – In a medical system that is designed to deliver radiation to treat tumors, suggest one hazard that may arise and propose one software feature that may be used to ensure that the identified hazard does not result in an accident.

An example of a hazard in this situation is that the sensor that measure how much radiation is to be released may stop working. In this situation the software should not allow the treatment to proceed until it is fixed.

11.9 – Using the MHC-PMS as an example, identify three threats to this system (in addition to the threat shown in Figure 11.8). Suggest controls that might be put in place to reduce the chances of a successful attack based on these threats.

An unauthorized user will gain access to the system by infecting an access terminal and stealing login credentials.

An unauthorized user will harass and clog the system in an attempt to cause a denial of service.

An unauthorized user will bypass login terminals and inject malicious software into servers in order to change or steal confidential information.

Homework 3 - Software Engineering - CSCI 362-001

10.6 - A multimedia museum system offering virtual experiences of ancient Greece is to be developed for a consortium of European museums. The system should provide users with the facility to view 3-D models of ancient Greece through a standard web browser and should also support an immersive virtual reality experience. What political and organizational difficulties might arise when the system is installed in the museums that make up the consortium?

Depending on where the physical museums are located there may be legal issues depending on the content of the system. Ancient Greece had several activities which are not necessarily accepted today - this ranges from pedophilia, young marriage, and brutal murder. If the system includes these then there may be political damage done to the institutions. Organizational difficulties may arise if the system makes staff members irrelevant - the job that they previously done has been replaced.


10.10 - You are an engineer involved in the development of a financial system. DUring installation, you discover that this system will make a significant number of people redundant. The people in the environment deny you access to essential information to complete the system installation. To what extent should you, as a systems engineer, become involved in this situation? Is it your professional responsibility to complete the installation as contracted? Should you simply abandon the work until the procuring organization has sorted out the problem?

As a systems engineer you should attempt to gain the information you require to do the job you were
contracted to do. If it is being kept from you by others, you should avoid direct conflict (getting in
arguments or threatening those barring your way), and have the procuring organization gain and provide the data. At no point should you do any illegal activity to gain access to the data you need.

Homework 2 - Software Engineering - CSCI 362-001

No Silver Bullet by Frederick P. Brooks, Jr has many fair points, though seemingly none revolutionary. I agree that the nature of software means that a sure-fire way to complete every software project seems unlikely. The complexity, need for change, and variety of all software required seems too vast, especially with changing hardware and the variety of hardware. I also agree that high level programming languages did a huge amount for software development – it reduces labor time and complexity.

While object orientated programming does help in terms of design, I do not personally feel having a class hierarchy greatly aids the whole field of software engineering. While it does aid in the complexity of the craft, there are other factors that simply outweigh the advantages it gives. Similarly, I do not feel that artificial intelligence is going to make software engineering really easy – at least not in the near future. There are still great strides left to be taken to get the AI field to smaller accomplishments – solving something like easy software engineering development seems far off. I feel similarly about automatic programming.

In Kode Vicious' Cherry-Picking and the Scientific Method I agree that preparation for thins such as mergers is more important than trudging through old code for diamonds in the rough. Doing so seems like a much better use of time and will lead to more efficiency. Similarly, any time any bugs are to be fixed I think good documentation is in good practice – that way, if nothing else, you can always backtrack if your fixes have unexpected consequences, or someone wants proof that you have been working on something specifically.

Software Analytics by Tim Menzies and Thomas Zimmerman proved to be an interesting read. This was due to the fact that I had previously heard of and conceived the field, but had not actually read anything about it previously. I definitely find software analytics techniques necessary with all the data available today – it would be impossible to search through it all with humans, and would more than likely prompt many mistakes. The article also supports the idea that the “silver bullet” for software engineering is not likely to pop up, as even they state that what you learn from one experience may not apply to a different one. The article also reassures job security when they state that having a huge amount of processing power is useless without good scientists behind it – something I would assume that most people would think.

It seems out of the three articles that this one describes a subject that may encounter legal issues the most, depending on what type of data is being worked on and where it comes from. With recent scandals such as the NSA debacle and the companies related, this field may be greatly affected if legislation is passed to alter what is allowed. I must admit though, the predictions for software analytics in 2020 seemed a bit generic and lack luster.

Homework 1 - Software Engineering - CSCI 362-001

1.3 : What are the four important attributes that all professional software should have? Suggest four other attributes that may sometimes be significant.

Four Important:

I. Functionality/Performance
II. Maintainable
III. Dependable
IV. Usable

Four Suggested:

I. Secure
II. Safe (In terms of potentially damaging hardware)
III. Portable
IV. Understandable and Simple


1.8 : Discuss whether professional engineers should be certified in the same way as doctors or lawyers.

    Professional engineers should be certified in a similar way to doctors and lawyers. They should
have to demonstrate some level of competence in regards to knowing a variety of different software
engineering techniques. This would be so that they are capable of making a decision about what techniques should be used for development, as opposed to applying one approach to every problem.



1.9 : For each of the clauses in the ACM/IEEE code of ethics shown in figure 1.3, suggest an appropriate example that illustrates that clause.

I. Public - Do not develop systems designed to harm the public, such as making a program that acts as
mal-ware.

II. Client and Employer - Develop systems that meet client and employer specifications whilst still
preventing harm to the public, such as meeting specifications while maintaining security and performance.

III. Product - Do not create shovel-ware designed to capitalize on a fad whilst disregarding quality, such as creating a bad application to capitalize on the release of a new popular movie.

IV. Judgement - Do not allow yourself to be swayed into violating or ignoring moral or legal problems, such as accepting bribes to let something go or stealing previously developed software for use in your project.

V. Management - Not only should you hold yourself to a code of ethics, but encourage others to do so as well, such as in an office with potentially unethical business practices.

VI. Profession - Do not "paint software engineers black" by attempting to jeopardize the integrity or
reputation of the profession due to a fall-out with employers or colleagues.

VII. Colleagues - Do not belittle colleagues who have failed or are having trouble, and instead help or
give advice and support, even if in direct competition.

VIII. Self - Continue to learn about new software engineering techniques and encourage others to be ethical in their approach to software engineering, as opposed to refusing to use new techniques and sitting idly by whilst others do unethical actions without being encouraged to be ethical.



1.10 : To help counter terrorism, many countries are planning or have developed computer systems to track large numbers of their citizens and their actions. Clearly this has privacy implications. Discuss the ethics of working on the development of this type of system.

 By working on this type of citizen monitoring system several of the clauses above may be breached.
This is somewhat dependent on whether or not the citizens would like to be monitored and whether they agree such a system would be in their best interest, as well as your own thoughts on the matter. It would seem more likely that the citizens would not be in favor of such a system - and therefore, according to the clauses above, your actions potentially unethical.