Chapter 17

Chapter 17

Formulation and Planning

CHAPTER OVERVIEW AND COMMENTS

This intent of this chapter is to provide guidance for formulating the problem that a WebApp is to solve and then planning the project that will lead to the construction of the WebApp. Formulation allows stakeholders and the web engineering team to establish a common set of goals and objectives for the construction of the WebApp. It also identifies the scope of the development effort and provides a means for determining a successful, outcome. Even if you’ve said this to your students 20 times during the course, say it one more time: “A poorly formulated system will dissatisfy the customer and bring grief to the developer.”

Planning WebE projects is very similar to the planning activities noted in Part 4 of SEPA, except that everything tends to be lean when WebApps are small or moderate in size. You can delay discussion of WebApp project planning until you cover Part 4, if you prefer.

17.1     Formulating Web-Based Systems

It is important for your students to understand the difference between formulation and analysis. Formulation focuses on scope, goals, and objectives. Detailed WebApp requirements are considered during analysis.

The simple questions noted in Section 17.1.1 serve as a foundation for formulation. Have your students answer them for a few well know WebApps.

The mechanics of requirements gathering are discussed in Section 17.1.2. A key issue here is that there are often many different types of users and that each type has its won requirements. However, there is only one formulation for the system. The techniques discussed here are variations of (and in some cases, identical to) the requirements gathering methods discussed in Chapter 7.

17.2     Planning for Web Engineering Projects

Send a few moments in lecture discussing Figure 17.1. It’s important to note that large e-Projects take on many of the same characteristics as conventional (traditional) software engineering projects.

17.3     The Web Engineering Team

Be sure your students understand each of the different roles that can be played on a WebE team. The key points proposed in Section 17.3.2 for building a WebE team are worth emphasizing in lecture. If time permits, readings from Kidder’s classic book are recommended.

17.4     Project Management for Web Engineering

            You might begin by reading Steve McConnell’s quote alound. Although anarchy might sound good for Web projects, it almost always resulting in failure. Be sure your students understand this—there’s no glamour in a chaotic project, especially when things go bad, and they almost always go bad when chaos reigns.

Because outsourcing is so common when WebApps are built, Section 17.4.1 should be emphasized. The tasks noted should be used to emphasize that just because you send the project outside, this does not absolve you from technical and management responsibility.

The in-house development tasks (Section 17.4.2) emphasize the same tasks are conventional software engineering (Part 4 of SEPA). I would suggest a brief overview at this point, delaying detailed discussion until you cover Part 4.

17.5     Metrics for Web Engineering and WebApps

You should note that most WebApp metrics are in their formative stages and that further work remains to be done before reliable metrics are available. However, a WebE team can still gain benefit and insight from even the most rudimentary measures. These are presented here.

A discussion of the metrics presented in this section can be delayed until you cover Chapter 22, if you prefer.

17.6     ‘Worst Practices’ for WebApp Projects

Sometimes you learn more by discussing how not to do something, than by hearing about what to do. That’s the intent of this section. During lecture, I’d recommend that you provide examples of each worst practice and the resulting consequences.