Issuu on Google+

ToolsAll: Sample Responses for the Case Assignments Chapters 1-4 The assignments included in the original case description and these sample responses are by no means all that could be assigned for this case; the ones actually selected represent the author’s priorities in teaching these subjects. The Part 1 assignments, Chapters 1-3, include most of the topics of these chapters. In the Part 2, Chapters 4-6, assignment emphasis is placed initially on the development of a comprehensive set of use cases and domain classes, after which two situations are selected for more detailed requirements: 

The sale’s transaction with a variety of payment options allows a view of some real world operations that are reflected in the programming structures of sequential operations, iteration, and branching. An activity diagram and system sequence diagram of this transaction are required.

The stocking and restocking of product items in the new sales, rental, and used sales inventory, which was mentioned as a significant problem in the operation of ToolsAll. For the assignment of this situation the statechart is considered the most appropriate document.

Part 3 Chapters 7 assignments focus almost exclusively on these two situations with the development of a sequence diagrams for the sale’s transaction and a design statechart for the inventory reassignments. Chapter 8-12 assignments then take a global view for ODL definitions for the classes involved in these reassignments, menu hierarchies, and integrity and security controls.

1. Chapter 1 Assignments 1.1. Develop a technology architecture for the facility with some indication of how the components of the architecture should be distributed across the property on which ToolsAll activities take place. These activities may be broadly grouped into sales of tools and constructions supplies, rentals, and training. Investigate the extent to which wireless communication could be used to cover the large lot and hanger sized building on which ToolsAll conducts it business. Make an initial prioritization of the components of this architecture. The technology architecture should include a property wide local area network (LAN) connecting the data base and applications servers, the cash registers, and all the computers used for office functions, analysis, training course enrollment, job applications, information look up, and inventory maintenance. If Tom, Lisa, and Janet are satisfied with the current state of wireless communication security, the LAN can be entirely wireless, with sufficient access points scattered throughout the store and yard. This will be the easiest LAN to extend to the nursery when it is acquired. Otherwise, the LAN will need to be partitioned into wired and wireless sections with appropriate functions for each. A partitioned LAN will need bridges to connect the wireless functions in the yard and nursery to the more secure wired LAN in the store. This LAN and its components should sit behind a firewall with connections to the Internet for customer inquiries, orders, and information retrieval on innovations in tools and building techniques and materials. 1.2. Develop an application architecture layout and plan for the next several years. What are some of its major functional components? How should these components be distributed over the technology architecture? In what order should they be developed? The suggested system will contain a transaction processing system since it is intended to record all sales, rentals, and class attendances. It is also a management information system since it is intended to provide reports to Tom and Lisa on which aspects of the entire business are doing well or not. It is not primarily either an executive information system (EIS) nor a decision support system (DSS) although it may fulfill some of the M Peter Jurkat

Page 1 of 9

1/13/2017


Full file at http://testbank360.eu/solution-manual-object-oriented-analysis-and-design-with-the-unified-process-1stedition-satzinger roles of both. The implementation of the suggested system will provide both communication and office support to the employees and managers of ToolsAll. In the functional decomposition suggested by the material in the chapter, it is definitely an inventory management system and also a customer maintenance system. It does not directly fulfill the roles of neither an order-entry nor an order fulfillment system in isolation from each other; both these functions are recorded as part of the functions of the employees. Since no mention is made of a ToolsAll generated catalog, it is not intended as a catalog maintenance system. The suggested system is both a supply chain management (SCM) system and a customer relationship management (CRM) system in that it contains aspects of both. However, In the case of an organization the size and scope of ToolsAll it may not be appropriate to formally split the two systems. This it hinted at in the description of the case in that Janet has reviewed commercial systems, which usually do separate these two functions since they are targeted at large systems for which large fees can be charged. Janet found these systems to be inappropriate for ToolsAll. So, the system will support a central data base management system and various applications running against it, such as: sales management, customer management, inventory management, training course enrollment, and rental management. The sales and rental system function will be closely coordinated with the inventory system functions while the customer management system functions will be closely coordinated with those of the sales management system and the training course enrollment system. So, the system will support a central data base management system and various applications running against it, such as: sales management, customer management, inventory management, training course enrollment, and rental management. The sales and rental system’s functions will be closely coordinated with those of the inventory system while the functions of the customer management system will be closely coordinated with those of the sales and rental systems. An initial architecture might be represented as in Figure 1.1: Major Components of the ToolsAll Application Architecture in the file ToolsAllResponsesDiagrams.doc.

