7.3 Business Impacts

Lifecycle model Improvements:

		Software process models should be revisited to provide more support for back-end, post-development
		activities.

		The community needs to raise deployment to the level of a first class process phase. While most software
		methodologies have a deployment activity or phase, their major activities and discussions center on the ones
		close to development.

		The inclusion of deployment is almost a token to show completeness. In addition, the information and the
		respective representation advocated by process models in the deployment area also need to be revisited,
		particularly as they relate to components.

		The scripts, tools, and "hacks" are vital to deployment organizations and to the success of many products.
		However, process models do not discuss them as a formal activity. Consequently, they are typically created
		outside the scope of the planned product lifecycle.

		These activities need to be raised to first class status and considered a business asset. They should be
		managed projects with a formal requirements activity, regular release cycle, and supporting documentation.

7.3 Business Impacts

Better understanding of product scope:

		Lack of planning is perhaps the largest reason for the pain and expense deploying component-based
		systems.

		While the 4+1 Architecture Model (Krutchen) as shown in Figure 7.2, advocates scenarios in all four views,
		few systems have formal requirements around deployment and operational scenarios.

		Most requirements and analysis activities focus primarily on functional requirements and secondarily on non-
		functional requirements. Requirements are commonly evaluated using the FURPS framework (Grady &
		Caswell)-functionality, usability, reliability, performance, and supportability.

		The business side of a software product organization needs to understand and commit to a component
		strategy suitable to their market. If platform X and database Y are on the product roadmap, then developers
		and testers exercise those component combinations on every release.

		The engineering side has the obligation to communicate the cost of supporting those combinations so the
		business organization can decide where they belong on the product roadmap and how to charge for them.