0% found this document useful (0 votes)
87 views3 pages

Software Project Proposal Guidelines

The document outlines the requirements for a software project proposal assignment. It details 11 topics that must be covered in the proposal, including project components, timelines, specifications, scope, stakeholder input, challenges, comparisons to similar software, approach, prototypes, and evaluations. It also provides guidelines for structuring the proposal and marking criteria for grading.

Uploaded by

Prasanna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
87 views3 pages

Software Project Proposal Guidelines

The document outlines the requirements for a software project proposal assignment. It details 11 topics that must be covered in the proposal, including project components, timelines, specifications, scope, stakeholder input, challenges, comparisons to similar software, approach, prototypes, and evaluations. It also provides guidelines for structuring the proposal and marking criteria for grading.

Uploaded by

Prasanna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Software Project Proposal

Midterm assessment – 30% of your mark for this module

This coursework assignment explores the design and development of your software
project. The deliverable here is a proposal which defines and describes a number of
key elements of your project.

This proposal should be used to explore design decisions, consider the context of use
and identify the process by which the software project is developed. As such, your
proposal should include a reasoned justification that explores the following topics:

1) A clearly defined set of deliverable components of the software and the job of
work required to bring these components to completion.
2) The defined timescale of work, including any dependencies, milestones or
contingencies.
3) A formal specification of the desired system (e.g. UML, technical and
functional specification .)
4) A clearly defined scope for the project.
5) Some evidence of requirements elicitation involving some/all of your project
stakeholders.
6) A research summary that highlights the challenges of working within your
chosen domain
7) Evidence that compares your project to similar software tools (e.g. market
analysis.)
8) A description of your approach that discusses the motivations and reasoning
for working in a particular manner (e.g. Agile, User-Centred Design, Test-
Driven Development.)
9) Some early prototypes showing how the project will work and highlighting the
strengths and weaknesses of your proposition.
10) Some early evidence of assumption testing and validation of your designs to
date (e.g. user tests or automated feedback such as W3C
validation/accessibility testing, heuristic tests etc.)
11) A critical evaluation of your concept, your project in its current state and the
proposed software project.

The document should highlight a clear and systematic rhetoric with critical analysis
and an overall evaluation regarding the current state and feasibility of the approach
presented. A general report structure might look like this.
Aims and Objectives
Set clear goals and concise and appropriate challenges which are measurable. Aims
should be specific, with your objectives building up a bigger picture of what you hope
to do. Goals and operations should be clearly specified. The theme of usability is key.
This section should set out the measuring criteria for your work and your
presentation will be judged in relation to these aims and objectives.

Planning and Requirements Gathering


You should focus on how you hope to plan and gather requirements. We discussed
some different methods in the lectures and discussion group activities. It is
important that you evaluate the different methods in making your decisions and
provide some written analysis in your reports, with clear critique and some
functional understanding for the higher marks. Requirements gathering and
elicitation is a formative process. As such, your methods should reflect this
approach. Higher marks are scored where research forms ideas in a ‘funnel’ based
approach, moving downwards in terms of capturing specific user requirements. Your
planning should evidence any changes in your initial workflow, including allocation
of resources and time and some discussion around the fundamental deliverable
(MVP) of the project.

Formative Testing and Evaluation


This is the part of the project which requires the most research and understanding.
For middle marks, you should provide a good, clear overview of techniques to
identify and sample users, with a set of contextually relevant information and a
balanced overall argument. This should bridge cohesively with your requirements
engineering techniques, as well as your general research in target demographics,
types of systems and processes involved. Higher marks would require rigorous tests
that are insightful and utilise a wide range of metrics to analyse success through
different lenses.

Prototyping Techniques
You should describe your prototype, where strengths in different techniques lie and
where they are used. This section should also detail the movement between low-
fidelity and high-fidelity techniques, with a view to building the system and the
types of technology involved. There should be evidence of iterative design and
evaluation steps.

Evaluation Techniques
This section consists of your heuristics, metrics, scales and other factors to consider
when evaluating success. Where do the critical success factors lie and what novel
techniques could you use to measure your work? How do you intend to measure
success and failure in context? What works well about the system and where are the
fundamental flaws?

Marking will follow these general guidelines (out of 30 possible marks.)


>70% Shows good critique, a functional understanding of all of the
21 or more concepts taught and describes the iterative design process in
marks detail. Students should take an analytical approach and
evidence an advanced array of techniques for higher marks.
Groups should evidence a systematic approach and attempt to
frame their projects against a variety of factors such as
competitors in the market and wider academic and non-
academic considerations. A successful project will include
evidence of technical merit, clearly defined steps for iteration
and improvement and a strong report to account for the design
and development of these things. For higher marks, students
should select projects that are ambitious, novel and utilise
contemporary techniques and technologies.
65-69% Good functional understanding with a clear grasp of the core
19-20 marks concepts. Groups should produce evidence that they have made
clear, logical decisions with sufficient research to support
decisions. At this stage, groups should present a good, reasoned
account of their project with some critical analysis around the
core concepts and techniques. There may be some minor flaws
in either the process or in the technical aspects of this marking
band but students should show extensive knowledge in at least
some of the core learning outcomes of topics studied thus far.
60-64% A reasonable understanding of the core concepts and
18-19 marks competencies required, with a functional implementation of user
centred design and software development techniques that are fit
for purpose. Groups should be able to distinguish between good
and bad design decisions and make use of some of the
techniques studied in the module. There should be some
formative research and commentary to dictate rhetoric and
design decisions.
50-59% Groups should show some understanding of fundamental
15-17 marks concepts of system and software development lifecycles, with a
consistent and clear approach to their work. They should be able
to present their ideas in a meaningful way and have a grasp of
the software development lifecycle and an approach to building
and evaluating software in an iterative, collaborative way.
40-49% Groups should show some grasp of core concepts of the module,
12-14 marks but not enough to critically assess their own design decisions
and/or flaws in their premises.
<40% Unacceptable standard of work, presenting little or no relevant
less than 12 information and only showing evidence of understanding in
marks some key areas of software engineering.

You might also like