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.