Posts

Showing posts from September, 2019

HW 15: Chapter 15

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. Business Ethics(in software) The ethical reuse of software is an interesting topic that made me think about other industries and how they develop new products or technologies and how that related to software development. I think one of the first issues to tackle is the legal aspect of the situation. If a company contracts the services of a software contractor and in the terms explicitly forbids the reuse of the software they develop while working on their project then the contractor is obligated to perform their services i...

HW14: Testing Reflections

Image
I can recall early on in my computer science college education being told about the importance of testing. Oddly enough, I don’t recall ever being taught how to do it, or why it was so important until CSCI 362. While it seems apparent why testing would be important when creating a complex system or product, there are unique circumstances in software development that require more of an explanation to understand its importance to its success or failure. As I was thinking through some of the way’s software testing might be different from testing, say a new bicycle design, it became apparent that software testing would likely be more complicated for a few reasons. Testing Reflections Don't Think They Tested For This. First, the number of possible ways to interact with a software system is practically limitless whereas with a bicycle it is expected that the user will interact with it in a limited number of ways. This may seem like an oversimplification, but the same could...

HW13: Chapter 8

Chapter 8: Software Testing This chapter went over development testing, test-driven development, release testing, and user testing. The first question below was interesting to do as the scenarios in the text had user interactions and that made it easier to visualize how the system may be used. The wilderness weather system does not interact with a user, therefore, the scenario revolved around what the system might encounter in daily operation.  8.7. Write a scenario that could be used to help design tests for the wilderness weather system. A particular wilderness weather system is to be accessed by satellite uplink. The wilderness system collects its readings from the Anemometer, Barometer, thermometers, rain, sunshine, and visibilities gauges. Due to inclement weather, the wilderness weather system has not transmitted this data over the satellite link. The weather in the area of this system is very frigid with low visibility and has had to pause instrument operation to gene...

HW8: Chapter 2

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 a car The antilock braking of a car is a safety-critical system and therefore it seems the most appropriate model would be the waterfall model. The requirements analysis and definition of the system would be necessarily thorough and extensive documentation for the approval process would be expected. Also, the requirements for the system would remain relatively static, an area where the waterfall model excels. This is the most 'formal' model presented in the text. A virtual reality system to support software maintenance Integration and configuration would allow for a sufficiently generic yet modifiable program. Because the system may be used in different software environments having increased adaptability is cruci...

HW12: Mythical Man Month

Image
MMM The Mythical Man Month, written by Frederick P. Brooks in the mid 70’s, gets straight to the heart of flaws in the way people then, and to some degree now, may think about software development.   Much like his No Silver Bullet , Brooks uses colorful language and analogies to describe the development process and its flaws. The term tar pit still evokes an image of floundering dinosaurs in their “mortal struggle” and Brooks uses this term to describe the current state of large-system programming; teams struggling to meet deadlines, budgets, goals. The five reasons Brooks outlines as causes for these failings are poorly developed estimating techniques, assumptions about manpower and months being interchangeable, lack of stubbornness, bad schedules, and poor responses to schedule slippage. Approximate? Admittedly, I have put little thought into the development process in large scale efforts of software engineering despite having been involved in non-software related govern...

HW11: Chapter 6

Image
This is my take on the conceptual and process views of 3 different machines. I found myself having difficulty distinguishing between the two in some instances. I seemed to want to go directly to the process view and skip the conceptual view altogether. I'd like to find some simple, real-world examples of conceptual and then process view diagrams of the same system to see the differences. 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. %3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2...

HW10: Chapter 5

Image
System Modeling 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. This diagram does not include food, drinks, decorations, chairs, equipment, DJ, photography, or the other myriad of things possible at a party. It simply goes through the process of determining the size, date, venue, guest list, and invitations.     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 a...

HW 6: Chapter 4

Requirements Engineering 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 system should display instructions about the fueling process that progress as the process unfolds. (Swipe card > Select fuel type > Select amount of fuel required > How to dispense fuel) The system shall monitor or detect the swiping of a credit card to begin a transaction.  The system shall ask the customer the type and quantity of fuel required. The system shall check fuel levels available to be dispensed are adequate to fulfill requested fuel amount prior to charging the customers card.  The system shall ensure funds are sec...

HW:7 Reflections

Better than Goldfish, but Not by Much The four articles: The Magical Number 7 , Tire Pressure Monitoring System , Spy Car Act of 2015 , and Test-Driven Development  were interrelated in an interesting way. At first, I had a difficult time understanding where The Magical Number 7 fit in this group but after a short time, I realized how the research on attention spans and memory in the article was related to Test-Driven Development. Essentially, The Magical Number 7 is explaining research done in the 1950s that gave some insights into the short term memory and attention spans in average humans were relatively stable across a wide range of people. The key takeaway, and how this relates to TDD, is that human beings have short attention spans and as our knowledge about the subject lessens our ability to recall information decreases precipitously and because of this TDD is an ideal tool to work with that limitation. TDD works by limiting the amount of new information the developer nee...

HW5: Reflections

Common concerns in the articles and reflect upon them Common things I found throughout the four chapters and several readings were that systems require reliable, safe, and secure systems and the best way to obtain and maintain these systems is through a systematic approach do design, development, and deployment with reliability, safety, and security as focus areas. The Therac-25 Accidents article shows how a failure in the development of software can have potentially lethal consequences. Had the engineers developing this equipment used techniques such as n-version programming or more thorough safety verification processes there is a higher probability that the accidents would not have occurred. There were repeating themes throughout the chapters such as reliability, dependability, safety and security, etc. This was the case when discussing reliability engineering, safety engineering, security engineering, and resilience engineering. Each section discussed the importance...