Problem 1.17 p. 31
The product should have been conceptualized and designed with an open architecture. This is a type of architecture that allows for modifications to be made to either one or more components without any form of significant disruption of all other elements or the product’s overall operation/performance (Strei, 2003, p.5). In this case, it should be quite possible to include additional routines to the ones that are tasked with modifying the queue. Such a task is considered to be relatively simple and it’s better that starting the whole project from scratch.
Problem 2.17 p. 68
The software model that should be used for the Osric’s Office Appliances and Décor product is the iterative-and-incremental life-cycle model. This is due to various reasons. The first reason is that it offers the developers a mechanism for checking that the given software application is correctly designed and implemented. The second reason is that it allows for easy mitigation of risks. Thirdly, it allows for the determination of the sturdiness of the chosen core architecture with relative ease and at an early period of the product life cycle (Schach, 2007, p.42)
Problem 3.10 p. 100
If Osric’s Office Appliances and Décor Product were designed by an organization by an organization at CMM level 1 then it would most likely take a longer period to complete while also costing more. The product would also contain several instances of residual faults and be extremely difficult to implement and maintain.
Problem 4.10 p. 119
All of the teams or organization that are described in Schach’s (2007, p.117) Chapter 4 ( democratic, classical chief programmer, modified chief programmer teams, modern hierarchical programming teams, synchronize and stabilize teams, agile process teams, open-source programming teams ) would probably work in designing the product. The inability to impose democratic team framework./structure is its main weakness or disadvantage.
Problem 5.12 p. 146
Paul, Quentin and Rachel must all make local copies of the affect models (four in number). They should then freeze the most current version of the four modules in turns, make appropriate changes and then have those changes tested by the software quality assurance (SQA) department. The changed or modified version should then be treated as the baseline or benchmark version of the product. Local copies of the baseline version should then be distributed to the rest of the maintenance programmers. It is important for the baseline version to be under the tight control of the manager in order to ensure that the specific procedure for producing them is followed to the latter in the complete absence of the automated tool.
Problem 6.17 p. 174
Measuring utility
The designed product should be availed to the end-users so that they can use and experience it. This would allow them to determine its usability (ease of use/use friendliness) and whether it is able to perform its core intended functions. If it fails the usability test then it would not be used or deployed.
Gauging reliability
The designed product should be tested with different arrays of data. Should there be any form of failure, then its effects as well as the time and efforts required to correct it are to be accurately documented / recorded.
Gauging sturdiness
The designed product should be run or executed with inputs that totally violate the prescribed input specifications (for instance a string where an integer is expected). This should be done in order to determine if it fails or seamlessly handles the data. In this test, it is also advisable to test if a valid user command would generate undesirable outputs or results.
Performance measurement
During this test, storage space should never be an issue. Timing tests must however be carried out in order to determine how much time is taken by the program in computing various quantities and generating various reports.
Gauging correctness
This can be tested by running tests and performing random inspections. Test cases with known outputs should also be ran in order to check if the final output matches the expected results. This can only be done by testing if the product is correct and fit to its purpose. Non-execution based testing and execution based ones can be used to achieve this purpose.
Problem 7.18 p. 216
Modules of functional cohesion:
obtain_customer_information, and the print_invoice module
Classes that I expect to find:
CustomerClass and ServiceRequestClass
Problem 8.19 p. 247
Classical paradigm
Report routines and data input routines
Object-Oriented Paradigm
ServiceRequest Class, Customer Class
The reusable parts of the product – For the class and OO paradigm, it could be possible to reuse component parts such as software project management plan, specification document, test cases as well as the product design.
Problem 9.13 p. 279
Appendix A is a rather informal display or exhibit of the customer’s requirements. It is not possible to come up with duration or cost estimate until such a time that a specification document has been drafted
Problem 10.17 p. 329
A requirement workflow is important to be performed in order for us to determine the software that Osric’s Office Appliances and Décor needs (Schach,2007, p. 285). The initial step in the determination of requirement workflow is the understanding of the appropriate application domain (This involves investigating the nature of environment where Osric’s Office Appliances and Décor’s product would operate in). The process of determining the requirements is iterative. The next step is requirement elicitation and it involves understanding the actual nature of client requirements. The business model is the drawn and subsequently the requirements too are drawn. This is done until the requirements are satisfactory.
Understanding the domain
At this stage, we must come with a suitable mechanism for familiarizing ourselves with what is needed. The best way is to construct a glossary of all relevant terms.
| Block | A unit of work done by technicians within a period of 4 hours |
| Computer | An individual of company requesting Osric’s services |
| Decor | Office decorations arm of Osric |
| Executives | Senior and top most managers |
| High-Speed Data Link | High speed internet or intranet link |
| Invoice | A special billing report that is sent to the client for services offered |
| Job | Services offered |
| OOA&D | Osric’s Office Appliances and Décor |
| Outstanding Job | A request that is still in the pipeline |
| Priority | Order of importance and service delivery (designated 1 to 4 with 4 being the highest priority) |
| Rate | Cost of service to client |
| Redecorate | A service for redecorating executive’s offices by Osric |
| Service request | A request for service by client that is entered into the computer system |
| Shift | A period of time that Osric’s technicians are expected to work |
| Statistics | Shift data |
| Technician | An employee of Osric’s telecommunication arm |
| Telecommunications | Technology and communication industry |
| Turnkey Services | Complete services to clients |
| Waiting List | A list containing pending service requests that are yet to be completed by technicians. |
The next step is the generation of use case diagrams.
The next step is the generation of use case diagrams
Fig 1. Osric’s use case
Fig 2. Print Reports
Fig 3.Technician management use case
References
Schach, R (2007).Object-Oriented Software Engineering, McGraw-Hill, New York
Strei, TJ (2003). Open Architecture in Naval Combat System Computing of the 21st Century. Accessed on August,17th, 2013 from http://www.dodccrp.org/events/8th_ICCRTS/pdf/043.pdf
