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.

I think that many of the issues raised with software reuse could be solved with contracts.  If a customer pays the contractor to develop the system, the contractor who is developing it will create a contract regarding reuse for the specific system being developed.  If they want to include no-reuse policies, reuse for a fee policies, or specific parts that can be reused for free vs. paid, they are able to do so.  Contracts are important to many different aspects of our every day lives because they can protect our rights in so many different situations.  Without a contract, the reuse of software becomes really confusing and difficult to manage.  I think that if a customer pays a software contractor to develop a system, and no contract is in place to have an agreed upon plan for its reuse, then both parties should be able to reuse the system.  The contractor should be able to because they wrote/created the software in the first place.  It is “theirs” to reuse in the future.  The customer should also be able to reuse the software since they commissioned it, it is “theirs” as well.

The providers of reusable components could possible be paid a one-time fee for the reusable components.  It could also be possible that the payment could be figured on a rental type of payment plan.  For as long as the software is being used, the team or company who developed the software will be continuously paid.

It is important for software to be able to be reused.  Costs of software development can be significantly reduced and its speed and rate of development is greatly increased as well. Considering the complexity of today’s software, it is only expected that in the future, that complexity will grow.  With the ability to reuse, we can eliminate wasted time, money, and overall efforts while increasing quality and time for products to be user ready.  Although there are many ethical issues that will undoubtedly arise surrounding the topic, with the increased use of contracts, and actively discussing the issue before the development of the software, both sides can agree in writing to a plan.  Whether to reuse the software and who has the rights to do so, can be tackled in the beginning of the engineering rather than be an issue in the end.

Testing is extremely important in software engineering and architecture for many obvious reasons.  In order to ensure that a product is not only efficient in its operations, but also does what it is intended to do, the product must be tested thoroughly.  There are many issues that can arise in testing and cause it to be a difficult process.  Many of these problems are related to funding; often times people do not have the finances necessary to perform adequate testing on products, and are forced to push code sooner than they ought to.  Other issues can simply be related to the complexity of a project. If a project is extremely complex, the testing is also very detailed as well. In this scenario, it is very likely that the testing, although maybe thorough, missed some bugs in the code that may not be discovered until a later time.

I enjoyed reading about the different kinds of testing. I think the idea of break-the-software testing makes a lot of sense, when a user tries to break the software intentionally, they may be more likely to try inputs and values that are outliers and could have been overlooked in the initial design process.  Also, scenario testing seems somewhat sensible, but also limited and juvenile, in a sense. Sure, a tester may be able to read the scenario and use that to create testing for a program, but it seems like specific scenarios or details are likely to be missed. I think that acceptance testing is the most effective of the testing mentioned in this chapter, at the end of the day, if the user who will actually be working with the program, decides themselves that the software is good enough to be used, who is anyone else to say otherwise.

From the article entitled “The purpose of testing,” I really enjoyed the steady growth seen in the different phases which start with no difference between testing and debugging and end with testing being “a mental discipline that results in low-risk software without much testing effort”.

I also thought that the breakdown of testing into three different categories was an interesting thought.  Unit, component, and integration testing as different levels seem to be a good way to view testing. Unit testing is the simplest, testing individual units first. Then, once those units are put together, we can test the components to ensure that they are working properly together.  Finally, we can perform integration testing, once the components are put together, to be sure that the different components are all acting as they are supposed to.

8.7: Write a scenario that could be used to help design tests for the wilderness weather station system.

George is a reporter for the wilderness weather station. One of his responsibilities is to go to the weather center every day and observe the weather in order for the weather to be reported properly.

Each day, he arrives at the wilderness weather center and begins to examine the details of the day.  He reads the thermometer as well as the barometer, he records based on visual examination as well, how clear is the day? Is there a lot of sunlight. How does it feel outside? Dry? Humid?

George logs in to the to the weather and his prompted for his password.  He begins to enter all of the requirements of the daily log and is prompted with a warning that states a thunderstorm is likely in the near future. So, George must remember to report the likelihood of a thunderstorm.

