it unit 9 learning aim c project management distinction work
btec level 3 national diploma rqf it unit 9 learning aim c project management distinction work
it unit 9 learning aim c project managem
Written for
BTEC
PEARSON (PEARSON)
Information Technology 2016/2017 NQF
IT Unit 9 Learning Aim C Project Management (Dist
All documents for this subject (1)
Seller
Follow
AcademicAssignments
Reviews received
Content preview
lOMoARcPSD|3013804
lOMoARcPSD|3013804
Project Management
SOFTWARE DEVELOPEMENT
Project Phasing
To ensure the implementation of large-scale software development projects, they need
to be broken down into more manageable project components. With this thinking
we are going to begin our project by clearly mapping out the life of the project and
how we intend to follow all the deadlines and goals.
Before we begin the project, I must first phase the project and that begins by looking
at the user requirements we have been tasked with by the client. The term "user
requirements" refers to exactly what it sounds like. They are the end user's
requirements. These specifications specify how a facility, piece of equipment, or
process should perform in terms of the product to be manufactured, required
throughput, and manufacturing conditions.
However, the reason we are dividing the project into smaller tasks is so that a set task
can correspond to each and every stage of the methodology. In our case it will be
labelled an “agile sprint”, this may or may not be a collection of tasks but will be
decided at a later of date. I already analyzed extensively the project life cycle in
learning Aim A but will now look into in context of my current project.
, lOMoARcPSD|3013804
Project concept initiation – During this phase, which is currently ongoing, I as
the head of project management will summarize all the costs, benefits, user
requirements and requests with the feedback from the client and all stakeholders
who have input on this project. I will carry out this phase, through many different
means:
Identifying stakeholders
A project scope meeting
Breaking down requirements into smaller non-functional requirements
Acceptance of requirements documentation
Budgetary requirements
Risks and constraints
Project Initiation document
All of these documents/feedback will provide adequate information and scope for
stakeholders and product owner to give the greenlight for the project by highlighting the
requirements and constraints needed.
Definition and planning -
During the definition and planning stage we must get on with the tasks at hands as it
is an imperative part of the project life cycle and will most definitely be integrated
within our use of the agile methodology for the software production. It will be a
phase of continuation from the concept initiation including some important
documents that will most definitely be needed to produce in this stage:
Scope and Budget (further developed from the initial documents)
Work breakdown and schedule
Gantt Chart
Communication Plan
Risk Management (in more depth)
Launch and Execution –
Although concept gathering and planning is an important step for every project and
its development it is not the be all and end all of project management and the
software development. The execution of all the hard work put into the planning is
just as if not more important than the processes before it with this in mind I have put
in steps to place more importance on the execution phase for example:
PAGE 1
, lOMoARcPSD|3013804
Placing importance on status and tracking to make sure all targets are met
Key performance indicators and using a range of different software’s
Quality indicators (How the quality of the software is reflected)
Forecasts
Performance and control –
As contracted for EBITS I must do all that is possible to ensure quality and
performance of the project and making sure that all workers are working at full
capacity, we can achieve this through a variety of ways, but one key aspect is
incentives and deliverables. By setting realistic and attainable targets with the
addition of incentives it boosts output and morale for workers, other things we will do
to accomplish this:
Objectives (making them realistic and attainable to not strain workers)
Quality deliverables
Effort & cost tracking
Performance (vague but an essential tool to look at)
Project Close -
We must ascertain to keep stakeholders and clients at EBITS happy as I am
contracted to them and the project must serve the purpose, with this in mind
producing a solid project closure. We will hold an immediate reflection meeting
called the “postmortem” to reflect on the failures and successes of the project and
complete all the needed documents:
In depth postmortem
Project punchline
Reporting
Project scope meeting
Initial email to all EBITS
PAGE
2
, lOMoARcPSD|3013804
Conclusion of meetings
As seen by the meetings above the stakeholders and product owners accepted the initial
specification documentations relating to the user requirements, feasibility, cost
management of the project. However, there were some concerns raised about some user
requirements that were not being given enough importance which is a genuine and
rightful remark to make by the client. To address that allegation, we are sorting all the
user requirements into non-functional and functional to split them into smaller and more
manageable tasks.
User Requirements
Functional Requirements: These are the basic features that the system should provide
that the end user specifically requests. As part of the contract, all these functionalities
must be incorporated into the system. These are represented or stated as input to be
given to the system, operation to be performed, and expected output. They are the
user's stated requirements that, unlike non-functional requirements, can be seen
directly in the final product.
Non-functional requirements are the quality constraints that the system must meet to
meet the project contract's requirements. The importance of these factors, as well as the
extent to which they are implemented, varies by project. Non-behavioral
requirements is another name for them.
User Requirements
Table
Functional Non- Functional
Authentication Usability
Audit tracking Legal Requirements
As we are using
External interfaces Reliability the agile
methodology most
Historical Data Performance if not all the
requirements will
Reporting Requirements Subjective and
be in written
form.
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller AcademicAssignments. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $6.99. You're not tied to anything after your purchase.