Systems Analysis and Design in a Changing World, Fourth Edition -Solutions 15

Systems Analysis and Design in a Changing World, Fourth Edition

15-1

Chapter 15 – Making the System Operational Solutions to End-of-Chapter Material Review Questions 1.

List and briefly describe the three basic approaches to program development order. What are the advantages and disadvantages of each? Input, process, output (IPO) development order develops input programs or modules first, processing programs or modules next, and output programs or modules last. The primary advantages of IPO development order include simplified testing and early testing of user interfaces. The primary disadvantage of IPO development order is late implementation of outputs, which may delay the discovery of errors in processing modules or programs. Top-down development order implements program modules in their order of invocation (procedure or function calling), which corresponds to the top-to-bottom order of modules as they are drawn on a structure chart. The primary advantage of top-down development is that there is always a working (buildable and testable) version of the program. The primary disadvantage is that there are relatively few top-level modules, which may lead to inefficient use of programmers early in the project. Bottom-up development order implements program modules in the reverse of their invocation order, which corresponds to the bottom-to-top order of modules as they are drawn on a structure chart. The primary advantage of bottom-up development order is that a large number of programmers can work in parallel from the start of implementation. The primary disadvantage is that a large number of driver programs must be written to simulate the behavior of calling top-level modules that are not yet written.

2.

How can the concepts of top-down and bottom-up development order be applied to object-oriented software? The key issue is method dependence, or order of invocation. Methods not called by other methods would be implemented first in top-down development order and last in bottomup development order. Methods called by many other methods would be implemented last under top-down development order and first under bottom-up development order.

Systems Analysis and Design in a Changing World, Fourth Edition

3.

15-2

Describe three approaches to organizing programming teams. For what types of projects or development activities is each approach best suited? A cooperating peer team includes members of roughly equal skill and experience with overlapping areas of specialization. This type of team is best suited to projects requiring experimentation and creative problem solving. A chief developer team has a single leader who makes all of the important decisions. This type of team is best suited to projects with well-defined objectives and a clear completion path. A collaborative specialist team has members with a wide variety of skills and experience that minimally overlap. This type of team is best suited to projects that require diagnosis, experimentation, and creative and integrative problem solving, and that span a wide range of technology.

4.

What is a source code control system? Why is such a system necessary when multiple programmers build a program or system? A source code control system (SCCS) is an automated tool for tracking source code files and controlling changes to those files. An SCCS prevents multiple programmers from making inconsistent or conflicting changes to source files. An SCCS ensures that a source code file cannot be modified by more than one programmer at a time.

5.

Define the terms alpha version, beta version, and production version. Are there welldefined criteria for deciding when an alpha version becomes a beta version or a beta version becomes a production version? An alpha version is a system that is incomplete but ready for some level of rigorous testing. A beta version is a system that is stable enough to be tested by end users. A production version is a system that is formally distributed to users or made operational. Because users test beta versions by using them to do real work, an alpha version must meet the following criteria to become a beta version: the software must be nearly complete, and it must not be susceptible to severe crashes or other productivity-thwarting behaviors. A beta version usually becomes a production version after successful acceptance testing.

Systems Analysis and Design in a Changing World, Fourth Edition

6.

15-3

List and briefly describe implementation phase QA activities other than software testing. What is the effect on software testing of not performing non-testing QA activities? QA activities other than testing include conducting technical reviews and inspections. A technical review is a formal or informal review of design or construction details by a group of developers. An inspection is a formal technical review in which each participant plays a specific role (for example, presenter, critic, and secretary). Software testing becomes more complex and expensive if technical reviews and inspections are skipped because a larger number of errors find their way into the source code.

7.

What are the characteristics of good test cases? Test cases must ensure that all instructions in a program are executed, preferably many times, with a variety of data inputs.

8.

Define the terms acceptance test, integration test, system test, and unit test. In what order are these tests normally performed? Who performs (or evaluates the results of) each type of test? An acceptance test is a system test that determines whether the system fulfills user requirements. An integration test is a test of the behavior of a group of modules or methods. A system test is a test of the behavior of an entire system or independent subsystem. A unit test is a test of an individual module or method before it is integrated with other modules or methods. An acceptance test is normally performed by or under the direction of users. The programmer or his or her testing buddy usually performs unit testing. Integration and system tests may be performed by programmers or members of a separate quality assurance group.

