hey this is a master project for final semester so its have partsland i want one person to deal with it overall
we have to make a project on topic : PROPERTY MANAGEMENT SYSTEMso the first task is : Project storyboardi have uploaded the assignment 1 please do as it as given formatand please make sure it should be 100% plagrism free
i am going to send the filesso far you have to do assignment 1 which is due on 2/8/2019 till morning
ITECH1004_ITECH5004_Introduction to Multimedia Week 2: Agile Project Management Artefacts * Agile today means using a method based on iterative and incremental development, in which requirements and solutions evolve through collaboration. Agile emphasises: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan* Agile Project Management * * According to the Scrum Alliance, Scrum is the leading agile development method for completing projects with a complex, innovative scope of work. Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements. (-Wikipedia) Scrum * Week 2 - Project Selection & Project Life Cycles Scrum is an iterative and incremental agile software development methodology for managing product development. It defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal", challenges assumptions of the "traditional, sequential approach" to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines in the project. https://en.wikipedia.org/wiki/Scrum_(software_development) https://www.youtube.com/watch?v=Wo5dg5GY5Yg Week 2 - Project Selection & Project Life Cycles itech 3213-5213 Intro to ITPM * itech 3213-5213 Intro to ITPM * Scrum Framework * For more details on Scrum, read Case 2 of Chapter 3 of Schwalbe, 2014 Week 2 - Project Selection & Project Life Cycles Scrum participants: product owner, scrum master, scrum team Scrum Artifacts include: Product backlog, Sprint backlog, and a Burndown chart Product backlog: A list of features prioritized by business value Sprint backlog: The highest-priority items from the product backlog to be completed within a sprint Burndown chart: Shows the cumulative work remaining in a sprint on a day-by-day basis Scrum ceremonies: sprint planning session, daily scrum, sprint reviews, and sprint retrospectives Week 2 - Project Selection & Project Life Cycles itech 3213-5213 Intro to ITPM * itech 3213-5213 Intro to ITPM * Scrum Framework Week 2 - Project Selection & Project Life Cycles http://www.c-sharpcorner.com/UploadFile/d9c992/the-agile-scrum-framework/ Week 2 - Project Selection & Project Life Cycles itech 3213-5213 Intro to ITPM * itech 3213-5213 Intro to ITPM * Artefacts Product Vision Statement Product Roadmap Product Backlog Release Plan Sprint Backlog Increment * * Sprint—an example Week 2 - Project Selection & Project Life Cycles Schwalbe, 2014, pp126. Week 2 - Project Selection & Project Life Cycles itech 3213-5213 Intro to ITPM * itech 3213-5213 Intro to ITPM * Product vision statement An elevator pitch, or a quick summary, to communicate how your product supports the company’s or organization’s strategies. The vision statement must articulate the goals for the product. * * Product Roadmap: The product roadmap is a high-level view of the product requirements needed to achieve the product vision. It also enables a project team to outline a general timeframe for when you will develop and release those requirements. The product roadmap is a first cut and high-level view of the product backlog. * * Product Backlog: The full list of what is in the scope for your project, ordered by priority. After you have your first requirement, you have a product backlog. * * Release plan A high-level timetable for the release of working software/solution. * * Sprint Backlog The goal, user stories, and tasks associated with the current sprint. * * Increment The working product functionality, demonstrated to stakeholders at the end of the sprint, which is potentially shippable to the customer. * * Requirements Analysis High level analysis of client's requirements Stakeholder analysis High level project goals and scope High level project timeline and milestones Constraints, assumptions and dependencies * * Project progress By now, you should have: High level understanding of the project Meeting with your supervisor (Planned) First meeting with your client Assigned team responsibilities Team and supervisor meeting planning * Assessment reminder Project Storyboard– by the end of Week2 Remember, it has to be signed by project supervisor, Client, and project team. * Business Requirements “A requirement is: A condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.” International Institute of Business Analysis Business Analysis Body of Knowledge 2.0 * Who defines Business Requirements? Client or customer User representatives Subject matter and industry experts Stakeholders * Understanding Business Requirements To ensure correct inclusion of all requirements To determine project objectives To consider the best possible solution(s) To reduce confusion and rework! Requirements cannot be accurately defined if all stakeholders are not actively participated. Make sure you will interact with all stakeholders – clients (and their users if required). * Requirement Analysis First step in any project It is very important to have clear and thorough understanding of your clients’ business requirements – do not rush to solutions immediately. Do everything you possibly can Read written specifications and any other documents provided by the client Observe client’s business activities and processes. Interview stakeholders – users, clients Document requirements and check with clients if you understood their requirements – go through several iterations. * Cost of NOT defining requirements Focus shifts to creating a solution Problem forced to fit the solution Solution may not fulfill clients’ expectations You may fail to deliver the project. * Managing requirements List all requirements (User stories) Classify and Prioritize them – how critical to business (functional vs non-functional) Identify critical requirements – very helpful in managing project Understand relationships and dependencies Document everything * Defining project goals and objectives Goals are final outcomes of the project - your aspirations! Objectives are the exact steps undertaken to achieve goals. - should be specific, quantifiable and measurable. S - specific, significant, stretching M - measurable, meaningful, motivational A - agreed upon, attainable, achievable, acceptable, action-oriented R - realistic, relevant, reasonable, rewarding, results-oriented T - time-based, time-bound, timely, tangible, trackable * Feasibility study An assessment of the practicality of the proposed project Is the proposed project doable or achievable? Technical feasibility – is all required technology available? Operational feasibility – do you have all required skills? Economic feasibility – can your client afford or does it worth investing? - Benefits vs costs - Return on investment (ROI) * Acquiring project resources How are you going to acquire all required resources for the project Technology – Hardware/Software, Data etc. - Purchase, Licensing, renting (technology as service) - Who will provide those resources (you or your client) Human resources – you may lack some skills in your team - How are you going to fulfill those skill shortages - Seeking help from someone else or hiring someone when required You need to plan ahead – because you will have a tight schedule during project execution, you can’t afford to wait for something later on. * Useful Links https://www.dummies.com/careers/project-management/agile-project-management-artifacts/ https://venngage.com/blog/product-roadmap/ https://venngage.com/blog/product-roadmap/ * Product Lifecycle * A project life cycle is a collection of project phases that define what work will be performed in each phase what deliverables will be produced and when who is involved in each phase, and how management will control and approve work produced in each phase A deliverable is a product or service produced or provided as part of a project Project Life Cycle * * Generic Project Life Cycle (PMI, 2013) * Products also have life cycles Distinguishing life cycles project life cycle applies to all projects, regardless of the product product life cycle models vary considerably based on the nature of the product most large IT products are developed as a series of projects project management is done in all product life cycle phases Project Versus Product Week 2 - Project Selection & Project Life Cycles itech 3213-5213 Intro to ITPM * Product life cycles are concerned with product development Project life cycles are concerned with project management Week 2 - Project Selection & Project Life Cycles itech 3213-5213 Intro to ITPM * PRODUCT: these constitutes the deliverables and outcomes to be developed and delivered to the client as a solution to the project problem. Products may include Software Applications; Change Management Plan; Business Model; Systems Evaluation Report; Training/User Manuals, deployment plan…e.t.c USER STORIES*: a series of single-sentence statements describing the use(s) of proposed products. Project Outcome - Products User Stories * Functionality and the associated benefit of the functionality. In an Agile environment, projects are commonly comprised of a large number of user stories representing various levels of system/product user. The user story describes the type of system/product user, what functionality they want, and why they want it (or why it’s beneficial). The format of a user story is: As a (type of user), I want to (feature/function) so that (reason/benefit). Agile User Stories * The purpose of the agile user story is to encourage collaboration among the project team for each defined function of the system/product/solution being developed. While user stories represent a simplified approach to defining functionality, the challenge for the project team is developing user stories with the appropriate level of detail. Agile User Stories * All user stories should be developed with the expectation that once completed, the functionality defined in the agile user story will add value to the final product. If it does not add value to the finished product then it should be avoided. The Characteristics of a User Story * User Stories should be developed and written collaboratively by the project team. This development must also include input and feedback from the ultimate customer or product owner. The user stories represent a tool to facilitate team communication and collaboration instead of a formal specification or requirement. Not only does this collaboration encourage all of the team to contribute to the project, but only through the eyes of the customer or product owner do we know for certain what does or does not add value. How to compose User Stories * Finding the appropriate level of detail for user stories is often a challenge for the team. User stories should be general enough to provide a description of the functionality and the benefit while also allowing for innovation and creativity for developing a solution. They should not be so detailed as to lock the team into only one way of accomplishing the solution. Agile user stories * Independent – user stories should not be sequential or locked into a specific order. The team should be able to develop the user stories in any sequence. Negotiable – user stories should be flexible and without too much