Documente Academic
Documente Profesional
Documente Cultură
Revision History
Date Version Description Author
9/20/2006 1.0 s06211005
10/18/2008 1
Table of Contents
Table of Contents.....................................................................................................................2
Project Approaches:.................................................................................................................1
Project Goals, Objectives, Assumptions, and Constraints.......................................................1
Project Scope...........................................................................................................................2
Project Trade-off Matrix......................................................................................................2
Project Trade-off Matrix......................................................................................................2
Master Project Approach.....................................................................................................3
Development Approach.......................................................................................................3
Test Approach......................................................................................................................4
Training Approach...............................................................................................................4
User Support Approach........................................................................................................4
Communication Approach...................................................................................................4
Deployment Approach.........................................................................................................4
Operations Approach...........................................................................................................4
Milestone Approach.............................................................................................................4
Project Estimates..................................................................................................................5
Schedule Summary..............................................................................................................7
Schedule Summary..............................................................................................................7
Roles and Responsibilities...................................................................................................9
Knowledge, Skills, and Abilities*........................................................................................9
Team Structure...................................................................................................................11
Project Protocols................................................................................................................11
Risk and Issue Management Approach..............................................................................11
Configuration Management Approach...............................................................................12
Change Management Approach.........................................................................................12
Release Management Approach.........................................................................................13
Project Quality Assurance Approach.................................................................................13
Project Communication Approach.....................................................................................13
Team Environment Approach............................................................................................14
10/18/2008 1
Project Approaches:
Project Goals:
Our aim is to provide an application for XML coding which enables the XML coder to
create and manipulate XML documents.
Project Objectives:
The main features of this application are to provide user the ability to create, edit and save
XML document, some sort of way to validate the XML code that XML coder write as well
as application highlights the XML code by using colour codes and proper indentation
Project Assumptions:
1. Plate form(operations)
2. copy right
3.
Project Constraints:
1 time limitation
2 resources
3
4
Project Scope
[Description:
The Project Scope section defines the
1 tasks,
2 deliverables,
3 resources, and
4 schedule
Necessary to deliver the customer’s solution.
Note: when using the graphic, move the check marks to the appropriate boxes and
fill in the _____(blanks) within the sentence.
The Trade-off Matrix sets the default standard of priorities and provides guidance for
making trade-offs throughout the project. These trade-offs should be established up front
and then reassessed throughout the project’s life.]
10/18/2008 2
es
Sc
urc
he
so
Features
Features le ble
Resource
s
Schedul
e
Feature
Set
Given fixed Schedule, we will choose a resource, and adjust feature set as
necessary.
The Master Project Approach also describes how the various project teams will
collaborate to build and deploy the customer solution. This creates an awareness of the
dependencies among the teams.
This section should also include a description of the high-level work tasks to be
undertaken by each team. The work can be described in part by identifying what its result
or deliverable will be. This description can also include things such as tools,
methodologies, best practices, sequences of events, etc.
The Master Project Approach ensures that each team member understands how it will
contribute to the project’s overall success. In addition, it communicates to the customer
that Microsoft and its partners are working from a well-developed strategy. The Master
Project Approach evolves into the Master Project Plan during the planning phase.]
The sections below describe the project team’s approach to building the project work
packages.
[Note: The sections identified below are suggested categories. Modify these
categories to fit your project. ]
Development Approach
<<Begin text here>>
10/18/2008 3
Test Approach
<<Begin text here>>
Training Approach
<<Begin text here>>
Communication Approach
<<Begin text here>>
Deployment Approach
<<Begin text here>>
Operations Approach
<<Begin text here>>
Milestone Approach
[Description: The Milestone Approach identifies the significant events in the project’s
lifespan. During envisioning, these are usually expressed as External Milestones that
identify visible accomplishments of high-level deliverables and illustrate the project’s
schedule targets. At the highest level, External Milestones can be associated with the
completion of a specific project phase.
The Milestone Approach identifies the basis for establishing milestones. Depending on the
nature of the project, Milestones can be finance-based, progress-based, product-based,
and so on. The Milestone Approach defines this basis and identifies the milestone events
that will be tracked.
Describing Milestones early in the project establishes high-level time targets the customer
can confirm and the team must anticipate during its planning activities. It also identifies
the checkpoints where Milestone Reviews will occur to assess the project’s quality and its
results.]
At high level, the Milestones or goals in the lifespan of VUM Project are 7 which are:
1. Gathering & Analyzing Info
2. Envisioning the Solution
3. Planning the Solution
4. Development
5. Stabilizing
6. Deployment
10/18/2008 4
7. Viva Voice and presentation
Total 7 phases required to complete the Project of the EXWord. Project team will pass
through these above mentioned phases to successfully complete the whole development
process
The lifespan of each milestone vary by time allowed to achieve that milestone. In the
envisioning phase, the Project Team has to complete the 3 documents. This envisioning
phase has 7 days allotment in the Project Schedule. Project Team can take more than 7
days to complete this deliverable but in this case, they will get late for the next phase and
the Project Team has to work hard in the all remaining phases to complete the project
before the final allotted date.
Project Estimates
[Description: The Project Estimates section contains an estimate of the resources and
costs required for the project teams to accomplish their work. Resources include people,
equipment, facilities, and material. Costs are calculated by applying rates to each type of
resource requirement. This section should contain the following information, broken out by
each functional team:
Man Power:
Four out of four team members are available and are working on the whole
development process according to their responsibilities mentioned under the
heading “Roles and Responsibilities”
Equipments:
Software Equipments:
Required software equipments for development are following:
Platform (Microsoft Windows XP (5.1, Build 2600) Service Pack 2 Professional
Edition)
Documentation
Text (Microsoft Word Processor)
Graphics (Microsoft Visio)
Integrated development environments (NetBean, Microsoft visual studio)
Facilities:
Uninterruptible Power Supply (UPS)
Proper installation of software
Hardware maintenance
Clean, healthy environment
10/18/2008 5
The amount of the resource required
10/18/2008 6
Facilities B
Material C
Project Estimates provide information for calculating the budget estimate. They also
enable the project manager and team leads to identify the specific resources needed to
perform the work.]
<<Begin text here>>
Schedule Summary
[Description: The Schedule Summary section identifies and compiles the collective work
tasks and their calendar dates into a complete project schedule that identifies its
beginning and end dates. Each major Project Milestone is identified and assigned a
targeted completion date. The schedule is a consolidated schedule — it includes the work
and dates of all project teams.
The scheduling process is iterative. During the envisioning phase, the project’s Major
Milestones anchor the schedule. During the planning phase, the schedule will become
more granular as the work tasks are broken down.
The Schedule provides the basis for the customer to verify timelines and for the project
team to produce a constrained master plan from which it can validate proposed budgets,
resources, and timescales.]
<<Begin text here>>
Schedule Summary
Schedule/Work Plan Management consists of two perspectives: the high-level schedule
and dependencies, and the day-to-day tracking of work plan activities and task
completion.
The schedule management component consists of schedule timelines, dependencies and
resources, particularly where coordination with other external organizations is required.
The project schedule for EXWord was announced by the EXWord Project Instructor as a
framework. Constrained by the hard milestone dates specified in the Project Schedule
document, which is shown below:
10/18/2008 7
No. Phase Deliverables To Be Submitted Weight Allocated Submission
age(%age)
Days Date
0 Gathering & 1) Actors Catalog 10% 10 10/09/2006
Analyzing Info 2) Business Rules Catalog
3) Use cases & Usage
Scenarios
4) Glossary
1 Envisioning the 1) Vision Scope Document 05% 7 17/09/2006
Solution 2) The Risk Assessment
Document
3) The Project Structure
Document
10/18/2008 8
Roles and Responsibilities
10/18/2008 9
and support capabilities. This information is organized into functional teams and
responsibilities. At the highest level, the KSA can be based on the standard MSF roles.
Each functional team, or MSF role, is listed, and the team’s knowledge, skills, and abilities
requirements are defined alongside.
Justification: Knowledge, Skills, and Abilities information will facilitate the careful
selection of specific project participants and provide the basis for creating the core team
structure.]
<<Begin text here>>
Knowledge
i. Khurram
Base knowledge of Management such as
Finical management
Operations Research
HRM
Business Communication and Report writing
ii. Mubashir
Algorithms
Mathematical analysis
Software Engineering
Database
iii. Amjed
Modern Programming languages
Java, Visual C++
Databaseconstruction
iv. Yasir
HCI
Software Engineering
Theory of Automata
Skills
i. Khurram
Having skills to use the best use of the managerial skills in
right direction at right time and right directions
ii. Mubashir
Best logic building and Design structure skills for the
support of project and module designing
iii. Amjed
Development skills like to do programming in different
languages over different plate form and having the skill
adopt the new technologies required to manage the tools and
techniques and discuss documentations
iv. Yasir
Good skills of communication, software project management
and QA skills.
Abilities
10/18/2008 10
Team Structure
[Description: The Team Structure section defines the project’s organizational entities
(project manager, sponsor(s), steering committee, team leads, etc.), illustrates their
relationships to one another, and defines levels of responsibility and reporting structure.
When complete, the team structure assigns names to each organizational entity and
explicitly calls out the individual team (or team members) tasked with executing,
reviewing, and approving the project’s work. This assignment is spread across all entities
participating in the project: Microsoft, Partners, and Customer.
Hierarchy
Justification: The documentation of the project’s organizational structure ensures that all
project participants understand their roles in making the project a success, clarifies lines
of reporting and decision-making, and provides key stakeholders an opportunity to ensure
that the project’s organizational structure (project form) will facilitate the work (project
function).]
<<Begin text here>>
The EXWord teaming arrangements were initially developed based on the interests,
experience and expertise. From that starting point and with the understanding that Team
Leader’s home institution, would serve as the EXWord lead institution, arrangements were
made there for doing project work.
The Team of EXWord Project consists of 4 members. All members are playing a
significant role in the EXWord Project.
The following team structure is defined over the skills and abilities
Project supervisor
Project Protocols
[Description: Project Protocols are the set of project processes that must be
standardized to ensure all project participants are performing the processes in the same
manner. This standardization creates performance efficiencies and facilitates a common
language among the project stakeholders.]
10/18/2008 11
must be sufficiently detailed to facilitate the risk and issue management process during
the envisioning and planning phases. It must also make it possible to categorize issues as
product issues or project issues. This section will include the following:
Justification: The Risk and Issue Management documentation ensures that all project
participants understand their responsibilities in identifying and managing risks and issues,
and that all project personnel are using the same risk and issue management processes.]
<<Begin text here>>
Risk and issue management approach:
Risk management is a continuous process beginning in Phase I and continuing through
launch and orbital operations. Activities include planning for risk, assessing (identifying
and analyzing) risk areas, developing risk mitigation plans, and monitoring risks to
determine how they have changed over time, and implementing risk mitigation plans in a
timely manner. Risks can enter the project as technical or programmatic risks. Although the
Team Leader, QA & testing Manager and the Lead Designer will identify most risks,
risks can be identified by anyone in the project team at any time. The Team Leader is the
owner of the risk management process. Team Leader will continuously monitor the risk
management process to ensure that risks are being reported, tracked, and dealt with in a
proactive manner.
10/18/2008 12
Change request form
Roles and responsibilities of change management activities
Reference to the contractual change order from the Customer Contracting
Approach section
This section includes the transition plan (release to production) and plans for back-out
processes. The approach should be compliant with the Microsoft Operations Framework
(MOF) Release Management Process.
Justification: This information ensures that the project plans for and follows an orderly
process of solution test and implementation, thus limiting the impact on the customer’s
operational environment and ensuring that environment is operationally ready to receive
the release.]
<<Begin text here>>
Quality expectations
Process for assurance (audit, reviews, contractor controls)
Process for control (peer reviews, inspections, tests)
Quality organization (entities, roles, and responsibilities)
Templates for the Product Review, Project Milestone Review, and Customer
Approval reports
Training requirements
10/18/2008 13
identifies the processes, methods, and tools required to ensure timely and appropriate
collection, distribution, and management of project information for all project stakeholders.
It also describes the team’s strategy for communicating internally among team members
and company personnel, as well as externally with vendors and contractors.
The progress report is an important document that should be detailed in this section. It
describes how to collect and distribute the non-financial metrics and qualitative
information that pertain to project progress, team performance, schedule slippage, risks,
and issues that impact the project. The progress report should summarize completed
work, report on milestones, and highlight new risks.
The user communication section should include the processes, methods, and tools that
will explain the solution to the customer and user communities to ensure rapid and
trouble-free adoption of the solution. This should identify the key points along the project
cycle where the solution will be presented to the users and provide a description of what is
presented (user requirements, functional specifications, prototypes, etc.). This section
should identify responsibilities for creating and delivering the user communication and
identify a process for collecting user feedback for incorporation into technical documents
and the solution.
10/18/2008 14
In addition to requirements, this section should determine infrastructure staging and the
roles and responsibilities for environment setup. If necessary, the requirements can be
identified by team role (development, logistics, testing, user education, etc.).
Justification: The Team Environment Approach ensures that the working environment is
readily available in the timeframes set by the project schedule.]
<<Begin text here>>
10/18/2008 15