9.

What is a driver? What is a stub? With what type of test is each most closely associated? With what development order is each most likely to be used? A driver is a module that simulates the calling behavior of a module that hasn’t yet been developed. Drivers are most closely associated with unit testing and are most likely to be used with bottom-up development order. A stub is a module that simulates the execution or behavior of a module that hasn’t yet been developed. Stubs are most closely associated with unit testing and are most likely to be used with top-down development order.

Systems Analysis and Design in a Changing World, Fourth Edition

10.

15-4

What factors make testing object-oriented programs more complex than testing structured programs? Complicating factors include the following:    

11.

Methods can be (and usually are) called by many other methods, and the calling methods can be distributed across many classes. Classes can inherit methods and state variables from other classes. The specific method to be called is dynamically determined at run time based on the number and type of message parameters. Objects can remember internal (state) variables between calls. The response to two identical messages might be different due to state changes that result from the first call or occur between calls.

List possible sources of data used to initialize a new system database. Briefly describe the tools and methods used to load initial data into the database. Possible data sources include manual (paper) records, files or databases of a system being replaced, files or databases of other systems in the organization, and manual data entry during training or normal system operation. Tools for initializing database content include normal data entry programs, optical character recognition software, custom-developed data conversion programs, and DBMS import and export utilities.

12.

Briefly describe direct, parallel, and phased installation. What are the advantages and disadvantages of each installation approach? Direct installation installs a new system, quickly makes it operational, and immediately turns off any overlapping systems. Direct installation is the simplest to plan and execute, but it runs the greatest risk of interrupted service. Parallel installation operates both the old and new systems for an extended period of time. Parallel installation is relatively complex to plan and implement, but it reduces the risk of interrupted service. Phased installation installs a new system and makes it operational in a series of steps or phases. Phased installation breaks up the complexity of planning and execution into manageable pieces, but the total planning and execution effort is greater than with the other methods.

Systems Analysis and Design in a Changing World, Fourth Edition

13.

15-5

Why are additional personnel generally required during the later stages of system implementation? Many labor-intensive activities must be performed during installation, testing, and switchover to a new system. Any form of parallel or phased installation increases the number of these activities.

14.

What are the differences between documentation for end users and system operators? Operator documentation covers topics, such as system startup and shutdown, backup and recovery, and software installation and upgrade, that are not typically covered in end user documentation. System operators are usually more highly trained than end users, so their documentation often has fewer “bells and whistles.”

15.

How or why is system documentation redundant with the system itself? What are the practical implications of this redundancy? System documentation describes the architecture and function of a system, but that information can also be extracted from the system source code (although with considerably less efficiency). System documentation must be updated every time the system itself is updated to prevent inconsistency.

16.

List the types of documentation needed to support maintenance activities. Which documentation types are needed most frequently? Which are needed least frequently? Documentation needed to support system maintenance includes all of the outputs of the analysis, design, and implementation phases. Implementation phase outputs (such as source code) are needed most frequently, and analysis phase outputs are needed least frequently.

17.

How do training activities differ between end users and system operators? End user training emphasizes hands-on system use to achieve specific business objectives. Training in the business context is as important as training in system specifics. Relatively large numbers of end users allow one-to-many (classroom) training sessions and train-thetrainer approaches. Variation in skills and experience levels necessitate several training methods and materials. System operator training generally omits the business context. The relatively small number of operators usually precludes classroom-based approaches. Relatively high skill and experience levels allow greater use of self-study as a training method.

18.

How does implementing a maintenance change differ from a new system development project? How are they similar?

Systems Analysis and Design in a Changing World, Fourth Edition

15-6

Differences depend on the magnitude of the change. All but the simplest and greatest changes follow the normal SDLC phases, but the scope of activity is restricted to the change area. Significant changes require larger analysis and design scope due to the greater potential for ripple and interaction effects with other portions of the system. At the extreme, a complete overhaul of the system calls for an approach equivalent to that of developing a new system. 19.

Why might system software upgrades not be installed? What are the costs of not installing them? There is always a risk that application software will malfunction or break after upgrading system software. Thus, there is a strong motivation to avoid system software upgrades. However, not upgrading runs the risk of not fixing critical but undiscovered bugs and makes newer system software features unavailable to existing applications.