After recording the information, George reports through e-mail the daily weather and the expectations of the next few days to the necessary outlets. George has completed his day.

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. Discuss the ethics of this approach for systems that are delivered to external customers.

There are major issues with the ethics of this approach since the external customers do not have any control over the testing budget of the testing company.  For example, it is possible that company A has plenty of money allocated to testing, and they are more than able to complete the testing that is needed for their external customer, there are no issues.  However, if company B does not allocate enough money for the testing budget, and they hit their limit sooner than expected, they will be forced to quit system testing and go ahead and deliver the product to the customers. This will obviously result in possible system errors and leaks in the product. Errors in the product can snowball into major issues, especially if the company was testing software related to a field such as medicine, finances, or politics.

The first four chapters of Mythical Man Month were very entertaining.  I thought most of it was very sensible, although at times a bit whimsical.  In the opening, the reader sees large system programming analogized to a tar pit.  The author continues to describe the attributes which attract people to the field of computer programming such as the joy of the craft.  He describes that people enjoy. making things that are useful to others, they become fascinated with creating detailed programs of many dependent but constantly moving parts and watching them work cohesively like a “castle in the air” (Brooks 7).  Brooks also mentioned that most programmers are optimists.  He says that it can be difficult to decipher whether this is because optimists are naturally attracted to the field of programming or if all others are driven away by its difficulties.  Later in the text, when discussing planning, the author describes how there are almost almost more bugs than anticipated…due to the optimism.

The next topic discussed, which is the bulk of the reading, is related to the Man-month.  Man-month is a unit that is used to measure scheduling needs.  It is simple, as a job becomes more demanding, the need of more men or more months goes up.  They are interchangeable, according to the concept.  However, Brooks points out that this could not be further from the truth when dealing with a topic like computer programming.  He discusses how the Man-month is true for work akin to farm labor, in which workers do not need to communicate with each other.  However, in a field such as computer programming, in which intercommunication between workers is crucial, the the Man-month concept fails.  Although I didn’t feel like it was a great analogy, he uses childbirth for comparison: no matter how many more people, or women, are added to the equation, childbirth still takes nine months to completion.  It was stated that adding more workers in computer programming can actually increase, rather than decrease, the time that it takes to perform a job to finish since the amount of communication necessary increases significantly with larger teams.

One section that I really enjoyed reading was about the breakdown of a programming job: 1/3 for the planning, 1/6 for the coding, 1/4 for components and early systems test, and the final 1/4 for the system test with all of the components in hand.  There is much more to the final product than the coding alone.  Brooks describes how to efficiently divide a large project: divide it into segments that are then assigned to different teams.  Organize the teams like one would organize a surgical team.  In surgery, only one person is actually performing the cutting, the others are simply there for support throughout.  The chief programmer is the surgeon, the co-pilot is the second-in-command.  There is also need for administrator, editor, secretaries, clerks, toolsmith, tester and a language lawyer.  By employing a variety of jobs to a small group only handling one segment of a large job, a manager can ensure that there are less people coding which creates better conceptual integrity.  This conceptual integrity can be achieved by a simpler and more straightforward process.

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.

A computer -controlled video conferencing system that allows video, audio, and computer data to be visible to several participants at the same time.

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.

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 systems 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.

The article written by Saurabh discusses 11 different predictions for the future of programming.  In general, I definitely agree with the author regarding the ideas presented.  Some of the points that I most agree with are  consoles everywhere, machine learning progression, and IoT concerns growing.

Saurabh talks about the growth of smart devices, specifically mentioning hairdryers and toasters.  I think that it can be easy to forget the vast amount of smart devices that exist, if we don’t use many of them, however, I once had the opportunity to stay at an AirBnB in Portland, Oregon which I’ve jokingly called the “smart house” and was able to see, first hand, how far these devices have come.  I was staying in a shared home, meaning that the space was available to different renters on the same night.  The owners of the home lived in the downstairs portion and had three bedrooms upstairs with a shared bathroom all listed on AirBnB.  I was staying in one of those bedrooms.  Upon making the reservation, I was auto-messaged a set of instructions describing the app I needed to download for their smart lock at the front door.  The central heating and air was controlled by the “Nest” application and locked to users such as myself without access.  Each room had it’s own Amazon Alexa for music, alarms, etc.  The shared bathroom used a smart toilet, which is capable of using only the appropriate amount of water per flush as well as heating the seat remotely.  I think that as the devices become more widely available and more affordable, we will be more open to using them in our everyday lives.

