Software Engineering for Computer Games Integration Software integration

Software Engineering for Computer Games Integration

Software integration Benefits of careful integration: Easier defect diagnosis Fewer defects Less scaffolding Shorter time to first working product Shorter development schedule Better consumer relations Improved morale

Software integration Benefits of careful integration (cont. ): Improved chance of project completion More reliable schedule estimates More accurate status reporting Improved code quality Less documentation

Software integration Phased integration: Old-fashioned style of integration Design, code, test and debug software units (“unit development”) Combine everything into a single system (“system integration”) Test and debug the whole system (“system dis-integration” ☺)

Software integration Incremental integration: Develop a small functional part of the system. Test and debug it. Adopt it as the skeleton of the system. Design, code, test and debug one class. Integrate the class with the skeleton. Test and debug the combination of skeleton and new class. Adopt the combination as the new skeleton and reiterate from step 2.

Software integration Incremental integration - benefits: Errors are easy to locate Time-to-functioning is shortened Morale of developers is preserved Progress monitoring is possible Customer relations are smoothened Units are more fully tested (early units are naturally regression-tested as new units are added)

Software integration Incremental integration – strategies: Top-down, breadth-first: adopt as skeleton the top class in the class hierarchy. Add classes following the hierarchy, breadth-first. Integration follows program abstraction. Interfaces usually built early on. Coding can start even before low level details are worked out. As a disadvantage, functional subsystems can take long to be reached.

Software integration Incremental integration – strategies: Top-down, depth-first: adopt as skeleton the top class in the class hierarchy. Add classes following the hierarchy, depth-first. Nearly all advantages of previous strategy. Functional subsystems are reached soon. Not so adequate to evaluate and test abstraction hierarchy.

Software integration Incremental integration – strategies: Bottom-up: adopt as skeleton a class at the bottom of the hierarchy. Add classes going up in the hierarchy. Requires detailed design before coding. Requires scaffolding to reach lower layer classes without having written upper layer ones. Usually, less effective than top-down strategies.

Software integration Incremental integration – strategies: Sandwich: this is what usually occurs in practice. Adopt as skeleton the top-level class, then go depth-first to the lowest layers, then stay there for a while, then go up again to the upper layers, and so on. It should be disciplined and follow a roadmap, despite its apparent lack of structure.

Software integration Incremental integration – strategies: Risk-oriented integration: instead of following class hierarchy, start with harder classes (the more complex, more important, largest, or more connected ones). Add the easy ones later on.

Software integration Incremental integration – strategies: Feature oriented integration: break your system in features (e. g. observable functionalities). Use your preferred strategy for each feature. Finally, integrate the different features.

Software integration Daily build and smoke test – this is a very effective strategy to keep a project up and running healthy. Design a smoke test: set of simplified tests that check the major points of the system and ensure that it continues to run. Do not consider your working DAY finished until you have a new system build running smoke tested.