project structure document

22
EXWord Project structure Document Version 1.0 Revision History Date Version Description Author 9/20/2006 1.0 s06211005 08/27/2022 1

Upload: api-3824962

Post on 10-Apr-2015

663 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Project Structure Document

EXWordProject structure Document

Version 1.0 

Revision HistoryDate Version Description Author

9/20/2006 1.0 s06211005

       

04/11/2023 1

Page 2: Project Structure Document

Table of ContentsTable of Contents.......................................................................................................1Table of Contents.......................................................................................................2

Project Approaches.........................................................................................................3Project Goals, Objectives, Assumptions, and Constraints.........................................3Project Scope..............................................................................................................3

Project Trade-off Matrix.........................................................................................3Master Project Approach........................................................................................4Milestone Approach...............................................................................................5Project Estimates....................................................................................................6Schedule Summary.................................................................................................6

Roles and Responsibilities..........................................................................................6Knowledge, Skills, and Abilities............................................................................7Team Structure.......................................................................................................7

Project Protocols.........................................................................................................7Risk and Issue Management Approach..................................................................7Configuration Management Approach...................................................................8Change Management Approach.............................................................................8Release Management Approach.............................................................................9Project Quality Assurance Approach.....................................................................9Project Communication Approach.........................................................................9Team Environment Approach..............................................................................10

04/11/2023 1

Page 3: Project Structure Document

Project Approaches:

Project Goals, Objectives, Assumptions, and Constraints

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 right3.

Project Constraints:1 time limitation2 resources34

Page 4: Project Structure Document

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.

The tasks are expressed in the 1. Master Project Approach, 2. the Milestone Approach, 3. the Project Estimates, and 4. the Project Schedule.

These multiple views allow the customer and project team to look at the project from different perspectives and to analyze how the work is organized.The tasks, deliverables, resources, and schedule exist at a high level of detail. These Project Scope statements provide the context for more detailed planning during follow-on project phases.]<<Begin text here>>

EXWord lies between the development environments. XML coder will be the main user of EXWordUsing EXWord XML files could be created and manipulated using the graphical views by XML coderData definition possible very easily and flexibly by using the EXWord with any invalid xml code by redistricting the user to a non editable coding viewThese xml file could be validated and test against a specific schemaThe XML files contain data definition and not be executed and tested along with web HTML files by using our softwareThe generated code by the EXWord could be saved as file print or could be used as data source files are these are tested against a schema and validated easily embedded into any system

Project Trade-off Matrix[Description: The Project Trade-off Matrix is a table that represents the customer’s preferences in setting priorities among schedule, resources and features.

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.]

Project Trade-off Matrix

04/11/2023 2

Page 5: Project Structure Document

Given fixed Schedule, we will choose a resource, and adjust feature set as necessary.

Master Project Approach[Description: The Master Project Approach is the roll-up of all the project teams’ approaches. This includes an overall statement of strategy for the project and individual strategy statements for each team. A strategy statement describes a general approach to accomplish work without associated metrics.

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>>

04/11/2023 3

FeaturesFeaturesFeaturesFeaturesFeaturesFeatures

ChosenChosenFixedFixed AdjustableAdjustable

ScheduleSchedule

Feature SetFeature Set

ResourcesResources

Page 6: Project Structure Document

Test Approach<<Begin text here>>

Training Approach<<Begin text here>>

User Support 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 Info2. Envisioning the Solution3. Planning the Solution4. Development5. Stabilizing6. Deployment7. Viva Voice and presentation

04/11/2023 4

Page 7: Project Structure Document

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:

A list of resource types

Following resources are available for our project.

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:

Hard ware Equipments:Required hardware equipment for development are 2 (two) Desktop Computers. These computers should base on Inter architecture with standard I/O devices. Software Equipments:Required software equipments for development are following:Platform (Microsoft Windows XP (5.1, Build 2600) Service Pack 2 Professional Edition)DocumentationText (Microsoft Word Processor)Graphics (Microsoft Visio)Integrated development environments (NetBean, Microsoft visual studio)

Facilities:Uninterruptible Power Supply (UPS)Proper installation of softwareHardware maintenanceClean, healthy environment

The amount of the resource required

04/11/2023 5

Page 8: Project Structure Document

Amount of Man PowerAmount

Available 4Required 3-4Deployed 4

Hardware Amount/ capabilityDesktop PCs 2Architecture Intel(R) Celeron(R) CPU 1.70GHzStandard I/O devices

Output devices AmountDigital Colour Monitors supported with Standard Display Cards

2

Input Devices AmountStandard PS2 Mouse, Microsoft Standard Key board

2 each

CD ROM 2Flash Drive 1

Power Equipments

Device AmountUPS 2

Software Type Name Amount/ CapabilityPlatform Microsoft Windows

XP (5.1, Build 2600) Service Pack 2 Professional Edition

2 installed copies on both desktop PCs

Documentation software Microsoft Word Processor

2 installed copies on both desktop PCs

Microsoft Visio 2 installed copies on both desktop PCs

Integrated Development Environments

NetBean 2 installed copies on both desktop PCs

Microsoft visual studio

2 installed copies on both desktop PCs

The rate applied to each resource

Resource Rate AppliedMan Power A+Hardware resources ASoftware resources AFacilities BMaterial C

04/11/2023 6

Page 9: Project Structure Document

The cost of each resource

Total days 157Total working days 135Daily working hours 2Total Working Hours for Unit man Power 269

daily working hours = 1 unit 8Units for one man power 34

Total Man Power Units 135

Total cost of resources for each functional team

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 SummarySchedule/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:

No. Phase Deliverables To Be Submitted Weight age(%age)

Allocated Submission

04/11/2023 7

Page 10: Project Structure Document

Days Date

0 Gathering & Analyzing Info

1)      Actors Catalog2)      Business Rules Catalog3)      Use cases & Usage

