I was born in Charleston, South Carolina. However, I have also lived in Alabama and Virginia before moving back to Charleston when in seventh grade. I remained in Charleston until I graduated high school from Fort Dorchester, after which my parents moved to Georgia. I am now a junior and a computer science major at College of Charleston. My faith, family, friends, and my dog, an eleven year old lab mix, are a few things that are important in my life. My current favorite movie is A Star is Born (the new version). I also enjoy going to the beach and going for bike rides, and I have recently taken up knitting over the past year. (In other words, I have knitted far too many scarves to live in a state with such hot and humid weather.) I am excited to further my knowledge of computer science in this software engineering course this semester and to see where my acquired knowledge will take me in my future CS career.
1.3
Four important attributes that all professional software should possess include acceptability, dependability and security, efficiency, and maintainability. Other attributes that may sometimes be significant may include: 1. creativity in order to appeal to a specific client/user base depending on the purpose of the software, 2. backward compatibility in order for users to be able to continue using the software with older versions of files and data, 3. being innovative in order to keep up and compete with other rapidly advancing and changing technologies (for example, that of other competing companies), and 4. portability in order to provide users with increased mobility of software on any device or operating system they may prefer.
1.8
In my opinion, professional engineers should be licensed in the same way as doctors or lawyers in terms of ethical practices. Because the vast majority of society depends daily on the work by software engineers, their work could have potential detrimental effects. For example, if a software engineer is developing software for a doctor's office, a level of respect and confidentiality should be given to the patients when the developer has access to personal information that may be used maliciously if placed into the wrong hands. Software developers have a great knowledge base that allows them to work in a wide variety of fields, which most other professions do not possess. Therefore, the dependability and trustworthiness of software developers is vital to the workings of an ethical society.
1.9
PUBLIC: When developing a website for a large company, a software engineer should not implement a virus into the site that would infect users' computers for the purpose of stealing personal information, such as passwords, bank account information, etc.
CLIENT AND EMPLOYER: If a bug is discovered in an online shopping website by the software engineer, it is expected that the bug will be fixed out of interest for both the client and employer. For example, if the website calculates an incorrect amount of state tax owed by the user at checkout, this could negatively effect both the client and employer.
PRODUCT: If the developer realizes he/she does not have the proper skill set to perform a certain task, he/she should admit this fact and allow a developer with the proper expertise to handle the task.
JUDGMENT: When a software engineer recognizes a potential overlooked problem in a team's code/work, he/she should know when to speak up about the problem rather than knowingly allowing the problematic work to be implemented into practice.
MANAGEMENT: A software engineer should give credit where credit is due for work that is not theirs. It is common for developers to use previously written code, but credit should be given to the original developer of that code when needed.
PROFESSION: Software engineers should do their best to meet proposed deadlines to clients and should not knowingly withhold critical information needed by the client.
COLLEAGUES: When a colleage asks for aid on a task they are struggling with, a supportive software engineer will be willing to give advice in a non-condescending manner.
SELF: With an ever growing amount of technology, a software engineer should continue to take courses and study new technological advances and innovations in their field.
1.10
To help counter terrorism, many countries are planning or have developed computer systems that track large numbers of their citizens and their actions. Clearly, this has privacy implications. If a software engineer found that this interfered with their personal ethics, he/she would technically be required to speak out against this and possibly resign from their position. However, this remains a problem of personal choice, as it may be seen as both ethical and unethical, depending on the point of view. For example, some may view any invasion of privacy as unethical, despite the reasoning behind it. On the other hand, if the US were to use such technology against an enemy country during a time of war or under suspicion of malicious acts against the US, some may perceive such use of technology justifiable. In this example, some may even consider it it unethical to not use such technology against another country in order to protect the USA's own citizens. In matters such as this, the ethics of working on the development of this type of system becomes a matter of personal choice and specific situations.
All three of the assigned readings, in one way or another, discuss the development costs that accompany any software development process and the methods that can help reduce and/or increase these costs. “No Silver Bullet” highlights this fact by stating that “the cost of software has always been development cost, not replication cost” (Brooks 17). However, the article also makes the point that software progress is not necessarily slow due to development costs. Rather, the high speed of hardware development makes the progress of software appear slow in comparison to hardware’s rapid innovations (Brooks 11). Nonetheless, methods such as code replication, top-down design, and version-controlled storage of files all aid in decreasing the amount of time it takes to push out usable software.
One such example of decrease in development cost is illustrated in George V. Neville-Neil’s “Kode Vicious”. The article states that the best way to avoid ending up in the pits of cherry-picking is to be sure to periodically merge whatever code that a developer is working against. In other words, a developer should “have a merged and tested branch ready to go when it is time for [the developer’s] project to resynchronize with the head of the development tree” (Neville-Neil 33). A related idea is reflected by Google’s practices in Rachel Potvin and Josh Levenberg’s article, “Why Google Stores Billions of Lines of Code in a Single Repository”. Google implements the trunk-based development strategy in order to efficiently manage their large repository, thereby decreasing development costs. This method also helps to alleviate the difficulties associated with the merging of branches (as in “Kode Vicious”), but does so by attempting to altogether avoid the “painful merges that often occur when it is time to reconcile long-lived branches” (82). Rather than developing on the branches themselves, revisions (such as bug fixes) are developed on mainline and subsequently cherry-picked into the branch if necessary. Because of the extremely vast repository that Google works out of (which is not the case for all software developers), this method is especially beneficial, as it allows newly committed code to be immediately seen and used by all other Google developers (82). Although there exist additional benefits to this trunk-based approach, there also exists drawbacks, such as the added costs of developing automated testing and “pre-submit” infrastructure.
This reflects the common trend of trade-off analysis throughout the software development process in general, as reflected in “No Silver Bullet”. The article states that software development is the only technology where one can choose to gain from “either improved performance or in reduced costs”, suggesting that improved performance comes with a host of development costs while reduced costs comes with a decrease in software performance (Brooks 11). This is further illustrated by the fact that “Google invests significant effort in maintaining code health to address some issues related to codebase complexity and dependency management” thanks to its large repository (Potvin & Levenberg 86). Despite potential benefits of working out of smaller repositories, Google has determined that the benefits of maintaining its current working repository outweighs its current costs of maintenance or that of downsizing into a non-monolithic source repository. This example suggests part of the reasoning behind Brooks’ belief that no “silver bullets” are likely to appear anytime soon due to the very nature of software, such as its trade-offs, among other factors.
11.4
The common characteristic of all architectural styles that are geared to supporting software fault tolerance is that the system architecture is designed to include redundant and diverse hardware and software. The importance of this can be seen through the replicated server approach, where redundancy, but not usually diversity, is provided. Because server hardware is often identical and run the same versions of software, they can cope with hardware failures but not the software failures that are not localized to a single machine. Thus, both diverse hardware and software is necessary for handling software design failure. Benefits of redundancy can be illustrated in replicated servers through the preserved system integrity if the hardware of one server were to fail and another server be forced to take over the unprocessed transactions.
11.7
It has been suggested that the control software for a radiation therapy machine, used to treat patients with cancer, should be implemented using N-version programming. Because of the currently extremely high costs for medical treatment, especially treatments such as radiation, I think this would be an acceptable suggestion, as N-version programming may be less expensive than self-checking architectures in systems for which a high level of availability is required. This decrease in cost for this technology may then help to lower the cost of radiation treatment for cancer patients. Although development costs would still be high due to the requirement for several different teams to develop different software versions, it would still be cheaper than self-checking architecture and would even add to the reliability of the machine. (This reliability is important because an overdose of radiation to a patient could be fatal.) Of course, this assumes that there is a need for high availability of the machine, which I believe there would be considering the high prevalence of cancer. Although reliability is often valued over availability in the medical field, I believe that both can be achieved in this specific case without the need for compromise.
11.9
You should explicitly handle all exceptions in a system that is intended to have a high level of availability in order to ensure that program exceptions do not cause system failures, as well as to continue normal operation after the exception has been processed. Because the system has a high level of availability, it is consistently relied on to function properly. Each time that an exception cannot be properly handled, someone is losing time and money that could be put towards a better use of time due to something that could have been avoided in the first place.
12.5
Five possible functional system requirements generated from the system safety requirements:
1. The system must allow for user override in case of an emergency or some unpredicted situation.
2. The amount of pressure to be applied to the brakes should be regulated based on current speed of the train and/or distance. For example, a braking that is too hard may also cause safety hazards for passengers, may cause damage to the train or its cargo, etc.
3. The speed of the train should be constantly calculated by the system.
4. A warning should be given to the train conductor in the event that there is a red light and/or the brakes need to be applied. A warning should also be given if there is a change in the speed limit ahead.
5. The system should offer alternate routes (those without red lights) for the conductor to take in the event that a segment of track is signaled with a red light.
By the time I got to the last article for this week’s reading, “Why Software Projects Fail, and the Traps You Can Avoid That Could Spell Disaster”, it was obvious to me how spot-on its list of reasons was considering the failed software projects that we had just read about. What was shocking, however, was how such large companies and organizations could fail so miserably due to not meeting simple requirements as listed by this article, such as having unclear project requirements, insufficient time, and inadequate planning. This was surprising because these appear to be common sense factors to consider when working on any type of work, but especially work that could potentially cost millions or billions of dollars, time, and even people’s lives (such as in the failed Therac-25 cases). Although there may have been bugs in the software that may have contributed to the failure of the software overall, bugs are an expected hurdle in any programming feat. In fact, the article even stated that developers have come to expect failure. The problem with bugs and/or failure is when humans fail to properly address them, such as by giving themselves adequate time for software testing, poor communication between team members, etc. For example, one issue with the spacecraft accidents was not lack of intelligence, but rather lack of communication between team members, so that engineers were not fully informed on how their piece of the puzzle was supposed to fit together with everybody else’s. If there were better communication between these teams, the engineers most likely would have been able to address common concerns across the board and would have been able to adapt their code to better fit the project goal as a whole. Additionally, chapter 13 emphasizes the practice of design for recovery under the assumption that a security failure could always occur, no matter how well-developed the engineer believes the code to be. Another aspect from these readings that surprised me was that the reuse of code from earlier working Therac radiation machine designs contributed to the eventual downfall of the Therac-25 software. Generally speaking, I had always thought that reuse of code was a positive thing that led to more confidence in the code as well as saved time and money. Although the reuse of the code in the Therac-25 system did not turn out how the engineers had expected, the reuse of the code was not the specific problem; rather, the problem was with the engineers who carelessly reused the code without applying its features or lack thereof to the current model at hand. In other words, it seems that most software failures occur not because of the lack of intelligence but because of the failure to follow through with testing and checking up on every single piece of the project (in other words, being detail-oriented). Chapter 14 of the book mentions collaborative checking, which air traffic controllers implement to constantly monitor the work of the rest of their team. This allows any mistakes made by one member of the team to have a much higher chance of being detected by some other member. This not only improves team communication but also ensures adequate testing, which is beneficial for software engineering practices as well. For example, in the FBI Fiasco articles, there was extremely poor communication between teams – to the point where many could not even agree on the exact scope of the project, much less the exact user requirements. However, if a similar system of checking each other’s work had been implemented, all teams would have been on the same page and would have been able to work much more efficiently rather than trying to rush and, instead, find the project behind schedule and over budget in the end. All in all, these case studies have largely illustrated the lesson pointed out in the 2005 FBI Fiasco: “'Well, lesson No. 1: faster, cheaper, better. Pick two, but you can't have all three.”
4.5
Plausible user requirements for:
a. An unattended 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.
b. The cash-dispensing function in a bank ATM.
c. In an internet banking system, a facility that allows customers to transfer funds from one account held with the bank to another account with the same bank.
4.6
An engineer responsible for drawing up a system requirements specification might keep track of the relationships between function and non-functional requirements by creating a relationship schema, such as in database concepts. A similar approach to the relationship schema would allow for the engineer to easily visualize relationships between the requirements. Some revision, such as using squares for functional requirements and ovals for non-functional requirements, may be useful as well.
4.7
Set of use cases for an ATM:
Reflection:
A common concern among the articles includes privacy and safety. In the article about the Tire Pressure Monitoring System (TPMS), the authors point out the apparent lack of concern for the safety of auto drivers due to the lack of security enacted on TPMS, including location privacy risks, lack of input-validation on incoming data, and spoofing dashboard warnings. Although many believed that there was little to be concerned about security-wise, the article points out several very valid security issues. Though some may nonetheless believe the authors’ concerns to be over dramatic, those who seek to act maliciously will find creative ways to do so, and I would never underestimate a person’s potential malice; the extreme lengths and creativity of criminals have been proven time and time again. The Security and Privacy in Your Car Act of 2015, however, seeks to address concerns like the ones brought up in the TPMS article. One point that stood out to me in the act was the fact that users should be “given the option of terminating the collection and retention of driving data.” User override of software is important because bugs and security issues can always exist in software, no matter how well-developed the engineer believes the code to be. Another important point that I believe the act addresses is the required ability to not only detect but also report and prevent the interception of data and/or control of the vehicle. Simply detecting a potential threat does nothing to help the cause if efforts are not made to also report the threat in order to learn more about the threats and to prevent the threat from causing its intended harm. Test-driven development (TDD), as the last assigned reading discusses, would be beneficial in addressing these security and privacy threats by allowing developers increased awareness of and concentration on software requirements in general, including security. The fact that every single line of code is tested using the TDD method would decrease the potential for bugs within software, and the increased emphasis on writing effective tests would aid in security as well by ensuring the proper functioning of all code. In fact, I believe that many, if not all, of the past software failures that we have previously discussed in this class could have been prevented if this method of development were implemented, as it addresses the major problematic themes (i.e. overconfidence in software, unclear requirements, etc.) that appeared throughout each case study of the software failures.
2.1
A system to control antilock braking in a car: I would suggest using the waterfall model as a basis for managing the development of this system because of the safety-critical aspect that a braking system presents for an automobile. Therefore, the specification and design documents must be complete so that security analysis may be performed on the system before its actual deployment.
A virtual reality system to support software maintenance: For this system, implementing the integration and configuration approach may be best because this is a general-purpose system that would have many features in order for it to be able to adequately maintain software, and these types of stand-alone application systems are commonly included in the reuse-oriented approach. Adapting the system for use in specific applications using this method would be much cheaper and more efficient if the main chunks for the system were already developed.
A university accounting system that replaces an existing system: The integration and configuration approach would best support development of this system because many of the functions of the old system would remain the same for the new system since it is an accounting system with a specific purpose. The old system could then be adapted to fit user requirements for the new system, which should include aspects of the incremental development method as well to ensure that the user's likely changing requirements are being met as efficiently as possible.
An interactive travel planning system that helps users plan journeys with the lowest environmental impact: Because user feedback would be crucial to the success of this system, an incremental development approach would be suggested. This method will ease the burden of constant user feedback that will most likely change the requirements of the system while it is in the process of development as well as after it is deployed. Therefore, this approach will make it cheaper and easier to make changes in the software while making it easier to access user feedback in the first place.
5.3
You have been asked to develop a system that will help with planning large-scale events and parties such as weddings, graduation celebrations, and birthday parties. Using an activity diagram, model the process context for such a system that shows the activities involved in planning a party (booking a venue, organizing invitations, etc.) and the system elements that might be used at each stage.
5.5
Develop a sequence diagram showing the interactions involved when a student registers for a course in a university. Courses may have limited enrollment, so the registration process must include checks that places are available. Assume that the student accesses an electronic course catalog to find out about available courses.
5.7
Based on your experience with a bank ATM, draw an activity diagram that models the data processing involved when a customer withdraws cash from the machine.
5.8
Draw a sequence diagram for the same system. Explain why you might want to develop both activity and sequence diagrams when modeling the behavior of a system.
You might want to develop both activity and sequence diagrams when modeling the behavior of a system because sequence diagrams highlight the objects of a system, whereas activity diagrams highlight the operations of the system. This allows for increased ease and clarity in representing and communicating to others the different parts of a system. For example, nonexperts generally find the data-flow activity diagrams easier to understand, while experts often prefer to view sequence diagrams (most likely because of the more detailed information regarding the relationship between objects).
6.4
Draw diagrams showing a conceptual view and a process view of the architectures of the following systems:
A ticket machine used by passengers at a railway station.
Conceptual View:
Process View:
A computer-controlled video conferencing system that allows video, audio, and computer data to be visible to several participants at the same time.
Conceptual View:
Process View:
A robot floor-cleaner that is intended to clean relatively clear spaces such as corridors. The cleaner must be able to sense walls and other obstructions.
Conceptual View:
Process View:
While reading the first four chapters of The Mythical Man-Month by Frederick P. Brooks, Jr., I could not help but notice the similarities between it and past articles that we have been assigned for class homework. Many of the readings that we have been assigned, including this one, discuss the problematic practices that many organizations continue to implement when developing software. Despite the knowledge that these problems exist, organizations continue to ignore the advice given by people like Frederick P. Brooks, Jr., despite their expertise in the field of computer science and software development. Brooks calls a particular aspect of this ignorance to attention when he states that “when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse” (page 14). For example, our previously assigned class readings on the FBI’s fiascos on its journey to a new electronic system prove to be a perfect example of what Brooks is explaining in the first four chapters. When taking Brooks’ words into account, it is easy to see the problematic surplus number of teams working on the FBI project at one time. Not only were there too many people working on the project, but there was also extremely poor communication between the teams. The poor communication was especially evident when some were not even aware of the actual project specifications and limitations. Brooks addresses this communication problem in chapter two’s “The Mythical Man-Month” when he states that “the added effort of communicating may fully counteract the division of the original task” (page 18). In other words, inefficient communication can completely derail the task at hand even when people would otherwise have sufficient knowledge to complete their given task. Another point that stood out to me was the similarity between Brooks’ critique of being overly optimistic regarding the proper functioning of software and limited bugs and Thomas Smale’s warning to software developers to actually expect there to be bugs, as seen in his article, “Why Software Projects Fail, and the Traps You Can Avoid That Could Spell Disaster”. Because of this expected failure, Brooks suggests giving yourself additional time for testing and bug fixes, which all our past assigned readings have also pointed out, either explicitly or implicitly. Despite all the similarities found between these project analyses and articles, organizations continue to repeat the same mistakes instead of learning from the many past project failures. One thing that stood out to me from Brooks’ essays, however, was that project managers often “trim the task” of the project at hand once they realize that the project is running behind schedule. This act of trimming the task occurs either purposefully or “silently” by “by hasty design and incomplete testing” (page 24). Although the rushing of the project design and inadequate testing has been obvious in our past readings on project failures, it surprises me that project managers would cut these things out of the project purposefully, especially after having read about the potentially severe consequences of these actions (i.e. the deaths involved in the Therac-25 radiation accidents). After all this time, it seems that more project managers would learn to listen to experienced developers like Brooks if they want to avoid these types of scheduling failures in the future, possibly implementing his formula for determining a project schedule.
8.7
Write a scenario that could be used to help design tests for the wilderness weather station system.
Joe is a meteorologist responsible for monitoring several of the wilderness weather stations to ensure their proper functioning and to keep up proper maintenance on them. Each Monday morning, he logs in as an authorized user and administrator for his assigned stations. Joe then reviews the collected data for any abnormalities for each instrument. He finds an abnormality in one of the instrument's collected data readings and reports this to the various other teams that work with the system, including the local weather forecasting team. He flags this as an abnormality in the system. Then, Joe ensures that all the data was correctly transmitted to the data management system and reports any errors if not correctly transmitted. Then, Joe visits each station at its location to ensure no physical damage has been done to it or the instruments that may interfere with the proper data collection and functioning of each one. If damage is thought to be done to the station or instrument, Joe takes it back to the lab to be worked on or replaced. If a station or one of its instruments is replaced, Joe must then update the new identification number for the new station/instrument in the weather station system. Lastly, Joe updates his findings for the week to the weather station database.
8.10
A common approach to system testing is to test the system until the testing budget is exhausted and then deliver the system to customers. This approach seems extremely unethical, especially considering the fact that most projects end up over budget to begin with. Testing, as possibly the most critical factor of the software development process, should not be pushed to the back burner to receive what is left over of the budget, especially since testing is often times the last, or one of the last, phases of development for software. Therefore, there would be minimal amount of money to provide for the testing of software when completed in this manner. This becomes an especially important matter to consider when software is developed for people whose safety could depend on it. For example, delivering an inadequately tested system to the health care industry could potentially harm or kill patients, depending on the type of bug that was not found in the testing phase. Even if people's health, for example, does not depend on the proper functioning of the system, it is unethical to knowingly provide somebody software that has been inadequately tested. Ultimately, the customer is paying for the development of software, and this includes a proper testing phase. Otherwise, the customer would not be receiving what they paid for and are expecting to receive.
Reflections on Intro to Testing
One interesting note about this reading is the statement that programmers often believe that the effort put into testing seems wasted if no bugs are revealed. Considering that testing consumes (or at least should consume) at least half the labor put into producing a functioning program, this feeling of wasted effort seems understandable. However, one concept that stood out to me in the reading is the problem of subtle bugs that are not as obvious as "easy" bugs, yet potentially more destructive. Therefore, it seems that if no bugs are found, then effort was not wasted but, instead, most likely not enough. This idea can also be seen in the Pesticide Paradox and the Complexity Barrier discussed in the chapter. Even though it may seem as though something is bug-free and functional, the pesticide paradox suggests that there are most likely remaining bugs that have not been found yet - the aforementioned subtle bugs that were "immune" to previous testing. The complexity barrier adds to this problem, partially due to all the "bells and whistles" that people can't seem to get enough of, causing further complexity in not only the programming but the testing itself as well as discovery of these pesky, subtle bugs. In fact, my dad had previously worked for a software development company that had one of these subtle bugs in their software for years before he even worked there. This bug caused major problems, including having parents of college students pay the tuition bills for students who did not belong to them. This bug occured at least once a week. It was so difficult to both find and reproduce that the company offered overtime pay and provided dinner on special designated nights to any employee who wanted to stay afterhours to try to find and fix the bug. After five years of working there and nobody in the company being able to find the bug, my dad was finally able to discover and reproduce it. Turns out, the difficulty was all due to the extreme amount of "bells and whistles" programmed into the code. This anecdote furthers the author's point and is interesting because it allows for a real-life example of this discussion from the reading.
15.10: The reuse of software raises a number of copyright and intellectual property issues. If a customer pays a 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.
If a customer pays a software contractor to develop a system, the customer would be the most obvious person or group with the right to reuse the developed code. If the software contractor agrees to develop software to give to a customer, the customer can then do whatever he wants to with that software. This could be compared to a person going to the store to buy apples. Before the shopper buys the apples, he is not allowed to do whatever he wants to with the apples because the apples belong to the grocery store. For example, a shopper would not be allowed to eat the apples, throw them away, give them away, etc. without paying for them because they are not the shopper’s apples to eat, throw away, give away, etc. However, once the shopper pays for the apples, he is then allowed to eat them, cook with them, or do whatever he wants to with them because they now belong to the shopper, or customer. The same goes for a customer of software once the software is bought from a developer willing to sell the code. After the software is bought, the contractor should no longer be able to specify what the customer can or cannot do with the software system (unless regulations were previously agreed upon between the contractor and customer prior to purchase, in which case, regulations should be followed by both parties). If the customer then wants to allow others to reuse the code, then I believe they are allowed to do so without the permission of the contractor simply because the system is now the customer’s product that they paid for.
The software contractor should have the right to use that code as a basis for a generic component as well. This is not to say that the contractor has the same rights as the customer, however, to use the code in its entirety however the contractor wants after the system has been purchased. However, using the code as a basis for a generic component seems similar to concept reuse, which is different from copying code line for line. Additionally, different customers are most likely going to have specific needs for their systems that are more than likely going to differ from another customer’s system needs. This results in vastly different software systems, even if the generic components started off as identical. Furthermore, the software contractor should be able to sell the same software system to a customer even if the contractor already sold the system to a different customer, as long as this practice is not previously forbidden by a contract between the customer and developer. The customer is paying for the contractor’s expertise and product, so it would be ridiculous, from the contractor’s viewpoint, to develop a system more than once if it could otherwise be avoided. This would be like a manufacturer of automobiles creating a different model of car for every single customer who wants to buy a car. If a customer wants to have the only copy of a software system, then this should be discussed prior to purchase. Otherwise, the developer should be able to re-sell their developed system to other paying customers. However, it seems unethical for the developer to sell a software system to a paying customer and then release the software for free to others, but this is nonetheless the decision of the contractor. If the customer wants to avoid this situation, then, again, it should be discussed prior to purchase.
To reimburse providers of reusable components, payment mechanisms may be as simple as giving credit to the original developer(s) of the software, such as for open-source projects or free software. The traditional method of payment with money is an option, most likely for companies and independent developers. Royalties would not seem like a great option considering the need for constant maintenance of software and how quickly software becomes outdated, etc. Another payment option may be access to the completed software that made use of the reusable component. Additionally, a barter-like system may be implemented; if the consumer has a set of skills that the component developer does not have, then the consumer may offer a trade of knowledge, such as assistance in a different field within computer science, or any field for that matter, a trade between different types of computer systems, etc.
Another issue with the reuse of software is the question of who has the right to reuse software if a developer is working for a company – does the developer himself have the right to reuse it, is the software the property of the company, both, or neither? Should the developer only have the right to reuse the software for purposes related to enhancement of the company he is employed at, or should he have the right to reuse the software for any purpose he desires since the code was from his own intellect and no one else’s? This issue of reuse is further convoluted if there is more than one person that worked on the software. This is a complicated issue that relies on many factors, such as what type of company the developer works for, the type of software developed, privacy concerns, etc. This issue should be discussed and clearly established for each employer-employee relation, as well as developer-customer relations.
9.8
The three main types of software maintenance include fault repairs, environment adaptation, and functionality addition. Fault repair maintenance is used to fix bugs and vulnerabilities in the code and are usually fairly inexpensive to fix as long as the fix does not involve the need to rewrite several program components or include extensive system redesign. The second type of software maintenance, environment adaptation, adapts the software to new platforms and environments and occurs when a component of the original system environment changes. An example of this type of change might be a change in the operating system on which the software runs. Thirdly, functionality addition software maintenance is implemented to add new features and to support new requirements. A commmon example of this is when user requirements change and, consequently, the software must also be changed. This type of maintenance is often more expensive than the other two types of maintenance, especially because it is harder to change components of software after it has gone through all the software development stages.
It is sometimes difficult to distinguish between these three main types of software maintenance because there is no clear-cut distinction between them. Often times, maintenance needs of another type reveal themselves through maintenance of a different kind. For example, when working on maintenance from a change in the software environment, the software developer may deem it necessary to also add functionality in order to take advantage of the newly implemented environmental features. Other times, the software developer may decide that the best way to fix faults in the software may be to implement maintenance on environmental adaptation or to add functionality. Thus, as one can easily see, the three types of maintenance here are not rigidly defined, can overlap with one another, and can implement a cause-and-effect relationship between the three.
9.10
Software developers have a professional responsibility to develop code that can be easily maintained even if their employer does not explicitly request it. Because of the inherent need of software to adapt and evolve if it is going to remain useful, it is absolutely necessary for the software to be maintained in order to do so. Any software developer would know this to be true, and it would be negligent for the developer not to develop code that can be maintained since maintenance is such a critical component of the lifespan of software. The critical nature for software maintenance is especially evident when looking at legacy systems and how many of these systems continue to be used today; if it weren't for ease of maintenance on these systems, many companies would more than likely be spending large sums of money on new systems more often than is necessary. The maintenance ability for these legacy systems is what keeps companies able to use these systems for longer in the first place.
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.
17.10
Moving from using desktop applications to accessing the same functionality remotely as services could cause slower data transfer for the users, as data transfer takes place at network speeds. Transferring large amounts of data, such as video or high-quality images, also takes a lot of time. Users may not be willing to pay for the same service but with lower quality due to slow data transfer. These risks may be reduced if there was a guarantee of fast network speeds and a guarantee of no large data transfers, although these guarantees are improbable and impractical. However, using web technologies like AJAX and HTML5 may help reduce this risk of slow data transfer times, as these technologies can configure a browser and use it as a client with significant local processing instead.
Another risk is that the provider of the software could stop managing and offering the service. If a business relies significantly on this service, for example, this could be detrimental to the business and it could lose all its previous work and important information needed for success. This risk could be reduced, however, if there were multiple providers of the service. The business should also backup its important data in its own database not managed by the provider of the software in the case that the provider stops managing the service and a different provider still offers it. Another way to reduce this risk is if the provider offers the user(s) the option to buy the software/rights to the software in the case that the provider goes out of business, ceases management/offering of the software or service, etc. This would prevent the user from losing all of its work and critical information, although this could be an expensive route.
A third risk of moving from desktop applications is the possibility of having a service that does not meet the user requirements due to mere assumptions made by the provider. Using the agile method for development may help to lower this risk, as this would allow for incremental delivery and quick evolution of the software after user feedback. Additionally, configurability should be designed into the system in order to reduce this risk. This would allow users more say in their preferences for the service.
18.4: Define an interface specification for the Currency Converter and Check credit rating services shown in Figure 18.9.
Method: Currency Converter This service converts a given amount of money from one currency type to another.
Operation: convert
Input: double/float amount, String originalCurrencyType, String convertedCurrencyType
Output: double/float convertedAmount
Exceptions: input amount not a double, input has too many decimal places, input is null, currency type does not exist, input is a negative amount
Method: Check Credit Rating This service checks a person's credit score given identifiable information for the person.
Operation: checkCreditRating
Input: Integer socialSecurityNumber, String address, String name, Boolean responseToSecurityQuestions
Output: Boolean isThisPersonWhoTheySayTheyAre, Integer creditScore
Exceptions: null response to security questions, invalid SS number and/or address, the person is under 18 and/or does not yet have credit
19.3: Why is it impossible to infer the emergent properties of a complex system from the properties of the system components?
It is impossible to infer the emergent properties of a complex system from the properties of the system components because emergent properties are properties of the system as a whole. Therefore, these emergent properties become observable only after all the system components have been integrated. The reasoning behind this can be further explained by looking at the two types of emergent properties: functional and non-functional. Functional emergent properties occur when the purpose of the system can only be determined after all components are integrated into it. For example, looking only at a bicycle seat and its functionality tells you nothing about the functionality of the bicycle as a whole; the same goes for a complex computer software system. The second type of emergent properties, non-functional, can only be determined from within the system’s operational environment. Outside of the operational environment, these non-functional emergent properties are likely to differ or may not be observed at all (i.e., reliability of a system). Thus, the emergent properties of a complex system cannot be inferred from its system components.
20.10: You work for a software company that has developed a system that provides information about consumers and that is used within a SoS by a number of other retail businesses. They pay you for the services used. Discuss the ethics of changing the system interfaces without notice to coerce users into paying higher charges. Consider this question from the point of view of the company’s employees, customers, and shareholders.
Changing the system interfaces without notice to coerce users into paying higher charges is an overall unethical practice, despite short-term advantages that a company may receive from it. From the point of view of the company’s customers, the customers have agreed to pay for pre-specified services. Changing these services in any significant manner should ultimately break the contract (for either a formal or informal contract), as the service becomes something different than what the customer originally agreed to pay for. Additionally, charging a higher price for these services would ultimately lead to customers searching for a different (i.e., more honest, cheaper, etc.) company to conduct business with. Even if the customer likes the changes better than the old changes, they would more than likely be unhappy about being forced to pay more money for it, and any change would lead to the customers needing to re-learn how to use the system, resulting in decrease in profit for the customers’ retail businesses as well since their employees would need to relearn the system and may even need to take training on it. Additionally, an obvious decrease in profit for the customers would also occur, as they would be forced to spend more money on a necessary component of their business.
From the employees’ point of view, they would ultimately need to do the work that is required of them by their bosses, else risking losing their jobs. However, the employees also fall under the terms of the code of ethics for software engineers. If the employee is aware of what the company’s plans are in changing the interfaces without warning the customers in attempt to make more money, the employee is called to speak up and counter this unethical practice. If worse comes to worse, the employee may even be called to ultimately quit their work at the company.
In examining the shareholder role in this situation, the shareholders may end up achieving their goal of making more money at the expense of the customers. However, this increase in profit may only be for the short-term, as customers are likely to see through the company’s deceptive practices and begin searching for other places to conduct their business. Ultimately, the shareholders may end up losing money in addition to their reputation, which could last for as long as the company is in business. All in all, the risk and breach of the code of ethics is not worth the benefit in the end.
Our team has made great progress on Deliverable #3. We now have a functioning testing framework, consisting of a bash script, driver, and the first five test case text files. Luckily, our team worked consistently on this task instead of procrastinating, as unforeseen problems hindered progress at times, such as hidden, incorrect end-of-line characters caused by differences in various text editors, which made it difficult to locate the bug in our bash script methods. Because of difficulties of meeting in-person to work on the deliverable, each group member was assigned and/or volunteered for specific tasks. This seemed to work well for us. Instead of group members being unaware of the functionality of other group members' code/tasks due to the fact that they did not work on that task, the opposite actually occured since all tasks are interweaved together. In order for each group member to implement their portion of the deliverable, the group member needed to study and have knowledge of the other members' work. In turn, this may have actually allowed each group member to become more knowledgeable of the testing framework as a whole. This method of working together also seems to have increased communication between group members since the tasks of each member were interleaved with the others. The need to review others' work, however, emphasized the need for commenting in code and made me realize the true importance of it. It is much more time-efficient to read comments than to decipher each and every line of code written by another person even if you already know the general idea of what the code should do. This was a challenging yet rewarding deliverable, as it provided me with valuable experience in bash scripting and has given me a decent starting knowledge base of the bash scripting language. We are now ready to take on the challenge of the remaining twenty test cases.
21.4: Explain why an object-oriented approach to software development may not be suitable for real-time systems.
An object-oriented approach to software development may not be suitable for real-time systems due to run times of object-oriented code that may likely delay the real-time systems. This is due to the many interactions between and references to objects. Additionally, different types of programming languages (i.e. object oriented, functional, procedural, etc.) are best suited for different types of problems simply due to the nature of the problem at hand. Likewise, object-oriented programming may not be the best suited to real-time systems development because of similar reasons.
22.6: Fixed-price contracts, where the contractor bids a fixed price to complete a system development, may be used to move project risk from client to contractor. If anything goes wrong, the contractor has to pay. Suggest how the use of such contracts may increase the likelihood that product risks will arise.
Although it may seem as though less risks would arise through the use of such contracts due to the increased responsibility of the contractor, the situation is actually a bit of a paradox. Such contracts may actually increase the likelihood that product risks will arise due to the increased responsibility put on the contractor to get work done as quickly as possible. Once the work is done, the contractor is then able to simply pocket the previously agreed upon price for the developed system. Therefore, the contractor is likely to rush through the development process, including critical steps such as planning before actually beginning work, in order to more quickly reap the benefits of the contract. This rush by the contractors is also likely to lead to cutting corners and settling for “good enough” code when they that the things could be improved. Two grave examples of this may be cutting back on security and testing, which is often overlooked by many software developers to begin with. The client is often unaware that such specifications regarding security and testing should be made if the client is not already familiar with software development. Thus, the finished product by the contractor may completely satisfy the user requirements but will also be filled with security risks and potential unforeseen bugs that the client may or may not recognize, especially not until after they receive the final system.
23.6: Figure 23.14 shows the task durations for software project activities. Assume that a serious, unanticipated setback occurs, and instead of taking 10 days, task T5 takes 40 days. Draw up new bar charts showing how the project might be reorganized.
Thus far, our group has worked very well together. Communication regarding progress on tasks between all three group members could be improved, but communication could always be improved among any group working together on a task. As our class guest speaker, Joye Nettles, put it, members of a group should over-communicate with the other group members. Nonetheless, this is minor, and I think that we are doing well as long as this is the least of our worries. One thing I appreciate is that we, as a group, do not tend to procrastinate on the deliverables. We were able to successfully complete deliverable #4 and are now prepared to begin work on deliverable #5 and injecting faults into our tested code. The different skillsets of each group member has been valuable, and I believe that we are all still learning new things and gaining valuable experience from working on this project and learning how to rely on others as a team. This is especially valuable if we are expected to work on teams once we begin work after graduation.
24.6: Explain why program inspections are an effective technique for discovering errors in a program. What types of errors are unlikely to be discovered through inspections?
Program inspections are an effective technique for discovering errors in a program because the reviewers may have even had experience in writing bits of the code itself or code that is similar to it. Additionally, assuming that the team looking through the code has experience in coding, the team is likely to catch errors that are common for programmers because they have learned this from their own experiences in coding. Working as a team, versus just one single person, is also beneficial because it introduces different ways of thought so that there are numerous people that can look at the code in different ways that other people may not look at it, finding errors/bugs as a result. Because the code is not actually ran while the team is looking at it, sneaky syntax and runtime errors are unlikely to be found, however, as well as subtle logic errors that often fall through the cracks when looking at the big picture of the code.