Download WebApp Development: A Framework for Effective Engineering and more Schemes and Mind Maps Web Application Development in PDF only on Docsity!
WEB PROJECT MANAGEMENT
5.1 UNDERSTANDING SCOPE
Much of the early effort expended during the communication activity focuses on a definition of WebApp scope. Scope is defined by answering the following questions:
Context:
How does the WebApp fit into a business context, and what constraints are imposed as a result of the context?
Information objectives:
What customer-visible content objects are used and produced by the WebApp increment?
Functionality:
What functions are initiated by the end user or invoked internally by the WebApp to meet the requirements defined in usage scenarios?
Constraints and performance:
What technical and environmental constraints will impact the framework activities that follow? What special performance issues will require design and construction effort?
Because it is difficult, to develop a meaningful plan without understanding the scope of the WebApp increment, the information derived during the communication activity must be examined with care. If scope is unclear at this stage, you have a bit of work to do before planning can commence.
5.2 Web Project Management
What Communication Work Products Are Relevant?
All communication work products are relevant to the planning activity. In some cases, the only information available may be your written notes and a set of usage scenarios that provide a description of the content and functions for the WebApp increment. If you take a more formal approach to communication, the following work products may be available for the planning activity:
Statement describing business motivation for the overall WebApp
Statement of overall objective for the WebApp
List of user categories
List of informational goals for the WebApp increment to be planned
List of applicative (functional) goals for the WebApp increment to be planned
Description of the increment (the statement of scope)
List of content objects for the increment
List of functions for the increment
Set of usage scenarios that describe how each user category will interact with the increment
Although it’s wonderful when all this information is available, it’s not necessarily sufficient for the planning activity. The information developed during the communication activity may not be as complete as the WebE team would like. It’s important to know what to do when this occurs.
What If Further Details Are Required to Understand the Increment?
Human beings have a tendency to apply a divide-and-conquer strategy when they are challenged with a complex or unclear problem. Stated simply, the problem is partitioned into smaller problems that are more understandable. Because the communication activity makes no attempt to fully define every aspect of the content and functions to be delivered by the WebApp, an elaboration strategy can be used when further details are required to understand the scope of the WebApp increment in a more complete manner. Elaboration begins with the information that has been developed as part of the communication activity. It is applied in two major areas: to the content that is to be delivered with the WebApp increment and to the functions that are invoked as part of all user scenarios for the increment.
SafeHomeAssured.com WebApp implemented two usage scenarios:
- Develop a layout of the space to be monitored.
- Get recommendations for sensor layout for my space.
5.4 Web Project Management
Functions (associated with ―space‖):
Specify and draw walls
Specify and draw doorways
Specify and draw windows
Compute size of each room
Save/retrieve a named space
Security protection is required
Update/delete a named space
Security protection is required
Print a named space
... and so on for all functions associated with this increment. The amount of effort associated with this elaboration is relatively small, but the payoff can be significant. For example, you now know that the team will have to develop at least seven functions associated with the creation of a user space.
What If Gaps Still Exist in Your Understanding?
You cannot expect to achieve comprehensive understanding at the planning stage. You’ll have to accept the fact that things remain a bit uncertain, even after you’ve elaborated the information derived during the communication activity—it’s one of the risks inherent in all engineering work. More important, you’ll have to complete the planning activity with imperfect information and move on. As you move further into the WebE process, your understanding will improve as modelling is conducted. However, it’s reasonable to assume that there will be a few surprises as construction proceeds. The team will have to adapt and move forward. The work associated with this is allocated as part of the planning activity.
5.2 REFINING FRAMEWORK ACTIVITIES:
The WebE team must now choose the framework actions and tasks that are right for the remaining WebE work to be applied to the increment.
The following framework activities must be refined for use on the increment to be built:
Modelling: Actions and tasks that lead to the creation of analysis and design models that assist the WebE team and other stakeholders to better understand the WebApp and how it is to be constructed.
Construction: Actions and tasks required for code generation (either manual or automated) and testing.
Web Engineering 5.
Deployment: Actions and tasks that deliver the WebApp increment to the end users who evaluate it and provide feedback based on the evaluation.
What Actions and Tasks Are Required?
WebE framework actions and tasks are refined by ―melding‖ characteristics of the increment and the process. One way to accomplish this is to create a table similar to the one illustrated in Figure 5.1. The top row of the table lists the key content objects and functions to be delivered as part of the increment deployment. The first column lists the set of framework actions and tasks for modelling, construction, and deployment.
The WebE team selects the set of actions and tasks that are most appropriate for the WebApp increment to be engineered. Although some team members will argue in favour of a very sparse list, it is best to spend the time to develop a set of actions and tasks that will lead to a high-quality result. It’s worth noting that just because a task is listed in the table it does not necessarily have to be used for every content object and function. The final decision is left to the Web engineer who will do the work. However, if the Web engineer decides to forego the WebE task, he or she must be able to justify the decision and is ultimately responsible for the quality of the work product produced.
Figure 5.1 Melding the problem and the process.
Web Engineering 5.
―I have a very strong feeling that the stakeholders are going to change their minds about this capability,‖ he states, ―and we’re going to have to update this collection of diagrams again and again. It’ll waste time.‖
Everyone pauses for a moment. The Web engineer has made an excellent point. If changes to the content and functionality are likely, the work products in question will have to be updated with each change—a time-consuming and potentially error prone task. What to do? The team leader ponders the situation for a moment.
―What if we create the work products assuming that no changes will occur. They’ll be really useful to guide design,‖ she says. ―If you’re right and the stakeholders do change their minds, we’ll jettison these diagrams and make appropriate changes to the design itself.‖ The team spends a few moments discussing this and then revisits its decision.
What Is the Appropriate Way to Assess Quality?
You can do it right, or you can do it over again. If a WebE team stresses quality in all framework activities, the team reduces the amount of rework that it must do. That results in lower costs and, more importantly, improved time-to-market. But it’s not enough to talk the talk by saying that quality is important. You have to explicitly define what you mean when you say ―WebApp quality‖ and define a set of tasks that will help ensure that every work product exhibits high quality.
In order to ensure the quality of work products as they are produced, the WebE team can conduct pair walkthroughs. This approach, adapted from the concept of pair programming in the Extreme Programming method, suggests that all work products be reviewed by a pair of Web engineers. The producer of the work product presents it to another team member who looks for errors, inconsistencies, and omissions. Working together, the pair tries to improve the quality of the work product. In cases where the work product is complex or its impact will be critical to the success of the project, the WebE team may schedule a team walkthrough—a review form that involves a number of team members and is guided by a distinct set of rules.
How Should Change Be Managed?
If you don’t manage change, it manages you. And that’s never good. It’s very easy for a stream of uncontrolled changes to turn a well-run WebE project into chaos. For that reason, planning for change is an essential part of the planning activity. Changes arise from a number of different sources: (1) nontechnical stakeholders may have an afterthought about the WebApp in general or the increment that is currently being developed, (2) end users may request different modes of interaction or demand different functions or content, or (3) Web engineers may learn that unexpected modifications are required to achieve WebApp requirements. In every case, the change that is requested must be described unambiguously, evaluated to determine the impact on the increment and the overall WebApp, and assessed to estimate the level of effort required to make the change. The problem is that all these change management activities take resources and time—things that are often in short supply as the WebE team is working on an increment. Yet, stakeholders want the changes to be made.
5.8 Web Project Management
5.3 BUILDING A WEB TEAM:
Web engineering highlights agility, and the agile philosophy stresses the importance of individual capability coupled with teamwork. These are critical success factors for a WebE team. To make effective use of the capabilities of each team member and to foster effective collaboration throughout a project, WebE teams should be self-organizing. In the context of Web engineering, self-organization implies three things:
(1) The WebE team organizes itself for the work to be done,
(2) The team organizes the process framework to best accommodate its local environment,
(3) The team organizes the work schedule to best achieve delivery of the WebApp increment.
Self-organization has a number of technical benefits, but more importantly, it serves to improve collaboration and boost team morale. In essence, the team serves as its own management. Ken Schwaber addresses these issues when he writes: ―The team selects how much work it believes it can perform within the iteration [increment], and the team commits to the work. Nothing demotivates a team as much as someone else making commitments for it. Nothing motivates a team as much as accepting the responsibility for fulfilling commitments that it made itself.‖
Why Don’t Teams Jell and What Can Be Done to Help?
Sadly, a WebE team can suffer from team toxicity—a malady defined by five factors that ―foster a potentially toxic team environment‖:
- A furious work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed.
- High frustration caused by personal, business, or technological factors that causes friction among team members.
- ―Fragmented or poorly coordinated procedures‖ or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment.
- Unclear definition of roles resulting in a lack of accountability and resultant finger- pointing.
- ―Continuous and repeated exposure to failure‖ that leads to a loss of confidence and a lowering of morale.
In general, each of these toxins can be avoided if the WebE team is self-organizing. A self-organizing team has access to all information required to do the job, thereby avoiding a frenzied work environment in which people are scrambling to find vital information. A self- organizing team has control over the process that is employed, the work products that are produced, the work schedule that is defined, and the quality and change management activities
5.10 Web Project Management
Respect for individual talents is critical: Not everyone is good at everything. The best teams make use of individual strengths. The best team leaders allow individuals the freedom to run with a good idea.
Every member of the team should commit: The main protagonist in Kidder’s book calls this ―signing up.‖
It’s easy to get started, but it’s very hard to sustain momentum: The best teams never let an ―insurmountable‖ problem stop them. Team members develop a ―good enough‖ solution and proceed, hoping that the momentum of forward progress may lead to an even better solution later in the project.
What Are the Characteristics of a Good Team Leader?
Motivation: The ability to encourage technical people to produce to their best ability. This can be accomplished by providing incentives for high performance and imposing consequences for poor performance.
Organization: The ability to form existing processes (or invent new ones) that will enable the initial concept to be translated into a final product.
Ideas or innovation: The ability to encourage people to create and feel creative even when they must work within bounds established for a particular WebApp.
5.4 MANAGING RISK:
Risk management includes a series of tasks that help a WebE team to understand and manage the many problems that can plague a WebApp project. A risk is a potential problem it might happen, it might not. But, regardless of the outcome, it’s a really good idea to identify it, assess its probability of occurrence, estimate its impact, and establish a contingency plan should the problem actually occur. A WebE team considers risk at two different levels of granularity: (1) the impact of risk on the entire WebApp project, and (2) the impact of risk on the successful deployment of the WebApp increment currently being engineered.
At the project level, many risk-related questions must be asked and answered:
Can planned WebApp increments be delivered within the time frame defined? Will these increments provide ongoing value for end users while additional increments are being engineered? How will requests for change impact delivery schedules? Does the team understand the required Web engineering methods, technologies, and tools? Is the available technology appropriate for the job? Will likely changes require the introduction of new technology? At the increment level, concerns are more basic. Has the communication activity developed sufficient information for modelling, construction, and deployment? Is the refined process framework appropriate for the increment to be developed? Does the team have the right mix of skills to build this increment? Are content and function adequately defined? Does the increment pose a technology challenge? Risk management is initiated during the planning activity but is actually an umbrella activity that is revisited throughout the process flow. The
Web Engineering 5.
challenge for a WebE team is to do enough of it to be proactive about risk, but not so much that it slows other development work to a crawl.
How Do We Identify Risks?
At some point during the planning activity, the WebE team collectively addresses the fundamental question: ―What can go wrong?‖ Each team member is asked to make a list of risks that can be organized into one of the following categories: (1) people risks, (2) product risks, and (3) process risks. People risks are potential problems that can be directly traced to some human action or failing. For example, it’s likely that the WebApp increment will require components developed using XML, but the team currently has no one with XML experience. A technology-related people risk has been identified. Or maybe a specific stakeholder has been uncooperative in the past when information requests have been made, and yet, the required information is crucial to a successful outcome. A communication-related people risk has been identified. Product risk can normally be traced to potential problems associated with WebApp content, functions, constraints, or performance. For example, a risk that could impact the tight delivery time for the first SafeHomeAssured.com increment is discovered only after construction has commenced. A major content object is outdated and may require substantial modification before it can be deployed. A performance risk associated with a later SafeHomeAssured.com increment (in-home video monitoring) might be questionable control and monitoring interfaces for video and audio equipment.
Process risks are problems that are tied to the framework actions and tasks that have been chosen by the team. In some cases, too much process can be a potential risk. For example, the team has decided to do a thorough analysis model and has specified actions and tasks to accomplish this. For the fourth increment of the SafeHomeAssured.com WebApp (implement a layout for the space to be secured and recommend sensors for that space), a process risk might be that the work associated with developing a complete analysis model may be too time consuming and will cause a delay in design and construction activities. The lists of possible risks are collected from team members and consolidated by category. The WebE team then meets to evaluate them.
How Do We Evaluate Risks?
Once a consolidated list of risks has been developed, the WebE team performs a quick evaluation. Each risk is briefly discussed and evaluated in two ways: (1) the likelihood or probability that the risk will become a reality, and (2) the consequences of the problems associated with the risk, should it occur. The intent is to consider risks in a manner that leads to prioritization. No WebE team has the time or the resources to address every possible risk with the same degree of rigor. By prioritizing risks, the team can allocate resources where they will have the most impact.
Web Engineering 5.
mean that the WebE team simply ignores high-priority risks. The members of the team consider each risk that falls above the cutoff line in the risk table and answers three questions:
- How can we avoid the risk altogether?
- What factors can we monitor to determine whether the risk is becoming more or less likely?
- Should the risk become a reality, what are we going to do about it?
The answers to these questions can be recorded (as informal notes) by the team leader.
5.5 DEVELOPING A SCHEDULE
The reality of any technical project is that hundreds of small tasks must occur to accomplish a larger goal. Some of these tasks lie outside the mainstream and may be completed without worry about impact on the completion date. Other tasks lie on the ―critical path.‖ If these critical tasks fall behind schedule, the completion date for the WebApp increment is put into risk.
The WebE team’s objective is to list all WebE actions and tasks for an increment, build a network that depicts their interdependencies, identify the tasks that are critical within the network, and then track their progress to ensure that any delay will be recognized ―one day at a time.‖ To accomplish this, the team leader must have a schedule that has been defined at a degree of resolution that allows progress to be monitored and the project to be controlled.
WebApp project scheduling is an activity that allocates the estimated effort for specific WebE tasks across the planned time line (duration) for building an increment. It is important to note, however, that the overall WebApp schedule evolves over time. During the first iteration of the WebE process framework, a macroscopic schedule is developed. This type of schedule identifies all WebApp increments and projects the dates on which each will be deployed. As the development of the increments gets under way, the entry for the increment on the macroscopic schedule is refined into a detailed schedule. Here, specific WebE tasks (required to accomplish an activity) are identified and scheduled.
Scheduling for WebE projects can be viewed from two rather different perspectives. In the first, an end date for the release of a WebApp has already been established. The WebE organization is constrained to distribute effort within the prescribed time frame. The second view of WebApp scheduling assumes that rough chronological boundaries, that the end date is set by the WebE organization. Effort is distributed to make best use of resources, and an end date is defined after careful analysis of the WebApp. Unfortunately, the first situation is encountered far more frequently than the second.
What Is Macroscopic Scheduling?
As an example of macroscopic scheduling, consider the SafeHomeAssured.com WebApp. Seven increments were identified for the project:
5.14 Web Project Management
The WebE team consults and negotiates with stakeholders and develops a preliminary deployment schedule for all seven increments. A time line for this schedule is illustrated in Figure 5.3. It is important to note that the deployment dates (represented by diamonds on the time line) are preliminary and may change as more detailed scheduling of the increments occurs. However, this macroscopic schedule provides management with an indication of when content and functionality will be available and when the entire project will be completed. As a preliminary estimate, the team will work to deploy all increments with a 12-week time line. It’s also worth noting that some of the increments will be developed in parallel. This assumes that the team will have sufficient people to do this parallel work.
Figure 5.2 Time line for macroscopic project schedule
Increment 1: Basic company and product information
Increment 2: Detailed product information and downloads
Increment 3: Product quotes and processing product orders
Increment 4: Space layout and security system design
Increment 5: Information and ordering of monitoring services
Increment 6: Online control of monitoring equipment
Increment 7: Accessing account information
What Is Increment Scheduling?
Once the macroscopic schedule has been developed, the team is ready to schedule work tasks for a specific increment. To accomplish this, you can use a generic process framework that is applicable for all WebApp increments. Atask listis created by using the
5.16 Web Project Management
Design mechanisms for selecting security system components (sensors, cameras, microphones, etc.).
Develop procedural details for the graphical layout of security system components.
Conduct pair walkthroughs as required.
These tasks become part of the increment schedule for the fourth WebApp increment and are allocated over the increment development schedule. They can be input to scheduling software (e.g., Microsoft Project) and used for tracking and control.
How Do We Estimate Effort and Time?
The focus of estimation for most WebE projects is on macroscopic, rather than microscopic, issues. The WebE team assesses whether a planned WebApp increment can be developed with available resources according to defined schedule constraints. This is accomplished by considering each increment’s content and function as a whole. In essence, members of the WebE team ask, ―Can we deploy the fourth SafeHomeAssured.com increment with three people working for 5 weeks, given our current understanding of the increment, the risks that we’ve identified, and the task list that we’ve defined for the work?‖
If the team answers ―yes,‖ consistently and without hesitation, no further estimation activities are required. On the other hand, if the team has fear about a delivery date that was forced on them by one or more stakeholders, two options are available: (1) voice your concerns but proceed anyway, or (2) do a small amount of detailed estimation in an effort to help yourselves and your stakeholders better understand the resources and time required.
There are two feasible approaches to detailed estimation for WebApps. The first, usage scenario–based estimation, examines the usage scenarios (e.g., use cases) defined for the increment to be built. Examining the team’s past history, you establish a value Eavg, which is the average effort (in person-days) required to deploy a usage scenario. To estimate the increment, count the number of usage scenarios and multiply by Eavg. The number can be adjusted based on the perceived complexity of the usage scenarios. Once the effort is determined, it can be distributed across WebE actions and tasks along the project time line. Finally, the estimates can be used to assess the validity of the deployment dates for the increment. Figure 5.4 illustrates this approach for the fourth SafeHomeAssured.com increment, where the past history for the team indicates that Eavg=14 person-days.
Figure 5.4 Usage scenario–based estimation.
Web Engineering 5.
Both usage scenarios to be implemented are considerably more complex than average with complexity multipliers of 2.5 and 2.0, respectively. Hence, the overall effort required to implement the fourth increment is estimated to be 63 person-days to be distributed over a delivery period of 5 weeks.
It’s time for a word of caution. Inexperienced teams (and team leaders) assume a linear relationship exists between people, effort, and time. That is, if 63 person days are required to model, construct, and deploy an increment, the work could be accomplished by one person working for 63 days, two people working for 32 days, three people working for 21 days, and so forth. Sadly, a linear relationship does not exist. In reality, as more people become involved in a project, more effort is spent on communicating and coordinating (meetings, e-mail, etc.). Additional time is spent on things that have nothing to do with the project (e.g., telephone calls, coordinating the softball league), administrative issues (e.g., applying for a new health insurance plan), and other ―non-productive‖ work. As a consequence, it may take three people 25 or more calendar days to achieve 63 person-days of effort.
Figure 5.5Product process table for estimation.
A second estimation approach uses a product-process table. In this approach, all major WebE actions are listed in the first column of the table. All major content objects and functions for an increment are listed in the first row. Team members estimate the amount of effort (in person-days) required to perform the WebE action for each content object and function. Figure 5.5 illustrates this estimation approach for the fourth SafeHomeAssured.com increment. This effort appears to be a bit more optimistic than scenario-based estimates. Both must be reconciled to provide a single estimate. The relatively complex content and functionality of increment 4 demands considerably more WebE effort than earlier increments.
Web Engineering 5.
- Quality problems found by end users are almost always much more expensive to correct than they would have been had they been uncovered earlier in the WebE process flow. Fixing a design error before the WebApp is constructed can be many times less expensive (in expended effort) than trying to correct a deployed WebApp.
- Every problem uncovered by end users demands rework, and rework absorbs resources (people and effort) that would have been applied to the next increment. The overall project falls behind schedule.
- Early users may not fully exercise the increment, leaving content and function untouched. Quality problems may exist in these untouched areas. They will be discovered later (and if you believe Murphy’s law) at the worst possible time.
It is therefore advisable for every WebE team to focus on WebApp quality as increments are being engineered. But where do you focus?
What Quality Assurance Mechanisms Can the Team Use?
Although quality problems can arise from a variety of sources, their origins can often be traced to a failure to understand or achieve the needs of end users. Therefore, the first quality assurance mechanism for Web engineering is a thoughtful, thorough communication activity. If care is taken as requirements gathering is conducted, then there will be less likelihood that errors. Inconsistencies or omissions will not be passed into subsequent framework activities. The pair walkthrough can be used to assess the quality of all work products developed as part of communication. In this case, the walkthrough participants include a Web engineer and one or more stakeholders.
Once requirements for content, function, constraints, and performance are passed forward to the modelling activity, analysis and design tasks commence. In every case, analysis and design models should be assessed for quality. At a minimum, the WebE team can create a generic checklist that you can use to assess the model. For more complex or critical models, a pair walkthrough can be conducted for each model that is created.
Once the WebApp increment code has been generated, a systematic sequence of tests can be initiated to assess the quality of the increment. It is important to note that tests must exercise all user requirements and at the same time examine technical aspects of the increment. The results of all quality assurance mechanisms should be recorded. This will assist the team when changes must be made and will also help the team to correct process weaknesses that led to a class of errors.
What Are the Mechanics of a Pair Walkthrough?
A pair walkthrough was an effective and agile mechanism for ensuring the quality of work products (e.g., analysis and design models, HTML or XML code, various scripts, and content and functions) that are produced as a consequence of WebE activities. As an example of the mechanics of a pair walkthrough, we’ll consider a portion of the analysis model of the fourth increment of the SafeHomeAssured.com WebApp. This increment implements a layout
5.20 Web Project Management
for the space to be monitored and recommends sensors for that space. A member of the WebE team, working in conjunction with a specific stakeholder from the marketing department, produces a portion of the analysis model. As the interface model is developed, the Web engineer works together with a knowledgeable stakeholder and conducts an ongoing pair walkthrough. Both the Web engineer and the stakeholder review the interface model as it evolves, addressing questions such as:
Is there anything about the page layout that is problematic?
Are menu items meaningful, complete, and intuitive?
Is the space layout scheme easy to use? Intuitive?
Can you envision how you’d navigate to this page and from it to other functionality and content?
Have we missed any key functionality or content on this page?
What are you assuming about this model?
These and other questions are addressed repeatedly as the model evolves. The result is ongoing corrections and/or modifications to the model.
What Are the Mechanics of a Team Walkthrough?
There are situations in which the entire WebE team will review a work product. This situation occurs when the work product (e.g., a navigation design) may have broad impact for the entire WebApp, and hence it is important that everyone understands the issues and has input into the review. Two team members use the ―pair programming‖ approach to develop some aspect of the WebApp. Once they are convinced that the work product is complete in draft form, the pair asks other members of the team to participate in a team walkthrough. The producers give the other reviewers any information that has been produced (either in hard copy form, if feasible, or in electronic form). The reviewers promise to spend at least 30 to 45 minutes reviewing the work product and listing any issues, problems, or impressions based on the review. Within 24 hours, a team walkthrough begins. The producers of the work product begin by ―walking through‖ the work product, explaining what it represents and how the reader might interpret what is shown. As this occurs, the reviewers ask questions (often based on notes developed before the review) and point out potential problem areas. The producers note each of these without trying to solve them immediately. As the walkthrough proceeds, the participants follow these guidelines:
1. Review the product, not the producer: Conducted properly, the team walkthrough should leave all participants with a warm feeling of accomplishment. Conducted improperly, the walkthrough can take on the aura of an inquisition. Errors should be pointed out gently; the tone of the walkthrough should be loose and constructive; the intent should not be to embarrass or belittle, but rather to assist.