Thinking Critically 1.

Examine the system flowchart for Rocky Mountain Outfitters in Figure 10-5. Develop a preliminary development plan based on IPO development order. Which programs are difficult to classify as input, process, or output? Is a straightforward application of IPO development order appropriate for this system? If not, what changes should be made to the preliminary development plan? Input programs include the following:   

Customer information maintenance program Customer order program Catalog maintenance program

The order fulfillment program performs both processing and output, and the sales analysis program generates output. Thus, IPO development order would implement the three input programs first, the order fulfillment program next, and the sales analysis program last. The customer order and order fulfillment programs are the most difficult to classify. The customer order program is primarily input, but it also has aspects of processing (for example, checking and modifying inventory status and modifying existing orders). The order fulfillment program can be classified as processing, output, or both. Processing elements include preparing shipments from orders, and output elements include the shipping documents and interfaces to shipper systems. IPO is probably an appropriate development order for this system, but some modifications could be beneficial. The sales analysis program is probably the least important, so addressing this program last is acceptable. The order fulfillment program produces its own outputs, so no other programs need to be implemented to test its processing functions. In theory, the customer order program should be the last of the three input programs to be implemented because it also has processing components. However, it is an important

Systems Analysis and Design in a Changing World, Fourth Edition

15-7

program with complex user interfaces, so its development (or at least the development of its user interfaces) should probably be expedited. It might be possible to implement and test it first by using DBMS utilities to populate the database with sample customer, inventory, and catalog data. 2.

The chapter discussed top-down and bottom-up development order for transformoriented structure charts. Can these development orders also be applied to transaction-oriented structure charts such as the one shown in Figure 10-10? If so, how? Each module beneath the transaction center can be treated as a separate structure chart for the purposes of applying top-down and bottom-up development orders.

3.

Describe the process of testing software developed using both top-down and bottomup development order. Which method results in the fewest resources required for testing? What types of errors are likely to be discovered earliest under each development order? Which development order is best as measured by the combination of required testing resources and the ability to capture important errors early in the testing process? Software testing under top-down development order starts with an implementation of the top-most module and stubs for each of the second-level modules. One by one, each stub is replaced with a fully implemented module, which is then tested. As each stub is replaced, new stubs must be created for any subordinate modules. The process continues until all of the modules have been fully implemented and tested. Bottom-up development order starts with a driver for one related set of bottom-level modules and the initial implementation of one of the bottom-level modules. After that module is tested, another bottom-level module is created, and the driver is modified to call it (or a new driver is created). After all bottom-level modules in a calling group have been implemented, the driver is replaced with a new module, and a new driver is written to call the new module. Implementation and testing moves up the structure chart in this fashion until all program modules have been implemented and tested. Under top-down development order, a stub is written once for every module. Under bottom-up development order, a smaller set of drivers is written, but each driver must be updated several times as subordinate modules below it are implemented. In addition, driver modules are generally more complex than stub modules (for example, compare the driver in Figure 15-16 to the stubs in Figure 15-17). Thus, bottom-up development order tends to consume more resources because more effort is expended writing and modifying modules that will be discarded after testing. Top-down development order finds errors in upper-level modules first. These modules typically contain the business logic of the system and integrate the activities of the lowerlevel modules. Thus, logic and integration errors are found sooner with top-down development order.

Systems Analysis and Design in a Changing World, Fourth Edition

15-8

Bottom-up development order finds errors in the lower-level modules first. These modules typically contain detailed procedural code including data access, I/O formatting, and computations. Thus, errors in those modules are found sooner with bottom-up development. Neither implementation order completely dominates the other when required resources and early error detection are considered. If errors are assumed to be evenly distributed through the structure chart and if they are assumed to be equally “fixable” regardless of structure chart location, then top-down development order is better due to its lower resource consumption. But many systems have complex procedural, I/O, or data access modules, and discovering errors in those modules early in the development process can save time and testing resources. 4.