That leads to the next idea, of IoT concerns.  IoT, or Internet of Things, refer to devices that connect to the internet for some sort of data transfer.  All of these devices mentioned previously, the toilet, the smart door lock, the Alexa, the nest, etc. access the internet for shared data.  With this internet access, comes the possibility of an intruder gaining access to these devices and using them maliciously.  Although most of us wouldn’t be worried about someone gaining access to our smart toilet, after all, what could they possible want to do with our toilet?  But, what if the access to that toilet could somehow bridge the access to our smart front door lock? And the hacker was able to let himself into our home with a device from a mile away by simply gaining that initial access to our toilet?  The security of these devices are going to become increasingly important with their increasing use.

Finally, I think that the idea of machine learning is really interesting and makes a lot of sense to become a growing area for the future of technology and software engineering.  As we find ways to increase the capabilities of computers and other IoT devices, at what point will we be able to program them to learn more, and learn more faster.  We already see examples in targeted ads on our devices, we may search for a new winter coat, and all week might see ads related to winter clothing from that one simple search.  One day these computers will be able to go a lot further on their own, maybe one day in the not so far future, our personal robots or digital assistants will know more about us than we would like them to.  Hopefully, the machine learning doesn’t displace too many jobs.  As a CompSci major, the idea of job growth in the field is something that has attracted me to the field, and thinking about the loss of many jobs due to machine learning is less than attractive although a reality for sure.

2.1: Suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems.  Explain your answer according to the type of system being developed:

A system to control antilock braking in car

The waterfall model

Since the waterfall model presents the process of development as a cascade of stages from one to another, its allows for precise planning which is needed in a tedious program such as system to control antilock brakes.

A virtual reality system to support software maintenance

Incremental development

Since software maintenance is ever-evolving, matching it with a software process model like incremental development, which is also a developing process is sensible.  Incremental development uses new updates/versions of the software until the desirable system is configured which seems like it could work well with a VR system for software maintenance.

A university accounting system that replaces an existing system

Integration and configuration

Due to the fact that there is already a working system, and the goal is to replace it, it makes a lot of sense to use the integration and configuration approach.  This relies on the reusability of other systems or of their components in the building of the new system.  

An interactive travel planning system that helps users plan journeys with the lowest environmental impact

Incremental development

Since research can be done up front to begin the development of a system such as this interactive travel planning, but cannot finalize it, an incremental approach makes the most sense.  With user interaction and user traveling to continuously develop the program, a high-functioning travel planning system can be achieved over time.

In this discussion, we are reviewing a few very different articles that can be tied together under the themes of software security issues and thorough testing.  One of the readings is the “Security and Privacy in Your Car Act of 2015.”  It lays out cyber security issues for vehicles that are mandated as of 2015, including but not limited to, all vehicles as of a certain date containing a cyber dashboard which displays an easy-to-understand display of the cybersecurity and privacy of the information in the car.  The vehicle will also share which information it is collecting from the car to the driver/owner of the car.  The owner of the car can terminate the collection of this data, and still have use of all navigation equipment, but can not terminate the collection of the safety data that may be needed for accident reviews such as attempts at avoiding an accident or emissions testing, etc.

A second article is titled, “Security and Privacy Vulnerabilities of In-Car Wireless Networks: A Tire Pressure Monitoring System Case Study.”  This article discusses the mandatory tire pressure monitoring system in all cars throughout the U.S. and Europe today, and how these are susceptible to hacks.  Although they do provide quality information to the driver of the car, if a hacker gains access to these systems, and can falsely display a low tire pressure sensor from a following car, for example, it can cause a driver the need to pull over to check a tire.  Once the driver pulls over, the following car or hacker of the TPMS system, can execute an attack of some sort on the car and it’s driver.  It has been proven that these systems can be accessed remotely, from outside the vehicle it is installed in, up to 40m away.