2. Chapter 2 Assignments 2.1. The unified process combines both predictive and adaptive approaches to developing applications. How does (1) a predictive approach and (2) an adaptive approach apply in each of the following: 2.1.1.

The development of the various components of the ToolsAll application architecture that you developed in the assignments of the previous chapter. A predictive approach might work well if experienced application programmers are available since there seems to be little groundbreaking application technology in this project. This approach may have a shorter completion time expectation when compared to adaptive approaches. However, an adaptive is inherently less risky since the expected work schedule will have provisions for returning to earlier task and correcting or adapting them to requirements discovered late in the project.

2.1.2.

In their overall integration to achieve ToolsAll’s goal of a comprehensive and integrated information system. An adaptive approach may have an advantage here due to the management team’s inexperience with three-tier, organization wide application development.

2.1.3.

How might a combination of predictive and adaptive approaches improve on their individual use?

It is not clear that the combination is really different than an adaptive approach. Even within any adaptive approach there are predictive elements. 2.2. What activities will take place under each of the nine disciplines to meet the goals of the Inception and Elaboration phase of the UP? M Peter Jurkat

Page 2 of 9

1/13/2017


Full file at http://testbank360.eu/solution-manual-object-oriented-analysis-and-design-with-the-unified-process-1stedition-satzinger UP Discipline Business Modeling

Requirements

Design

Inception Phase Development of an overall business model, and within it a model of the use cases and database objects, particularly to meet the goal of understanding the entire operation of the business ‌ Develop requirements from the stated goals and specify the functions and interactions between the major components of the overall system, with emphasis on how the system will be used and what data is to be kept for the database objects (sale items, customers, courses, etc.) Begin to design the user interfaces for the various use cases.

Implementation

Implement a prototype data base for sale and rental items, customers, and courses with functional user interfaces

Testing

Test this prototype system with operational personnel and customers.

Deployment

Deploy the prototype in some low risk settings, such as course enrollment and tool rental Keep careful track of all suggested changes to the requirements from developers, department heads, clerks, and customers. Optionally, test these suggestions by implementing the ones that will have significant effects on the system and do not require extensive changes to the prototype (save these changes for the Elaboration Phase). Develop the Inception Phase project plan (schedule, resources, etc) and begin to

Configuration Change Management

Project Management

M Peter Jurkat

Page 3 of 9

Elaboration Phase Refine and elaborate the business model by detailed UML models of the use cases, class/object diagrams, and sequence diagrams, and all their associated tables, diagrams, etc. Complete the detailed requirements for the various components, with emphasis on the database and the most critical use cases. Incorporate the requirement changes suggested during the prototype development and testing. Design the database and describe in detail the most critical use case sequence diagrams. Either elaborate the prototype or start the system development over again. Implement the database and the most critical use cases. This may be done in several iterations. Test the elaborated systems after each iteration with operational personnel and customers. Deploy the elaborated systems after each iteration for the appropriate functions of the business. Track the changes both suggested and implemented in the elaborated systems. Implement the ones most relevant to the requirements and plan for the implementation of the rest for the Construction Phase. Resist scope creep!

Complete, put in place, and update the overall project plan through Construction and 1/13/2017


Full file at http://testbank360.eu/solution-manual-object-oriented-analysis-and-design-with-the-unified-process-1stedition-satzinger

Environment

M Peter Jurkat

develop the overall project plan. Monitor how the development team is working and how it interacts with operational personnel. Encourage and implement frequent communication. Put in place the working areas and tools of the development team. Record and evaluate suggested operational environment changes based on the prototype testing.

Page 4 of 9

Transition Phases. Monitor the task completion times and the risk factors. Take appropriate action.

Plan the final hardware, software, and configuration environment. Implement enough of it to test the elaborated systems after each iteration.

1/13/2017