Assume that the Rocky Mountain Outfitters customer support system will be developed as described in your answer to question 1. Assume that 14 people are available for programming and testing. What sizes and types of teams are best suited to the project? Note: Students should review the RMO implementation alternatives discussed in Chapter 8 before attempting to answer this question. Because teams should consist of four to ten members, the chief developer should divide the programmers into two, three, or four teams. Given the size of the project, one of these teams should be a dedicated quality assurance team servicing the other three teams. That team might not need to be created until several weeks into the project, depending on the testing schedule. Quality assurance for such a large project will span a wide range of technology and will require diagnosis and experimentation. A collaborative specialist team is ideally suited to that task. One person should be designated as the primary interface to the other teams. Another person should be designated as the administrative leader of the team. (The same person, however, could fill both roles.) Because the amount of available information is limited, it is difficult to determine how best to organize the programming teams. However, some relevant observations can be made based on the characteristics of the project as described in Chapter 8. The critical issues that affect team organization are the use of relatively new technology and the relative lack of experience among IS staff with that technology. Some or all of the teams will be using new tools and a new operating system, and they’ll be developing a system unlike any they’ve developed before. Thus, it is highly unlikely that all team objectives and paths to completion can be characterized as “well-defined.” This makes a chief developer organization less desirable. It might be possible to dedicate one team to portions of the system that use older technology and skills (for example, the database interface on the mainframe). Chief developer organization might be appropriate for that team.

Systems Analysis and Design in a Changing World, Fourth Edition

15-9

The other teams should be organized as cooperating peers based on the need for creative problem solving and consensus-based decision making. A chief developer organization would be appropriate only if one or two programmers have many more organizational and applicable technical skills than all the other programmers do. In that case, a chief developer organization might be appropriate, though there will almost certainly still be some need for experimentation and consensus building. 5.

Consider the issue of documenting a system using only electronic models developed with a full life cycle CASE tool. The advantages are obvious (for example, the analyst modifies the models to reflect new requirements and automatically generates an updated system). Are there any disadvantages? Hint: The system might be maintained for a decade or more. The system owner is effectively locked into the CASE tool for the life of the system, unless he or she is willing to spend the considerable amount of money required to reimplement the system without the CASE tool. The situation is similar to the problem of extracting data from old sources (for example, data stored in a dBase II file on a 5.25 inch floppy disk). You must maintain appropriate software and hardware to be able to access the data. Without the CASE tool, developers would have to rely on printed output (which may be incomplete or unavailable) and source code stored in ordinary files (if it was ever stored that way). While this may appear acceptable in theory, it is extremely difficult in practice. Source code generated by CASE tools is not intended to be read by the human eye (and there’s considerable incentive for the CASE tool vendor to make it unreadable). Modifying such code is technically but not economically feasible.

Systems Analysis and Design in a Changing World, Fourth Edition

6.

15-10

Some types of system documentation (such as models developed during the analysis phase) are seldom looked at after the system is made operational. What are the advantages and disadvantages of not keeping such documentation types? The primary advantage is that you won’t have to store or retrieve a large amount of documentation. The primary disadvantage is that the models will have to be reverseengineered from other sources or developed from scratch if they are needed. Reverse engineering of system models is complex and prone to errors. Developing from scratch is more accurate but far more expensive.

Experiential Exercises 1.

Assume that you and five of your classmates are charged with developing the Customer order program shown in Figure 10-16. Create a development and testing plan to write and test the required modules. Assume that you have three weeks to complete all tasks. A top-down implementation approach is best suited for this program unless there are some particularly difficult issues to be resolved in lower-level modules. One complicating factor is that some of the functions within each transaction type overlap. A high priority should be given to implementing and testing these functions. Because six people are available, one possible approach is to assign the five transaction types to five different people. If any of the transaction types is substantially more complex than the others (for example, create new order or cancel/change order), multiple people could be assigned to those transaction types, and the remaining people could cover two of the simpler transaction types. The sixth person could initially work on the transaction center and shared modules and later be dedicated to quality assurance. Between 25 and 33 percent of the schedule should be reserved for integration testing, system testing, and making necessary modifications. That leaves between 10 and 12 days to complete programming and unit testing.

Systems Analysis and Design in a Changing World, Fourth Edition

2.

15-11

Implement a formal QA process in one of your programming or system development classes (be sure to obtain permission from your instructor first). Form a group of students to implement an inspection process. Have one or all members prepare presentation materials for code that they’ve written and distribute them prior to a group meeting. If possible, create a buddy system for testing each other’s code. Evaluate the results in terms of time required for code development and quality of the final product. This is an excellent exercise if students are taking a development class at the same time they are taking the systems analysis and design course. The exercise works best if students are required to log their time in detail and perform a debriefing after the exercise is concluded. You can compare the results and experiences of different groups in class.