Scenarios4)      Glossary

10%10 10/09/2006

1 Envisioning the Solution

1)      Vision Scope Document2)      The Risk Assessment

Document3)      The Project Structure

Document 

05% 7 17/09/2006

2 Planning the Solution

1)      Functional Specification2)      Master Project Plan3)      Master Project Schedule4)      Risk Management Plan

30%30 17/10/2006

3 Development 1)      Development Plan2)      Source Code  

20% 30 16/11/2007

4 Stabilizing 1)      Test Plan2)      Test Cases 

05% 7 23/11/2007

5 Deployment 1)      Deployment Plan2)      Release Note3)      Installer

05% 07 30/11/2007

6 Final Evaluation & Viva Voice

1)      Presentation Document2)      Final Project Report  

25%  05 05/12/2007

The graphical view of the Project Schedule is show below:

The development of these seven complete deliverables presents special scheduling challenges for EXWord Project team. When project team completes one deliverable then it will send it to VU Project Instructor for checking. Every deliverable has its own dead date to submit, but it’s not necessary to send it before on the dead date, Project team can send it after that individual deliverable dead date, but the whole project (all deliverables) should be submitted before the dead date of the project which is 5th of December.

Roles and Responsibilities

04/11/2023 8

Page 11: Project Structure Document

Roles and Responsibilities

04/11/2023 9

Page 12: Project Structure Document

Khurram Sohail [email protected]

Team Leader

Key Roles & Responsibilities

i. Keeping the team on track

ii. Assigning units of work

iii. Leading meetings

iv. Scheduling team and client meetings

Mubashir [email protected]

Lead Designer

Key Roles & Responsibilities

i. Lead the team in all prospects of design

ii. Helping in code segment

iii. Structure design, interface design

Amjed [email protected]

Project Developer

Key Roles & Responsibilities

i. Handling the developing process

ii. Coding the project

iii. Analyzing the information generated

iv. Finalizing the solution

Muhammad [email protected]

QA & Testing Manager

Key Roles & Responsibilities

i. Overseeing the testing process

ii. keenly observing testing criterion

iii. Overseeing all module, integration, system and acceptance

Knowledge, Skills, and Abilities*

[Description: The Knowledge, Skills, and Abilities section specifies the requirements for project participants. This is expressed by defining the knowledge, skills, and abilities needed to conduct the project. These requirements should include technical, managerial, 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.

04/11/2023 10

Page 13: Project Structure Document

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>>

Knowledgei. Khurram

Base knowledge of Management such asFinical managementOperations ResearchHRMBusiness Communication and Report writing

ii. MubashirAlgorithmsMathematical analysisSoftware EngineeringDatabase

iii. AmjedModern Programming languagesJava, Visual C++Databaseconstruction

iv. YasirHCISoftware EngineeringTheory of Automata

Skillsi. Khurram

Having skills to use the best use of the managerial skills in right direction at right time and right directions

ii. MubashirBest logic building and Design structure skills for the support of project and module designing

iii. AmjedDevelopment 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. YasirGood skills of communication, software project management and QA skills.

Abilities

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

04/11/2023 11

Page 14: Project Structure Document

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. HierarchyJustification: 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 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.]

