Initial Project Plan Assignment 2

Resource Allocation system An Initial Project Plan

Introduction Resource allocation is a main part in managing any projects Resource allocation some recognizing the best available resources for the project, assigning them to company team and monitoring their workload throughout the work, and re-assigning resources if needed. Resource allocation system project team members are 1.Amel 2.K.L.P. Pramodya de Silva In this project we are both collaborate equally. Tasks done by Pramodya  An Initial requirement models  A Risk List  A master plans  An initial project plans

In this resource allocation project Tasks Done by Amel are: -  Project vision  A proposed architecture  A technical competency demonstrator  An inception phases. In our process we used slack as our communication method. We had meetings in every week at the class. We discussed about the project and had plans to achieve this project goals.

Project Practices and Measurements There are some technical practices used in the project. Such as Scrum, Lean (LN), Crystal, DSDM, Adaptive software development and Agile unified process. That process is the main agile technical practice we used throughout this project. Agile unified process is an iterative and incremental process consisting of four subprocesses or workflows. The components have been modified number of times to create number of variations. The unified process contains the rational unified process (RUP) and open unified process (Open UP). In our project Unified process is the main technical practise which we used. Technical practices such as Iterative development is a way of breaking down large project into smaller parts and complete it. By Iterative development software will be quicker and early during the software life cycle. Also, it’s more flexible. Continuous Integration is a development practise and it requires developers to integrate code into shared repository several times. This method verified each method by automated build. And it allows team to detect problems early. Independent testing is an inferential statistical test that determines whether there is a statistically significant difference between the means in two unrelated groups. How we Track the process of the project are First, we create Deadlines for each task so that we can track the progress of each and every task. In our project there are only two members. So, in our meeting we create project outline for track the project progress. Checked regularly: we checked the project progress regularly, our communication mechanism slacked helped us in this process to track the progress. Established goals and milestones Setting up tailored goals and milestones with each member of the team also goes a long way toward team satisfaction. It’s important to stress each team member’s role and how it will contribute to the success of the team. Keeping the big picture in mind is always important, even while implementing smaller goals and points of progress. System Overview

Functional Requirements

1. FR01: Provide a web interface that allows managers to view project and resource.  FR01.1: Resource Utilize overview  FR01.2: Project overview  FR01.3: personnel Overview

2.FR02: Provide a web interface to allow Managers to modify personnel and project information  FR02.1: Add new personnel to the project  FR02.2: Edit project attributes  FR02.3: Update project progress

3.FR03: Provide printable reports  FR03.1: Resource Availability reports.  FR03.2: Client programme / project report

FR04: Interface with database to retrieve personnel information Non-Functional Requirements • NFR01: RAS Must be able to be accessed from any location with internet access. • NFR02: RAS must be able to scale as zirous grown in size. • NFR03: RAS must be an easier to use than the current spreadsheet solution • NRF04: RAS must be able to handle multiple concurrent users’ employees using the system. • NFR05: The web interface must be responsive to user input. • NFR06: RAS must be developed in a manner that makes it easy to maintain and improve the future.

System Design RAS employs three-tiered architecture. We used the model-view-Controller (MVC) architectural design Patten. In MVC terminology the "Model" is seen as the actual information in an application. The "view" is the User interface, everything that the user will see when using the application. The "Controller" manages communication between the model and the view and manipulates that data according to the business rules. The framework encapsulates the view and controller concepts of the MVC architecture. In order to render a page for the end user the user first requests the page from the server. The controller will then analyses the request and invoke the correct action class to handle the request. The Action class will check the state of the application (the model, accessed using Hibernate) and return an appropriate response through the view.

Project milestones and objectives

Milestones in our project as below: - Our project milestones were phases. Phases means the start and end of work phases such as proof of concept.  Communication: Project meetings and communication mechanism.  Decisions: Decisions take by each and everyone in the team.  Design: Complete and review of the design  Planning: Completion and approval of the plan Resources:  Processes: Commencement or completion of the process ex: Testing start.  Integrations: Getting things connected and work together.

Objectives Project objectives are goals, plain and simple. These are the business objectives that you want the project to accomplish. Within project management, it is of utmost importance that a project's objectives are stated clearly as these will impact every decision in the project lifecycle. Project objectives must be measurable and contain key performance indicators that will be used to assess a project's success

