ITT545:WEB ENGINEERING

CHAPTER 8: Web Project Management

PREPARED BY: NOR AIMUNI MD RASHID/ UiTM CAWANGAN MELAKA KAMPUS JASIN
Chapter Outline
 Introduction
 Understanding Scope
 Refining Framework Activities
 Building a Web Team
 Managing Risks
 Developing a Schedule
 Managing Quality
 Managing Change
 Tracking the Project
Chapter Objectives & Outcomes

 By the end of this chapter, student should be able to:

 Explain steps in managing a web project.
 Identify risk, refine framework activities, developing a schedule and managing
quality.
8.1 UNDERSTANDING SCOPE
 SCOPE OF WEB PROJECT
 1. Context: It informs the way by which the Web application will meet the
business requirements.
 2. Information objectives: It is related with the deliverables produced for the
customers.
 3. Functionality: The functions invoked by the end user or by the Web
application itself to meet the user’s requirements, as defined in use cases.
 4. Constraints: These are also a sort of requirements only like technical,
economic, managerial and environmental constraints.
 Technical constraints are related to the birth of new technologies like new
programming languages or new operating systems.
 Economic constraints refer to the money constraints;
 managerial constraints are related to the management stress on the Web
project that is going on, and
 environmental constraints refer to introduction of new operating systems,
system software etc.
Divide-and-conquer Strategy

 Use by developer to solve complex problem

 divide a complex problem into smaller sub-problems,
find solutions to these sub-problems, and then, combine
them all together to get the solution as a whole.
 Web Project Management
 the tools and the techniques used in the Web project management
are characterized by the current transition from traditional software
development methods to agile methods.
 Web project management ties the technical product development
to the economic product manufacturing.
 Web project surrounded by certain constraints like costs, time-
deadlines, resources and quality. Time is short, budget is small and
Web projects are very complex.
 WPM should include the following:
1. Leadership (organize, control, lead staff and inform);
 2. Development (set, plan, define objectives);
3. Monitoring (check and control).
 CHALLENGES OF WEB PROJECT MANAGEMENT
 1. Web projects are small, complex and more vulnerable to attacks. To cope
with these challenges, Web project management makes use of the reusability
concept.
 2. Web project teams are heterogeneous, i.e., they have mixed type of people.
 3. In Web projects, problems like ambiguous, unclear and incomplete planning
tasks, regular changes in planning and defects in the project organization result
in poor planning of Web projects in hand.
 4. It is difficult to do manpower estimations in Web projects, as the artists in a
Web team are very much creative and innovative.
 5. It is difficult to get alternative solutions to the Web development as
compared to the traditional software.
 6. Newer development languages, newer operating systems, regularly
changing user’s requirements, and complexity of Web applications have a very
high impact on Web applications.
8.2 REFINING FRAMEWORK ACTIVITIES
 A Web engineering team must consider the following three
aspects for further refinement:
 1. Modeling: It includes a model that understands the tasks
needed to develop analysis and design model, which assists
the Web team in the project work.
 2. Construction: This involves the tasks needed for code
generation and testing; either manual or automated test tools
may be used.
 3. Deployment: This involves the tasks that deliver the Web
applications to the end users, who evaluate it and provide
feedback.
8.3 BUILDING A WEB TEAM
 Guidelines To Build An Effective Web Team

 1. Team guidelines must be established, which includes what is

expected from each team member and how it is to be dealt with.
 2. Team leaders and project managers must motivate their team
members for better results.
 3. Team should involve both formal and informal free flowing of
information for exchange.
 4. Every team member should promise to give his/ her best.
 5. It is easy for a Web team to start, but it is difficult to sustain such
teams.
 Characteristics Of A Good Team Leader

 1. A good team leader must motivate team members by giving allowances and
other incentives.
 2. A good team leader should be able to reuse the existing processes or invent
new ones that will help the team in the conversion of initial product into the final
form.
 3. A good team leader should be innovative (to create new ideas) enough and
he/ she should encourage the team members for the same.
 4. A good team leader should focus more on understanding of the problem,
manage flow of ideas and should work towards improvement of the quality of
the end product.
 5. A good team leader should have a problem-solving management style
instead of problem-creating type.
8.4 MANAGING RISKS
Web risk management is an umbrella activity, i.e., it
must be carried out throughout the WSDLC.
A Web team must look risks from the following two
angles:
1. Risk impact on the entire Web application;
2. Risk impact on successful deployment of the Web
application increment currently being engineered.
 There are two levels at which these issues must be considered,
which are given below:
1. At the project level, several risk-related questionnaires need
to be answered.
For example, can the Web application be delivered on time and
within available cost limits? Will the requests for change impact
delivery schedules? Does the Web team understand the Web
development models, methods, tools and technologies?
 2. At the increment level, the concerns are more focused.