The final two articles are very different from the first two.  One is about Test Driven Development.  TDD is all about writing only enough code to write a corresponding test suite for the code.  The initial code is intended to fail the test.  Once the test is failed, the writer can return to the code and augment it to pass the test.  Once the test is passed the developer can add to the testing and add to the actual code incrementally to ensure quality code.  The idea is that you write your testing before you write your functional code.

The other is about the magical number seven and the amount of information that an average human can contain in their minds and short term memory.  Obviously varying from person to person, however, the amount of information we can store is very limited, often less than we may think.

In reviewing these articles, I think that due to the limitations of the human mind, a concept such as test driven development makes a lot of sense in software architecture due to the complexity of modern programs.  If we try to complete functional code and write testing later, the ability to test all of the code in a good manner, can become extremely difficult, if not impossible.  By recognizing the limits of our human ability, and employing quality testing such as TDD, we can improve on systems such as the TMPS in cars

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.

Function – delivers gas and charges the credit/debit card
Description – delivers the proper amount of fuel specified by the user and charges amount of money to card swiped
Inputs – amount of fuel and card information
Source – fuel amount from user, card info processed from the reader
Outputs – proper amount of gas
Destination – gas pump
Action – user inputs the amount of gasoline desired, and then swipes card. The machine dispenses fuel through pump, measuring output until it is correct, then shuts off. The machine calculates the cost of the transaction based on this amount and charges the user’s card.
Pre-condition – need gas in the car and card is valid
Post-condition – car has gas and card has been charged
Side effects – n/a

The cash-dispensing function in a bank ATM.

Function – dispenses cash to user
Description – reads information from card and provides the specified amount of cash, debiting from the user’s account
Inputs – account information via card, amount of money wanted to take out
Source – card scan, user input
Outputs – proper amount of cash
Destination – cash goes to user, transaction info to the bank
Action – user scans debit card, ATM reads account information. Machine prompts user for an amount to debit, and deducts amount from specified account, dispenses cash to user.
Pre-condition – card is validated, there is sufficient cash in the ATM, and user’s account has enough money to cover transaction
Post-condition – the user’s account has been debited for amount specified
Side effects – none

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.

Function – transfer funds from one account to another
Description – debits account ‘A’ and credits account ‘B’ with no money unaccounted for after transaction
Inputs – bank account user login, amount/account to be debited, account to be credited
Source – user input
Outputs – the correct amount of money to account ‘B’
Destination – money to account ‘B’, transaction info to banking facility
Action – user logs in, user chooses account to begin action, user specifies action is ‘transfer’, user chooses amount to move, user selects account destination, user submits process
Pre-condition – login information is correct, user has sufficient money in account ‘A’ to cover transfer to account ‘B’
Post-condition – account ‘A’ has been debited, account ‘B’ has been credited
Side effects – None

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.

When initially listing the requirements for the system, keep the functional and non-functional fully separate and consciously decide where each requirement should go.  As the full list of requirements develops, review the two lists: functional and non-functional, and make sure that each requirement is in the correct list.  With consistent reviewing and thought concerning each item in the list, the engineer can keep the two lists separated despite the fact that they are not always as clear-cut as one might like for them to be.

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.

withdraw – enter card into ATM, enter pin when prompted, choose ‘withdraw’ from main menu, choose fast cash button of desired amount or custom amount.  If custom, type amount desired to withdraw.  Select finished with transaction and remove card.

deposit – enter card into ATM, enter pin when prompted, choose ‘deposit’ from main menu, input amount to deposit.  Deposit check/cash, no more than 50 bills.  Select finished with transaction and remove card.

check balance – enter card into ATM, enter pin when prompted, choose ‘check balance’ from main menu.  Balance should be displayed.  Select finished with transaction, remove card.