3.

Examine the end-user documentation supplied with a typical personal or office productivity package such as Microsoft Office. Compare the documentation to the categories described in the chapter. Which categories of documentation are supplied? How might documentation for a business application differ in content or format? Personal productivity packages are good examples for this exercise because they tend to have the most complete and advanced documentation. Today, most software packages include more online documentation than printed documentation. The latest version of the Microsoft Help system (standard in Windows 2000 and XP) is based on a simplified Internet Explorer interface and includes extensive support for hyperlinks and multimedia. End-user and troubleshooting documentation for a business application will be geared toward specific, business-related problems (for example, what do you do if a customer doesn’t know his or her order number?). Operator documentation for a business application will be much more substantial than it is for a personal productivity suite.

4.

Talk with a computer center or IS manager about the testing process used with a recently installed system or subsystem. What types of tests were performed? How were test cases and test data generated? What types of teams developed and implemented the tests? You should have no trouble finding senior IS professionals who’d like to share their testing and installation experiences. Have the professional bring in as many reports or slides as possible to demonstrate the depth and breadth of planning activities.

Systems Analysis and Design in a Changing World, Fourth Edition

5.

15-12

Talk with an end user at your school or work about the documentation and training provided with a recently installed or distributed business application. What types of training and documentation were provided? Did the user consider the training to be sufficient? Does the user consider the documentation to be useful and complete? For better or worse, most application developers will write a substantial amount of user documentation during their careers. This exercise is an interesting introduction to which types of documentation and training are most and least effective from the user’s perspective.

Case Studies Case Study: The HudsonBanc Billing System Upgrade 1.

What type of installation did HudsonBanc use for its new system? Was it an appropriate choice? A partial parallel installation was used; however, not all of the accounts and system functions were replicated on both the old and new systems. Given the risk involved, parallel installation was an appropriate choice, although hindsight shows that HudsonBanc’s specific implementation had faults.

2.

How could the operational problems have been avoided? There were two substantial operational failures:  

The new system couldn’t handle a full processing load. The new system couldn’t print bills with items more than 30 days old.

The first failure could have been avoided by testing the new system under full load. This could have been accomplished with minimal risk by operating both the old and new systems on all accounts for a month or two. Another approach would have been a gradual duplication of accounts from the old system to the new system with complete redundancy in the old system. Performance problems would have been gradually discovered, and the old system would have still been available. Note that a priori cost estimates for either recommended approach would have been much higher than for the approach actually used. In essence, HudsonBanc would have been raising implementation costs to minimize the risk of incurring the cost of cleaning up the mess that eventually occurred. There is no obvious change to the installation approach that could have prevented the second failure. This failure most likely arose from a gap in the requirements and/or an incomplete evaluation of vendor adherence to the requirements in the RFP. In either case, the solution would have to have been applied much earlier in the life cycle. This is an extreme example of the rising cost of implementing a system change.

Systems Analysis and Design in a Changing World, Fourth Edition

15-13

Case Study: Downtown Video Rental System Using the design class diagram you developed in Chapter 11 for the DownTown Videos rental system, develop an implementation and testing plan. Specify the order in which classes and their methods will be implemented and the groups of methods and classes that will be tested during integration testing. The Rental class is related to both rental items and customers. Because it has the highest dependency on other classes it should be implemented last. Implementation can begin with the rental item classes (Movie, Game, ConceptualItem, and ItemCopy), the customer classes (Customer and FamilyMember), or both sets of classes in parallel. These classes should be implemented and tested before the rental classes (Rental and RentalLineItem) are implemented. Within individual classes, create and update methods should be implemented and tested before other methods. Create and update methods are needed to create test data (objects) for testing the remaining methods. Note that this order follows the input-process-output sequence of the class methods

Case Study: Rethinking Rocky Mountain Outfitters 1.