Full file at http://testbank360.eu/solution-manual-object-oriented-analysis-and-design-with-the-unified-process-1stedition-satzinger

3. Chapter 3 Assignment 3.1. From the data supplied by Tom and Lisa, develop a net revenue stream for the next five years that would be available to support the software development effort and calculate the net present value of this stream. A suggested response to this assignment is shown in Table 3.1. The spreadsheet from which these numbers were calculated is in the file ToolsAllCalcs.xls and is available. From the given estimates, if SRITS is implemented the net revenues for the next five years are expected to be between $3.6M and $8M. Table 3.1 NPV of the Expected Net Revenue Stream if SRITS is implemented The following assumptions are made: 5% = discount rate based on 1% above T-Bill in February 2005 98% = current operating costs 2% = current funds available for development and distribution to stock holders Growth Assumptions Year 1 2 3 4 5 NPV NPV funds available

7% Gross Sales $ 10,000,000 $ 10,700,000 $ 11,449,000 $ 12,250,430 $ 13,107,960 $ 49,467,990 $ 3,681,787

4% Operating Costs $ 9,800,000 $ 10,192,000 $ 10,599,680 $ 11,4023,667 $ 11,464,614 $ 45,786,203

15% Gross Sales $ 10,000,000 $ 11,500,000 $ 13,225,000 $ 15,208,750 $ 17,490,063 $ 57,595,099 $ 8,184,480

8% Operating Costs $ 9,800,000 $ 10,584,000 $ 11,430,720 $ 12,345,178 $ 13,332,792 $ 49,410,618

3.2. To determine the cost of the development team for the next five years, determine the range of going salaries for senior/team leader level programmers, staff programmer/analysts, and network specialist. Assuming a 25% burden for fringe benefits and salary increases of 6% a year, find the net present value of the cost of this core staff for the next five years. For the feasibility analysis assume that the project will be essentially completed in one year so the development team does not have to have the same number of members for all five years. However, during the second year some development work will need to be done and during the next three years the development team will become a support and enhancement team. A possible source of IT salaries is swz.salary.com. In February 2005 the following salaries plus bonuses were shown there: $85,000 for project leaders – application systems and programming, database administrator $80,000 for systems analysts II $45,000 for application analyst I $70,000 for network planning analyst III $61,000 for web master Although not specified by Janet, it is recommended that the full time staff include a web master. If the above constitute the full time staff the total annual salaries and bonuses for the firs year add to $341,000. Assuming a 25% burden the total cost of the full time IT staff is $466,250. This is assumed to be the staff for the first year of development, during most of the system will be completed. In subsequent years the systems analyst II and the application analyst I will not be needed. Each part time intern working $20 hours per week during the academic year and 3 months during the summer will work 1280 hours per year. At a salary of $25/hour the annual salary is $32,000. During the first year of development it is assumed that there will be 2 part time interns devoted to populating the database and 3 to help M Peter Jurkat

Page 5 of 9

1/13/2017


Full file at http://testbank360.eu/solution-manual-object-oriented-analysis-and-design-with-the-unified-process-1stedition-satzinger the development team. In the second year only 3 part time interns will be used and during the net three years only 2 each year. After adding the part time salaries to the full time salaries plus burden, and then adding 10% for insurance, social security taxes, etc., the total Year 1 development team costs are $688,875. The same calculations for subsequent years and if salaries were expected to rise 6% per year, the IT staff for the next five years would cost as follows: Year

Salaries

1 2 3 4 5 NPV

$ 688,875 $ 602,608 $ 597,228 $ 628,838 $ 662,838 $ 2,680,685

3.3. Estimate the cost of such roving stations with network capability. Also, determine the number and capacity of application servers. Assume for now that a single database server will be used. Determine the cost of the data base server and software sufficiently capable to support the SRITS. Amortize the cost of this new equipment over the next five years with a 10% annual maintenance and replacement cost. Prices vary widely from year to year and across suppliers. In February 2005 the Hewlett-Packard web site was used to estimate that a small business server could cost up to about $20,000 and roving workstations with wireless cards and carts could cost up to $5000. Janet estimated that 2 servers and 10 roving workstations were needed. Wireless hubs were estimated up to $300 each and, in 2005, had an effective radius of about 30 yards so about 8 would be needed to cover two adjacent football fields. A phased acquisition strategy could generate hardware costs according to the following table:

Year 1 2 3 4 5 NPV

Servers $ 20,000 $ 20,000

Roving WSs $ 15,000 $ 15,000 $ 20,000

Hubs $ 1,2000 $ 1,2000

Cumulative Total $ 36,200 $ 52,400 $ 92,400 $ 92,400 $ 92,400

10% Maintenance/ Upgrade $ 3,620 $ 5,240 $ 9,240 $ 9,240 $ 9,240

Total $ 39,820 $ 21,440 $ 49,240 $ 9,240 $ 9,240 $ 114,747

So, the additional hardware needed for SRITS in the next 5 years has a NPV of $114,747. 3.4. Using these estimates, perform a cost/benefit analysis for the SRITS. Include estimates for the categories for which no estimates have been made. Then bring both the costs and benefits projected for the next five years to the present using NPV calculations and indicate the estimated net benefits. Subtracting the salary and hardware NPV costs from the two NPV net revenue estimates shows that the benefits of SRITS could range between $.8M and $5.4M, making the project eminently beneficial. All the calculations may be examined in the spreadsheet called ToolsAllCalcs.xls, in which the effect of changing the assumptions can be investigated. 3.5. Create a WBS for the inception iteration of the system’s development. A possible WBS for the inception iteration is the following. Tasks marked with (Milestone/Deliverable) are milestones and deliverable. It is assumed that the inception iteration is the first of the project and is numbered accordingly. M Peter Jurkat

Page 6 of 9

1/13/2017


Full file at http://testbank360.eu/solution-manual-object-oriented-analysis-and-design-with-the-unified-process-1stedition-satzinger

