Proposal A September 7, 2005
Posted by Coolguy in Project Management.Tags: Templates
add a comment
1 Executive Summary
1.1 Program Approach and Scope
- Initial Envisioning Phase followed by three iterative phases
- Envisioning Phase will mitigate risk and will allow for greater accuracy in time and budget forecasting
- If requirements are clearly defined and are unlikely to change as the project progresses, client may wish to sign off on the design for the entire solution before build commences; in this case, one would proceed without iterative development and implement the solution using a single development phase.
- Using a single Solution Planning and Development phase should reduce the project timescales
- The Envisioning Phase will involve a team of consulting company’s consultants and contributions from parents company employees.
- The deliverables of the Envisioning Phase are a clear design and plan for the completion of the solution.
- Resources to be used for iterative phases
- Timescales for deployment.
1.2 Schedule
- Initial Envisioning Phase which will last for (1-6) weeks.
- Estimated dates for completion
1.3 Pricing
- Envisioning Phase ~ Fixed price
- Time and Materials basis the estimate for the completion of the project
- After Envisioning Phase we will be better able to estimate the
complete price and time lines.
2 Company information
2.1 Background
- Registered address and detailes
- Inception date and articles of incorporation
2.2 Financial Stability
3 Organisation
3.1 Company profile
- Expertise: Training and certifications program
- Assets: Architectures and frameworks
- Experience: Customer engagements
3.2 Company locations
3.3 Management Structure
3.4 Knowledge Maintenance
4 References
5 Proposal Overview
5.1 Background
5.2 Scope
5.3 Objectives
- Increased efficiency of current processes.
- Improved customer service.
- Reduced training time for operator through the use of a common system.
- Increased ability to drive ‘add-on’ sales.
- A lower Total Cost Of Ownership (TCO) over the ageing technologies and
complex systems. - Future proofing.
- System resilience.
6 Solution
- Infrastructure
- Technical Architecture
6.1 Architecture Goals
- Satisfy the functional requirements
- Satisfy the non-functional requirements
- Smooth integration with pre-existing applications and infrastructure, if any
- Reuse of pre-existing systems and processes, if any
- Leverage best practices in solution and operating architecture
- Ease of migration from existing processes if any, to the new solution.
- Ease of maintenance
- To provide a good foundation for future
- To maximise the use of existing technology
6.2 Architecture Overview
- Modules and brief description
6.3 Enabling Architecture
- Technology to be used for auditing, logging, authentication, security
6.4 Infrastructure Architecture
6.4.1 High Level Architecture
- Directory services. Active directories
- Business logic: Microsoft BizTalk Server
- Workflow: Microsoft SharePoint Portal
- Database:
- Operations Management: MOM
6.4.2 Server Architecture
6.4.3 Infrastructure Components
6.4.4 Capacity
6.4.5 Authentication
6.4.6 Systems Management
- Operations Management
6.4.7 Resiliency
6.4.8 Disaster Recovery
6.4.9 Driving down TCO
- TCO consists of all Direct Costs (budgeted) and Indirect Costs (unbudgeted costs) over the lifespan of the IT System.
- Direct Costs
o Hardware/Software
o IT Operations
o Administration - Indirect Costs
o User Operations
o Downtime
6.4.10 Direct Costs
- Hardware/Software
- IT Operations
- Administration
6.4.11 InDirect Costs
- User Operations
- Downtime
- Future Proofing
7 Project Delivery Approach
7.1 Envisioning
7.1.1 Objectives
- To produce a project plan
- High level design
7.1.2 Deliverables
- High Level Requirements Document
- Project Initiation Document comprising:
o Scope Document – Definition of the scope and deliverables for the
implementation phases of the project.
o Risk Mitigation Plan – Identification of the risks to the
implementation phases of the project, and suggested mitigation
strategies.
o Project Plan – A Project plan for the implementation phases of
the project to deliver the scope stated in the Scope Document.
o Project Quality Plan – A description of the quality measures
to be taken to ensure the successful delivery of the project
scope.
7.2 Development Phases
7.2.1 Development Iteration(s)
7.2.1.1 Objectives
7.2.1.2 Deliverables
7.2.4 Stabilisation Phase
8 Deployment
8.1 Development and Staging
8.2 Live
9 Estimated Costs
9.1 Costs
9.2 Licenses
10 Schedules & Timeframes
11 Solution Delivery Methodology
12 Project Governance
12.1 Project Organisation
12.2 Role Descriptions
12.3 Scope management
12.4 Change Management Process
12.5 Testing
12.6 Quality assurance
12.7 Progress tracking & reporting
12.8 Risk Management and Exception Reporting
12.9 Skills transfer
Project Proposal Template September 7, 2005
Posted by Coolguy in Project Management.Tags: Proposal, Templates
add a comment
- 1.1 Approach & Scope: Phases and usecases
- 1.1 Cost and timelines
- Improving services by integrating
- Lowering Total Cost Of Ownership (TCO)
- Reducing leadtime between releases thereby increasing ability of the product to generate additional revenues by improvising on service offering for every release
- Future proofing
- Scalability of the Architecture and System resilience
2.2 Architecture/Infrastructure Overview
- Proposed Hardware Infrastructures for Production, Dev & QA
- Salient features of this architecture are:
Scalability
Geographical Redundancy
High Availability
Future Proofing
2.3 Interaction between other systems
2.4 System Overview Diagrams (Using presentation layer, Domain logic layer and data layer). Listing of modules with functionality
- Development Process to be used
- Start Up Phase
- Initiation Phase
- Requirements Elicitation and Elaboration
- Project Breakdown
- Architecture and Design
- Estimating and Scheduling
- Construction Phase: Staged Delivery with intermediate work products delivered before the entire project is completed
- Acceptance Phase
- Deployment Phase
- Closure Phase
4.1 Software Development Costs
- Effort required from Dev,Management, QA and Sys-Admin groups
- Break down by phases
4.2 Software Licenses Cost
4.3 Hardware Cost
5.1.1 Project Manager
5.1.2 System Analysts / Architects
5.1.3 Development Manager
5.1.4 Developers
5.1.5 Database Developers
5.1.6 User-interface specialist
5.1.7 QA Team
Scalabity
- The web server tier can be scaled linearly by installing additional web servers for handling incoming requests from HTTP clients as the load increases.
- The web servers will run identical configurations and can be included in the load-balancing mechanism without interruption of the service.
- Incoming requests from HTTP clients are dispatched via Apache to the application server tier.
- The application server tier can be scaled linearly by installing additional application servers running identical configurations as the load increases.
- This architecture provides near linear scalability of the application server tier from several hundred to hundreds of thousand concurrent user sessions.
- Clustering architecture of Oracle provides scalability to the database tier.
- Additional database servers can be added to the cluster without reconfiguring the application servers
Load Balancing
- Its usually a combination of hardware and software load-balancing.
- Load-balancing at the Web server tier can be implemented using a hardware load-balancer, using hardware like Radware, which distributes incoming HTTP requests to a cluster of identical Web servers, while maintaining sessions.
- Load-balancing at the application server tier is implemented in software between the Web server and application server using mod_jk from Apache Foundation.
- Load-balancing at the database tier can be implemented by using clustering mechanism of Oracle.
Redundancy
- High level of redundancy at all tiers, eliminates single-point-of-failure and thus ensures a high availability
- If a web server fails due to hardware or software failure, the hardware load-balancer will notice the failure when trying to dispatch incoming HTTP requests to the web server.
- It will mark the server as unavailable and will redirect the request to other Web server(s).
- Similarly if an Application server fails, all the requests would be redirected to the other available Application server(s).
- In case is the database, clustering mechanism would redirect the load to the available machine(s), transparent to the application.
- Geographical redundancy would be achieved by the third line of system hosted at a different data center.
Resilience, Fail over and Business continuity:
Resilience Requirements of any project could be met by
- Using redundant power supplies and applying RAID level 1 to handle address internal resilience
- Using more than one server at each tier to achieve system resilience
- Installing the solution across multiple data centers, to achieve geographical resilience
SRS Overview August 26, 2005
Posted by Coolguy in Business Analysis.Tags: IT Requirements, Templates
add a comment
- Background
- Business Context
- Requirements & Constraints:
Business Requirements: E.g: A admin should be able to report on details of the system audit log
Supplementary Business Requirements: E.g: The system should pre-populate
System Requirements: local failover capacity, geographically remote failover capacity
Design Constraints: Use cookies, change of password - Business Use Cases
- System Use Cases : Login,Auditing,Administer system users,Generate content,Local failover etc
- Glossary
- Actors
- Analysis Classes
Basics
- Functional requirements are things that a system has to do, like record a fact, do a calculation or make a decision. Functional requirements exist because of the subject matter within the context of the particular system. An airport system would have a functional requirement to record the landing time of a flight, a gardening system would have a functional requirement to fertilise the plants, a bottling system would have a functional requirement to fill the bottles.
- Non-Functional requirements (sometimes called qualities or attributes) are the qualities that a system has to have. Things like performance, security, usability,maintainability are all non-functional requirements. How fast does the bottling system have to fill a bottle, how convenient must it be for the gardener to fertilise the plants, who is permitted to look at the information about flights…these are all non-functional requirements.
- Project Goals are the reasons for doing a project. You can think of these as a type of high level requirement – all the other requirements contribute to meeting the project goals. The gardening system might have a goal of increasing the annual harvest of vegetables by 50%, maybe the airport’s target is to accommodate 20% more passengers and the bottling
system aims to reduce the number of defective products by an agreed amount. - Constraints are specified influences that affect the way that we meet the requirements. Perhaps the new airport system has to be operational within 1 year, the gardening system must only use organic products and the bottling system has a budget of 1 million Euros. The most common constraints are time, money and specified technology.