Describe the risks associated with planning the new CSS implementation and announcing the availability of Web ordering to customers. Remember that the new CSS will replace the current telephone and mail-order systems in addition to handling Web orders. How conservative should RMO be with respect to testing, installation, and customer announcements? What is the cost of being too conservative? The risks associated with rolling out the new CSS and its Web ordering component are similar to those in the HudsonBanc case. But for RMO, failure of the system will result in a permanent loss of revenue, not just delayed cash flow, due to lost orders and angry customers who may never return. Conservative planning is a must given the timing of the expected system conversion and the high number of sales that occur during the holiday shopping season. Announcing the Web ordering system should probably be delayed until the October 31 or December 10 catalogs, especially because the lead-time for preparing and distributing the catalogs is several weeks. Also, note that the Web ordering portion of the system relies on the newest technology—exactly the technology with which RMO IS staff is least familiar. There are several possible costs of being too conservative. First, the old system may not be able to handle the transaction volume (this presumes that the new system was developed to handle larger volumes than the existing system). Second, some sales may be lost from customers who find placing telephone and mail-based orders to be less convenient than placing Web-based orders. Last, delaying the system rollout may incur

Systems Analysis and Design in a Changing World, Fourth Edition

15-14

additional operating costs if the old system is more expensive to operate than the new system. If delaying cutover requires running both systems in parallel, operating costs will probably double during the busiest part of the year. 2.

What fallback strategies should be developed, if any? What should the “drop dead” date be for deciding whether to use the new CSS to process holiday orders? Given the magnitude of the risks, it would be unwise to shut down any part of the existing system before the holiday sales season is over. Even if the new system is ready and operating in time for the holiday rush, the old system should be kept in a “ready” state in case problems are encountered. This might require complete parallel operations to maintain current data in the old system. Or, it might be possible to update data in the old system on a nightly basis to keep it in sync with the new system. The drop dead date for deciding whether to rely primarily on the new system should be before the start of the holiday sales season—probably between October 15 and November 15, depending on the exact time of the holiday rush.

3.

Develop an installation plan and schedule. Justify your approach(es) and your timetable based on your previous risk analysis. The new system should be brought online one subsystem (mail, telephone, and Web) at a time. The subsystem with the lowest expected transaction volume should be brought online first to minimize the impact of any problems that are encountered. This approach will also allow gradual testing of “back end” functions such as inventory and shipping. One possible schedule is: November 1 – Start processing mail orders in parallel with the old system. November 15 – Start processing telephone orders in parallel with the old system. November 30 – Start processing Web orders. Parallel processing and data entry on the old system for each order type should not stop for at least two weeks to allow sufficient time for problems to surface.

4.

Analyze the training requirements, and develop a training plan and schedule. How can training, data conversion, and testing activities be overlapped or combined? What about training and support for customers using the Web ordering system? Training to process mail and telephone orders should begin as soon as those portions of the new system have passed integration testing. Sufficient training time (for example, two weeks) should be allowed to decrease error rates and increase efficiency levels before allowing personnel to process “live” orders. Test data could be taken from orders processed by the old system, which would allow testing personnel to compare the processing results. For Web-based orders, RMO should train staff to handle customer support requests by telephone, e-mail, or instant messenging. They could also combine the training for taking telephone orders with the training for providing telephone support for Web-based orders.

Systems Analysis and Design in a Changing World, Fourth Edition

15-15

Doing so would allow customers to call the same number for both purposes, and it would simplify taking an order by telephone if a customer becomes frustrated with the Web-based interface.

Case Study: Reliable Pharmaceutical Service Using the structure chart you developed in Chapter 10 for Reliable Pharmaceutical Service, develop an implementation and testing plan. Specify the order in which modules will be implemented and the groups of modules that will be tested during integration testing. Refer to the structure charts in the Chapter 9 Solutions Manual. The first structure chart represents the system as a transaction center where the four transaction types are Update Prescription, Fill Order, Generate Bills, and Accept Payment. The left-to-right order of the transaction modules follows the input-process-output order of the system and is thus a natural order for implementation and integration testing to follow. However, the structure charts omit certain necessary features of the system such as creating and maintaining files of prescriptions, drugs, customers, nursing homes, and pharmacists. Thus, the implementation of each transaction-processing module (and its subordinates) must be preceded by the implementation of maintenance software for files that are accessed when processing that transaction. For example, modules that create prescriptions, nursing homes, drugs, pharmacists, and patients should be created before the transaction-processing module Update Prescription. Within individual structure charts, top-down development order is generally preferred to bottom-up development order because it always provides a working (though incomplete) system that can be tested. Note that some testing methods, such as build and smoke tests, require top-down implementation.