jump to navigation

Proposal A September 7, 2005

Posted by Coolguy in Project Management.
Tags:
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: ,
add a comment

1. Executive Summary

2. Solution

2.1 Objectives

  • 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

3. Project Delivery

3.1 Analysis and scope

3.2 Development Phases

  1. Development Process to be used
  2. Start Up Phase
  3. Initiation Phase
  • Requirements Elicitation and Elaboration
  • Project Breakdown
  • Architecture and Design
  • Estimating and Scheduling
  1. Construction Phase: Staged Delivery with intermediate work products delivered before the entire project is completed
  2. Acceptance Phase
  3. Deployment Phase
  4. Closure Phase

4. Costs

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. Project Management

5.1 Roles

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

5.2 Scope management

5.3 Change Management

5.4 Quality Assurance

5.5 Risks management

5.6 Progress reporting

5.7 Metrics employed

6. Assumptions

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: ,
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.