Consider expert Web developer will create a complete design, but time and cost can be appropriate
5. Consider expert Web developer will create a complete design, but time and cost can be appropriate
saved if the general look and feel of the WebApp is identified for the out- systematic
sourcing vendor (this can always be modified during preliminary stages of the redundancy at many
project). The design should include an indication of the type and volume of levels to allow some
degree of operation content to be presented by the WebApp and the types of interactive process- when failures
ing (e.g., forms, order entry) to be performed. This information should be occur.”
added to the product specification.
Tom Gilb
3. A rough project schedule, including not only final delivery dates but also mile- stone dates, should be developed. Milestones should be attached to deliverable versions of the WebApp as it evolves.
CHAPTER 29
WEB ENGINEERING
4. The degree of oversight and interaction by the contractor with the vendor should
be identified. This should include the naming of a vendor liaison and the iden- tification of the liaison’s responsibilities and authority, the definition of quality review points as development proceeds, and the vendor’s responsibilities with respect to interorganizational communication.
All of the information developed during these steps should be organized into a request for quote that is transmitted to candidate vendors. 11
Selection of candidate outsourcing vendors. In recent years, thousands of “Web design” companies have emerged to help businesses establish a Web presence or engage in e-commerce. Many have become adept at the WebE process, but many
“If you’re only willing others are little more than hackers. In order to select candidate Web developers, the to pay peanuts, you
contractor must perform due diligence: (1) interview past clients to determine the get monkeys.”
Web vendor’s professionalism, ability to meet schedule and cost commitments, and
from “The A Team”
ability to communicate effectively; (2) determine the name of the vendor’s chief Web engineer(s) for successful past projects (and, later, be certain that this person is con- tractually obligated to be involved in your project); and (3) carefully examine sam- ples of the vendor’s work that are similar in look and feel (and business area) to the WebApp that is to be contracted. Even before a request for quote is offered, a face- to-face meeting may provide substantial insight into the “fit” between contractor and vendor.
Assessing the validity of price quotes and the reliability of estimates. Because relatively little historical data exist and the scope of WebApps is notoriously fluid, estimation is inherently risky. For this reason, some vendors will embed substantial safety margins into the cost quoted for a project. This is both understandable and appropriate. The question is not “Have we gotten the best bang for our buck?” Rather, the questions should be
• Does the quoted cost of the WebApp provide a direct or indirect return on investment that justifies the project?
• Does the vendor that has provided the quote exhibit the professionalism and experience we require?
If the answers to these questions are, “Yes,” the price quote is fair. The degree of project management you can expect or perform. The formal-
ity associated with project management tasks (performed by both the vendor and the contractor) is directly proportional to the size, cost, and complexity of the WebApp. For large, complex projects, a detailed project schedule that defines work tasks, SQA
11 If WebApp development work is to be conducted by an internal group, nothing changes! The project is initiated in the same manner.
checkpoints, engineering work products, customer review points, and major mile- stones should be developed. The vendor and contractor should assess risk jointly and develop plans for mitigating, monitoring, and managing those risks that are deemed important. Mechanisms for quality assurance and change control should be explic- itly defined in writing. Methods for effective communication between the contractor and the vendor should be established.
Assessing the development schedule. Because WebApp development schedules span a relatively short period of time (often less than one or two months), the devel- opment schedule should have a high degree of granularity. That is, work tasks and minor milestones should be scheduled on a daily timeline. This fine granularity allows both the contractor and the vendor to recognize schedule slippage before it threat- ens the final completion date.
Managing scope. Because it is highly likely that scope will change as a WebApp project moves forward, the WebE process model should be incremental (Chapter 2). This allows the development team to “freeze” the scope for one increment so that an operational WebApp release can be created. The next increment may address scope changes suggested by a review of the preceding increment, but once the second incre- ment commences, scope is again frozen temporarily. This approach enables the WebApp team to work without having to accommodate a continual stream of changes but still recognizes the continuous evolution characteristic of most WebApps.
These guidelines are not intended to be a foolproof cookbook for the production of low-cost, on-time WebApps. However, they will help both the contractor and the vendor initiate work smoothly with a minimum of misunderstandings.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more