Risk and Issue Management Approach[Description: The Risk and Issue Management Approach section describes the processes, methods, and tools to be used to manage the project’s risks and issues. It 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:

Description of risk and issue management processes, methods, and toolsSchedule/frequency of risk and issue management activities

04/11/2023 12

Project supervisor

Mr. Khurram SohailTeam Leader

Main Client Contact

Mr. Mubashir IqbalLead Designer

Mr. Amjed PervizProject Developer

Mr. Muhammad YasirQA & Testing Manager

Page 15: Project Structure Document

Roles and responsibilities within the risk and issue management processSpecifications of the risk/issue assessment form and the issues resolution form

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.

Configuration Management Approach[Description: The Configuration Management Approach section defines how all the project’s deliverables (hardware, software, management and technical documents, and work in progress) will be tracked, accounted for, and maintained. Configuration Management includes project documents, the development and test environments, and any impact on the production environment. This section will include the following:

Description of configuration management processes, methods, and toolsProcesses to request configuration changes (steps, approval levels)Roles and responsibilities for configuration managementVersion-control standards for documents

Justification: Configuration Management documentation ensures that the project can maintain object and document integrity so that a single version is used at all times.]<<Begin text here>>

Change Management Approach[Description: The Change Management Approach section describes how the project’s scope will be maintained through structured procedures for submitting, approving, implementing, and reviewing change requests. The change management process is charged with providing prompt and efficient handling of any request for change. This section should include the following:

Change management processes, methods, and toolsComposition of the Change Advisory BoardChange request formRoles and responsibilities of change management activitiesReference to the contractual change order from the Customer Contracting Approach section

04/11/2023 13

Page 16: Project Structure Document

Justification: Documenting the Change Management Approach helps the project maintain a timely single perspective of the project’s scope (both project activities and products produced) and ensure that only contracted work is undertaken.]<<Begin text here>>

Release Management Approach[Description: The Release Management Approach section describes the processes, methods, and tools that coordinate and manage releases of the solution to the different test and production environments. It describes the processes of coordinating and managing the activities by which all releases to the production IT environment are planned, tested, and implemented.

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>>

Project Quality Assurance Approach[Description: The Project Quality Assurance Approach section defines how the project intends to deliver products that meet the customer’s quality expectations and Microsoft/Partner quality standards. It addresses both the project’s management and the development of the project’s product. This section should include the following:

Quality expectationsProcess 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 reportsTraining requirements

Justification: A well-developed Product Quality Assurance Approach is key to managing customer confidence and ensuring the development and deployment of a golden solution.]<<Begin text here>>

Project Communication Approach[Description: The Project Communication Approach section defines how and what the project will communicate with its stakeholders. This communication occurs within the team and between the team and external entities. The Project Communication Approach 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.

This section includes the following:

04/11/2023 14

Page 17: Project Structure Document

Project Stakeholders and their communication requirementsTypes of communications (progress reports, change management requests, configuration management documentation, release management documentation, risks and issues, financial reports, project plans, technical specifications, etc.) and their standard configurations and mediaCommunication type ownersProject organization/distribution listsCommunication infrastructure requirements (tools, internal and external tracking systems, etc.)

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 Project Communication Approach should be organized into two sections: communication within the project and user communication.

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.

Justification: A well-developed Project Communication Approach ensures that information is available to its users in a timely manner to facilitate decision-making. It sets the expectations with the customer and the project teams that information will be distributed in a standardized fashion and on a regular basis.]<<Begin text here>>

Team Environment Approach[Description: The Team Environment Approach section defines the approach for creating the project team environment. It defines the physical environment requirements needed to conduct the project and the plan to establish that environment. Environmental elements include at least floor space (offices, meeting rooms, etc.) and equipment (computers, desks, chairs, telephones, etc.). The requirements should also define the location of the environmental elements and their proximity to each other. It also describes tools, systems, and infrastructure needed by the team, such as version-control software, developer tools and kit, test tools and kit, etc.

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>>

04/11/2023 15