1. Inception 1.1 Business modeling 1.1.1 Specify business environment 1.1.2 Create system vision 1.1.2.1 Define system objectives 1.1.2.2 List system capabilities 1.1.2.3 Identify primary business objectives 1.1.2.4 Report system environment and vision (Milestone/Deliverable) 1.1.3 Create business model 1.1.3.1 Collect existing system documents 1.1.3.2 Structure data base 1.1.3.3 Report business model (Milestone/Deliverable) 1.2 Develop requirements 1.2.1 Gather detailed information 1.2.2 Define functional requirements 1.2.3 Define non-functional requirements 1.2.4 Prioritize requirements 1.2.5 Develop user interface dialogs 1.2.6 Evaluate requirements 1.2.7 Report requirements (Milestone/Deliverable) 1.3 Project management 1.3.1 Finalize system and project scope 1.3.2 Develop project and iterations schedule 1.3.3 Report project scope and schedule (Milestone/Deliverable) 1.3.4 Identify project risks 1.3.5 Confirm project feasibility 1.3.6 Report feasibility and risks (Milestone/Deliverable) 1.4 Monitor and Control 1.4.1 Develop change control procedures 3.6. Use the knowledge areas of the PMBOK (in Appendix 1 at http://www.course.com/ooad/) to categorize the various risks that may be incurred in the development of ToolsAll’s system. Display your assessment of these risks in a table similar to Table 3-17. Many risks could be identified. Janet is the only high-level executive who has any experience in software development, and her experience does not include three tier applications on networks. Others are listed below. Also technically trained software developers may have difficulty communicating with the other employees who are likely to be hands-on, self-trained people. The following list is unlikely to be a definitive or complete; it might be worth a class discussion to evaluate this list.

M Peter Jurkat

Page 7 of 9

1/13/2017


Full file at http://testbank360.eu/solution-manual-object-oriented-analysis-and-design-with-the-unified-process-1stedition-satzinger

Risk Description Organizational failure - upper management inexperience Goal/objectives failure - scope creep Schedule failure – unrealistic task durations or unexpected events Resource failures - cost overruns

Difficulty of Timely Anticipation Moderate – more difficult will be the reaction to it

Overall Threat High

Low – system requirements seem clear High – unless software developers have input to schedule

Moderate

Low

Moderate

Moderate

Moderate (upper management commitment and resources are adequate for all but the worst failures) Moderate – particularly if schedule is too tight High – Janet has no experience hiring software developers Moderate

Low

Low

High – management team has no experience Moderate

High

Low

Moderate

Moderate – no ground breaking requirements

Low

Low

Potential Impact on Project High

Likelihood of Occurrence High

Moderate Moderate

Low

Quality failure

High

Human resource failure

Moderate

Communications failure Technology failure

High Moderate

High

4. Chapter 4 Assignment 4.1. Make a list of the various stakeholders in the project. Break this list down by the roles they play in the operation of ToolsAll. Include the various job functions of the day-to-day operation of the business. Client: Janet Sponsors: Tom and Lisa Development team members Operational personnel: Department Heads, clerks, stockers, and other employees Customers: purchasers, renters, course attendees Neighboring property owners 4.2. Many of workers of ToolsAll grew up in the rural area as farmers, carpenters, and local merchants. Many of these people are not comfortable with bright, young, and educated people prying into their affairs. What are some of the information gathering techniques targeted to the departments mentioned in the previous question that might be used to have these employees be somewhat comfortable with the information gathering process?

M Peter Jurkat

Page 8 of 9

1/13/2017


Full file at http://testbank360.eu/solution-manual-object-oriented-analysis-and-design-with-the-unified-process-1stedition-satzinger One of the most effective techniques might be to assign all new hires in the development team for a several weeks to several departments as if they were new employees of that department and then to have the department personnel train the new hires as if they were going to be permanently assigned to that department. This way the new hires would be met by the employees in situation familiar to the employees and would give them an assignment that would get them to know the new hires. It would also be an efficient way to have the new hires learn the operations of the business and its problems. This is similar to a practice (formerly in place but possible now abandoned) by UPS that assigns all new hires, no matter how high up in the hierarchy, to deliver packages on a regular route for at least a month and to spend about the same time in one of UPS’s depots. After the training, Janet should organize meetings with the Head and key personnel (or all personnel since there are not very many) of each department as a kind of focus group. In these meetings Janet, or preferably the Department Head, should present the goals and expected operations of the project and department personnel should be encouraged to ask questions in addition to answering the information gathering questions. The development team should attend each of these meetings. One of the functions of these meetings is to establish how the development team members are to interact with department personnel. This can differ by department; some Heads will want all interaction to go through them while others may be willing to have development team members interact directly with department personnel. In order to maintain good relations for the duration of the project each Department Head’s wishes in this regard should be followed. After the training period and focus group sessions it is likely that the new hires and department employees will be able to effectively communicate on a regular basis. 4.3. Develop an outline of a set of question to be used as the basis for interviews of department heads involved with the NRUTIP that would determine what business processes and operations are performed as part of the work of that department, how these processes and operations are performed, and what the information requirements are. What documentation is appropriate to record the information thus gathered? Comments and questions should examine each of the following topics: 4.3.1.

All the various tasks, many of which are likely to become use cases that employees perform in their regular and exceptional duties. 4.3.2. For each task, a series of questions that determines 4.3.2.1. under what conditions the task arises, 4.3.2.2. the customers goals 4.3.2.3. the immediate response of the employee, 4.3.2.4. a detailed description of the steps undertaken by the employee to meet these goals, including exceptional conditions and how the exceptional conditions are recognized, 4.3.2.5. what all forms and documents are that the employees and customers use in the conduct of the task, and 4.3.2.6. all aspects of the task that employees and customers find difficult, ambiguous, onerous, or unnecessary. 4.3.3. Aspects of work conditions that are working well and that are not working well or have particular problems. 4.3.4. Information that employees and/or customers find missing, hard to acquire, redundant, or seems to serve little purpose. The information items that are necessary to the business but not relevant to the employee’s tasks are prime candidates for automation. After each set of a few questions be sure to ask a general question like “Is there anything else about what we just discusses that you want to say?” Allow the flow of the questions to be partly determined by the respondent; follow branches in the topics immediately and come back to the thread later.

M Peter Jurkat

Page 9 of 9

1/13/2017


Solution manual object oriented analysis and design with the unified process 1st edition satzinger