HW17: Chapter 16

16.9 > Design the interfaces of components that might be used in a system for an emergency control room. You should design interfaces for a call-logging component that records calls made, and a vehicle discovery component that, given a post-code (zip code) and an incident type, finds the nearest suitable vehicle to be dispatched to the incident.

Created using gliffy.com

HW16: Chapter 9

9.8 > Briefly describe the three main types of software maintenance. Why is it sometimes difficult to distinguish between them?

  1. Bug Fixing - this is repairing faults found in the software after it has been launched. The bugs are there possibly because testing was not as thorough as it should have been or clients have exposed bugs by using the software in unexpected ways. Coding errors, design errors, and requirement errors are the least, middle, and most expensive to correct, respectively. 
  2. Modifying software to work in a new environment - when the hardware or platform that the system was built to run on changes, then the software must change as well in order to be compatible and avoid being obsolete.
  3. Implementing new or changed requirements - software must be updated or changed so that it conforms with any new requirements. 

It is sometimes difficult to distinguish between the different types of maintenance because they are often given different names and also because faults that arise within a system can maybe have overlapping maintenance requirements. 

9.10 > Do software engineers have a professional responsibility to develop code that can be easily maintained even if their employer does not explicitly request it?

Yes definitely! Software development and maintenance are not separate activities. It is important to keep in mind how a system will need to be maintained if, for example, it is a system that is meant to last a long time and will have a revolving-door of developers working on it. A software developer who cares about the quality of their work will want to reduce the future cost of maintaining their software. According to the textbook, they can do this by using "Good software engineering techniques such as precise specification, test-first development, the use of object-oriented development, and configuration management" to help reduce the cost of future maintenance (Sommerville 259).  The ACM Software Engineering Code of Ethics says that a software engineer must "promote an ethical approach to the practice of the profession". This can only by done by carefully constructing software that is in the best interests of the employer (even if they do not require it), the client (who will have to pay for future maintenance), and the public (who want to use the software).  

HW15: Chapter 15

15.10 >  The reuse of software raises a number of copyright and intellectual property issues. If a customer pays the software contractor to develop a system, who has the right to reuse the developed code? Does the software contractor have the right to use that code as a basis for a generic component? What payment mechanisms might be used to reimburse providers of reusable components? Discuss these issues and other ethical issues associated with the reuse of software.

As graphic designer, I have encountered problems before in the design industry with confusion as to who has rights to a created product. Software reuse seems like a similar issue and I think there will forever be a debate between groups who want to share everything and groups who want acknowledgement of their achievements and therefore the rights to their own software. The former group will argue that they have built working software and its reuse is important in order to save time and expenditure on creating more software that works the same way in a future product. The latter group will argue that they have the sole right to reuse software that they developed. 

I think, at this point in my career, that I at least believe in rewriting the code portion of software. I think it is better to go over old solutions and improve them, even if they end up performing the same tasks as the older version. Otherwise, how is code ever going to improve if we just copy old solutions and never learn from them?

HW14: Testing Reflections

+ Readings:

+ Response:

When we first were introduced to testing, I thought, “Oh good, I always test my code - I’ve been doing this for a while now!” I did not realize how different writing test cases and testing requirements is from me just putting a couple “System.out.println()” lines in my program to prove to myself that it is running the way I thought it was. 

This practice has left me spending a lot of time in the toy-program equivalent of a software tester’s Mental Phase Two where I discover that my code doesn’t work and then have to make changes. Using the IDE’s debugger was a bit of a game-changer when it came to testing my code, but it didn’t change the fact that my programs have a lot of bugs, even if they run like they are supposed to. I can’t even imagine the amount of bugs in a software system.

In the Introduction of Boris Beizer’s Software Testing Techniques (I am pretty sure this is the source of our class packet), it seems like we have been testing our programs so far with Kiddie Testing, where we just run it and see what comes out (come on, everybody does it!), but then we also have been using a form of testing that requires trusted Existing Programs (Beizer 24). We have built programs based on the professor’s requirements and they run the program and test it’s reliability against a program they themselves have already created (hopefully!).

Beizer claims that testing is “done to catch bugs” (Beizer 1). A benefit of testing is that it can be done by someone who has no idea of how the program works, whereas debugging can only be done by someone who knows where to look and what could possibly be the cause of the failing test case.

I also took a look at “Google’s Innovation Factory: Testing, Culture, And Infrastructure”, an article written by Google’s Patrick Copeland for IEEE’s International Conference on Software Testing, Innovation, and Validation publication from 2010. Copeland claims that “Development teams write good tests because they care about the products, but also because they want more time to spend writing features and less on debugging” (Copeland 2). This is similar to Beizer’s approach where “The first and most obvious reason [for testing] is we want to reduce the labor of testing” (Beizer 6). Writing clear and intelligent tests is important because this means that more focus goes towards developing the software.

It’s also clear that software could never be bug free. Beizer elaborates on this by saying “If the objective of testing were to prove that a program is free of bugs, then testing not only would be practically impossible, but also would be theoretically impossible” (Beizer 24). It is not possible for there to be no bugs in software - it is possible, however, that the tests do not test that buggy input of the software and maybe the buggy input has such a small chance of being run that no one will ever know. 

I do think there are a couple of important ways of writing code that would decrease the possibility of bugs. Copeland refers to Frederick Brooks's No Silver Bullet when he states that “While there is no magic bullet, there is a pragmatism that can be applied to software development that seeks to balance the art form of creating software with the needs for repeatability, efficiency, and quality” (Copeland 4). Techniques like minimizing human-error in the running of software, reusing code that is proven to be reliable, and, of course, testing are all good practices.