Posts

Showing posts from November, 2019

HW27: Chapter 25

25.10.  Describe five factors that engineers should take into account during the process of building a release of a large software system. Competition – If there are different companies competing in the same market then they should make sure that they add any features necessary to make their system more valuable to consumers to prevent market share loss. Marketing requirements – It is important to be aware of the details of the system that is being marketed to consumers, as marketing advertisements will give current and potential customers and idea of what the system will be able to do upon release and will most likely take their business if their needs and expectations are not met. Platform changes – The platform on which a system is being released is likely to be changed at one point or another and it is important to ensure that the system being produced will be able to run on the most current version of the platform. Technical quality of the system – The system sho...

HW26: Chapter 24

24.6.  Explain why program inspections are an effective technique for discovering errors in a ­program. What types of error are unlikely to be discovered through inspections? Program inspections are an effective technique for discovering errors because they allow for peers to review code and find bugs whereas testing only determines that bugs exist. Additionally, program inspections detect approximately 60% of bugs in a program while testing detects about 25%. However, if a developer and an inspector both misunderstood a system requirement in the first place, then any bugs resulting from that misunderstanding are likely to be missed in an inspection.

HW25: Team Progress II

Team Steve has made great progress since the last deliverable. The script is complete and now displays the date and time of completion of each test case and the test cases now accept a user defined description for each method being tested. The html report has been formatted to display the information in a table that is much easier to read than the blocks of text we had previously. All of our test cases have been completed and we are now injecting faults into the Glucosio code for our next deliverable.

HW24: Chapter 23

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

HW23: Chapter 22

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. Fixed-price contracts may increase the likelihood of product risk because the contractor will be responsible for any additional cost beyond the amount that they won the bid for and they might forgo some aspects of software engineering in order to deliver a product in budget on time. For example, the contractor might not put as many resources into testing their system if they believe that they will go over budget because, as we’ve read, software projects can easily go over budget, and testing makes up a large part of the budget. This would result in a product that is complete but not tested and therefore prone to more bugs than normal.  

HW22: Chapter 21

21.4.  Explain why an object-oriented approach to software development may not be suitable for real-time systems. A real-time system will need to have interactions between its components that are as quick as possible. In object-orientated software, objects have to interact with each other and while an individual interaction between two objects might be fast, the time it takes for each interaction to be completed adds up, and having multiple objects needing to interact with each other to achieve a desired output would not be time efficient and would cause deadlines to not be met, resulting in system failure.

HW21: Team Progress I

Our team, Steve, has overcome a few obstacles and now has deliverable 3 complete. Our driver is complete and was designed from the beginning to be able to accept any of our five methods being tested so we already have a good start on deliverable 4. The scrips is nearly complete. It functions properly but it still needs to provide some additional information, such as date and time, when the test cases are completed. The html report is nearly complete, it only needs to be formatted to display the information in a table instead of just listing it on the html page. Overall, the team is continuing to make significant progress.

HW20: Chapter 20

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 interfaces of the system without notice to coerce customers to pay more for the service is clearly unethical as, if it wasn’t unethical, then it wouldn’t have to be done without notice in the first place. The ACM code of ethics states that software engineers should be honest and trustworthy and to “ provide full disclosure of all pertinent system capabilities, limitations, and potential problems to the appropriate parties. ” Customers would most likely be angry with the service provider and choose to change providers. If changing provid...

HW19: Chapter 19

19.3.  Why is it impossible to infer the emergent properties of a complex system from the properties of the system components?             The emergent properties of a complex system come from the interactions of the system’s individual parts. Even if you know how each part acts individually, it is not possible to know exactly how the parts will interact with each other until they are implemented in the system.

HW18: Chapter 18

18.4.  Define an interface specification for the Currency Converter and Check credit rating services shown in  Figure  18.7 Currency Converter <interface name = “CurrencyConverter”> <operation name = “ConvertCurrency” pattern = “wsdlns: in-out”> <input messageLabel = “In” element = “ratens: ExchangeRate”/> <output messageLabel = “Out” element = “ratens: USDRate”/> <outfault messageLabel = “Out” element = “ratens: InDataFault”/> </operation> </interface> Check Credit Rating <interface name = “CheckCreditRating”> <operation name = “checkCredit” pattern = “wsdlns: in-out”> <input messageLabel = “In” element = “creditns: SocialSecurityNumber”/> <output messageLabel = “Out” element = “creditns: CreditRating”/> <outfault messageLabel = “Out” element = “creditns: InDataFault”/> </operation> </interface>

HW17-B: Chapter 17

17.10.  Your company wishes to move from using desktop applications to accessing the same functionality remotely as services. Identify three risks that might arise and suggest how these risks may be reduced.             One risk would be the reliability of the remote service. It is possible that the service could become unavailable, through no fault of the company, and remain unavailable for an unknown period of time, preventing the company from completing any work. One way to mitigate this risk is by having a backup remote service in case one becomes inaccessible for any reason.             Another risk is the vulnerability of information on a network. By using a remote service, information and computers on the network can be vulnerable to hackers more easily because if a hacker were to gain access to a computer on the network, they could gain access to the whole...

HW17-A: Chapter 16

Image
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. Call Logging Component Vehicle Discovery Component

HW16: Chapter 9

9.8.  Briefly describe the three main types of software maintenance. Why is it sometimes difficult to distinguish between them? Fault repair – This is the maintenance of fixing and repairing errors. The types of errors are coding errors, which are the cheapest to correct, design errors, which can require changing components in a system, and requirements errors, which may require redesigning an entire system. Environmental adaptation – This is the maintenance required when a system’s environment changes. Types of changes include hardware, operating system, and supporting software changes. Functionality addition – This is the maintenance required when system requirements change due to organizational or business changes.             It is sometimes difficult to distinguish between the three types of software maintenance because they often related to or caused by one another. For example, an environmental change, ...