Here, queries are answered. For example, has the
communication strategy collected required information for
modeling, construction and deployment? Is the refined
process framework suitable for the next Web increment to be
developed? Are the Web content and its functions properly
defined?
 RISK CATEGORIES
1. A product risk involves some potential problems
related to the Web content, functions, constraints or
performance.
2. A process risk involves some problems that are
related to the framework actions and tasks chosen by
the team.
3. People risk involves WebE team, stakeholder or
people involves directly with the WSDLC
Risk Assessment Table (RAT)

 ri is the risk identified and i

ranges from 1 to n,
 li is the probability of the
likelihood of the risk
associated
 xi is the impact of the risk.
8.5 DEVELOPING A SCHEDULE
 Estimations Of A Web Project

Web estimations involve the following two

methods:
1. Usage scenario-based estimations;
2. Product-process table-based estimations.
 USAGE SCENARIO-BASED ESTIMATIONS

the Web team examines the use cases that are defined
for the Web project and answers whether they can be
reused for the next increment of the Web project.
Based on the team’s past history, an estimate (value),
Eavg, is calculated.
It is the average effort [in person-months (p-m) or
person-years], which is required to deploy a usage
scenario.
 USAGE SCENARIO-BASED ESTIMATIONS
But, in order to estimate the next Web project increment
(improved version), we count the number of usage
scenarios and multiply by Eavg.
Note that the number can be adjusted based on the
complexity of the use cases.
Once the effort is made, it can be then scheduled
(distributed) across Web engineering tasks along the project
time and cost limits. Also, the estimate may be used to find
out the legitimacy of the delivery dates for every increment
(newer versions).
 USAGE SCENARIO-BASED ESTIMATIONS

 The relationship among people, effort and time is not linear, i.e., it is not
necessary that increasing the team size will deliver the Web project at an
early date. Rather, it may increase the delivery date of the Web project.
PRODUCT-PROCESS TABLE-BASED
ESTIMATIONS

 all major Web engineering actions are listed in the first column of the
table.
 All content objects and functions are listed in the first row.
 Then, the need is to estimate the amount of effort (in p=m) required to
perform the Web engineering action for each content and function.
8.6 MANAGING QUALITY
 PAIR WALKTHROUGH VS
TEAM WALKTHROUGH
 Pair walkthrough: A member of Web engineering team works in
association with a specific stakeholder (may be from the
marketing department) to produce a part of the analysis model
like a graphical explanation of the GUI. The Web engineer works
with this marketing person and conducts an ongoing pair
walkthrough.
 WALKTHROUGH GUIDELINES

 Team walkthrough: the entire team may review the work product.
 1. The product is reviewed and not the producer. The errors should be
pointed out. The walkthrough should be loose and constructive. It
should not depress other team members.
 2. The agenda of the review must be decided and maintained, as
required.
 3. The debates, controversies and fights among participants should be
limited. The issues should be noted down for later discussions.
 4. A walkthrough is not a problem-solving session.
 5. Notes should be written on your laptop or notepad.
 6. The walkthrough should be completed within 60 to 90 minutes only.
8.7 MANAGING CHANGE
 Rules in Managing Changes

Rule 1: The (n + 1) st Web model implements content

and functionality associated with the increment, and it
may also do changes to the content and functionality
requested for the nth increment. Another metric to
specify the criticality and the impact of change is to
put the required changes in the form of priorities level.
 Rules in Managing Changes
Rule 2: Reduce problems with the next version.
A change associated with version n should generally be
addressed only after version n is initially deployed, i.e.,
delay changes while project is going on, but make
changes only after the increment has been delivered for
the first time.
Changes can be made as a part of the current
increment only in certain exceptional cases like some
legal demand is there or serious damages may occur if
the changes are not made immediately or Web usage
will fall down if the changes are not made, and doing
changes is better than delaying them further.
 Rules in Managing Changes
Rule 3:Web tasks that fall into the first category need
not be updated as changes are requested and made.
But, the work products in the second category should be
modified to reflect any changes so that they remain
useful in the remaining Web activities.
8.8 TRACKING THE PROJECT
 10 Signs Project In Jeopardy
 1. The Web team does not understand the customer’s
requirements.
 2. The scope of a Web project is not properly defined.
 3. Changes are not managed properly.
 4. The chosen Web technology changes.
 5. Business needs of a company also keep changing.
 6. Deadlines of Web projects are unrealistic.
 7. End users are not actually interested in the Web app.
 8. Web team does not have sufficient manpower to work.
 9. Best methods, models, technologies and guidelines are not
used by the Web team.
 Precaution Guidelines for Outsourcing

1. Internal communications must be done.

2. Rough Web design may be developed internally by the
organization.
3. Estimated internal project schedule must be
developed.
4. Job responsibilities of both internal and external or
outsourced teams must be identified.
5. Validity of the vendor should be established.