Subject Phase Iteration Dates Primary objectives (risks and use case scenarios) ITC303 – Software Development Project 1 Inception Phase I-1 11/03 – 12/03 Establish Vision Establish Initial Use Case Model Complete Preliminary Non-functional Requirement Analysis Identify/Document Candidate Architectures Establish Version Control I-2 28/03 – 10/04 Establish Risk List Complete Full Description for Critical Core Risky Difficult (CCRD)Use Case Implement Technical Competency Demonstrator Create Test Plan Establish Initial Project Plan Deliver Life Cycle Objectives Milestone (LCOM) Complete Inception Phase Project Assessment Elaboration Phase E-1 11/04 – 24/04 (Session Break) Mitigate Highest Priority Risk(s) Implement Highest Priority Architectural Element(s) to Support CCRD Use Case Complete Development Testing for Highest Priority Architectural Element(s) E-2 25/4 – 8/05 Mitigate 2nd Highest Priority Risk(s) Implement 2nd Highest Priority Architectural Element(s) to Support CCRD Use Case Complete Development and Integration Testing for 2nd Highest Priority Architectural Element(s) E-3 9/05 – 22/05 Mitigate 3rd Highest Priority Risk(s) Implement 3rd Highest Priority Architectural Element(s) to Support CCRD Use Case Complete Development and Integration Testing for 3rd Highest Priority Architectural Element(s) Deploy Executable Architecture in Trial Environment Complete Internal User Acceptance Testing for CCRD Use Case in Trial Environment E-4 23/05 – 3/06 Contingency Deliver Life Cycle Architecture Milestone (LCAM) Complete Elaboration Phase Project Assessment Mid-year Semester Break   Mid-year Semester Break ITC309 – Software Development Project 2 Construction Phase C-1 11/07 – 24/07 Implement 2nd Highest Priority Use Case(s) Complete Development and Integration Testing for 2nd Highest Priority Use Case(s) Complete Internal User Acceptance Testing for 2nd Highest Priority Use Case(s) C-2 25/07 – 7/08 Implement 3rd Highest Priority Use Case(s) Complete Development and Integration Testing for 3rd Highest Priority Use Case(s) Complete Internal User Acceptance Testing for 3rd Highest Priority Use Case(s) C-3 8/0 – 21/08 Implement 4th Highest Priority Use Case(s) Complete Development and Integration Testing for 4th Highest Priority Use Case(s) Complete Internal User Acceptance Testing for 4th Highest Priority Use Case(s) C-4 22/08 – 4/09 (Session Break) Contingency Deliver Initial Operation Capability Milestone (IOCM) Complete Construction Phase Project Assessment Transition Phase T-1 5/09 – 18/09 Deploy Application in Trial Environment Complete 1st Round External User Acceptance Testing Resolve Any Identified Issues T-2 19/09 – 2/10 Complete 2nd Round External User Acceptance Testing Resolve Any Identified Issues T-3 3/10 – 14/10 Contingency Deliver Product Release Milestone (PRM) Complete Final Project Assessment

Resource Allocation system Use-Case: Brief Description

This use case describes the process involved in allocating resources to a project. It covers operations like creating a project, selecting and allocating resources to a project, updating project status and cancelling a project. The project manager performs all these operations. It also covers operations like viewing projects assigned to a resource, tasks covered under a project, entering actual and estimated time to complete a project. Also, business sponsors can view the status of the sponsored projects.

Actors Employees, Project Managers,Manager Pre-Conditions The manager should initiate a request with the system to trigger the resource allocation process and resources should be available.

Normal Flow

1. Project manager raise a request to create a project
2. After creation of a project, resources (IT professionals) are selected for the project and assigned to it.
3. The project can also be cancelled by the manager.
4. Business sponsors can login to the system and view the status of the projects sponsored by them
5. Project managers can update the project status based on project planning, implementation.
6. IT professionals can view the projects assigned to them, tasks under the projects.
7. Once tasks are assigned the resources can enter the estimated time for the task
8. Once task is completed the resources can enter the actual time for the completed task.

Actor System Project manager Manages the employees The use case ends.

Alternate Flows If the project proceedings are not successful, then the project manager can cancel the project Actor System Project manager Manages the project

Sub flows Obtain workers information.

Key Scenarios Key scenarios can be defined as any scenario that meets one of the following requirements Architecturally significant use case. Intersection of quality attributes with