Project notes
Find need for new development + define problem
Feasibility study – can It be done / is it desirable for developers? (technical, financial, legal)
Team creates feasibility report
Prototyping includes:
Code snip (inc comments)
Explain snip
Outputs + errors
Corrections and output
Next step
Analysis
•• Identified suitable stakeholders for the project
and described them explaining how they will
make use of the proposed solution and why it is
appropriate to their needs.
Stakeholders (no full name for privacy reasons) – have diverse stakeholders, how will the project help them
Fact finding [use 3+ stakeholders]
Observation (games)
o Photos + images
o (no hair/faces of people only hands)
o What user liked + disliked
o What to include / not
Questionnaire (games)
o (10+ questions)
o Analysis and chart
Document collecting (simulation)
o Relevant pages of books / information
o Mathematical calculations
Interview [mandatory]
o Large info amount
o Interview responses can be clarified
o Stakeholders may be busy
o People may not interview well
ANALYSE + CONCLUDE ALL FACT FINDING
•• Researched the problem in depth looking at
existing solutions to similar problems, identifying
and justifying suitable approaches based on this
research.
Look at existing similar systems[2-3] w pictures (not huge size)
pros and cons,
what will you include / leave out
•• Identified the essential features of the proposed computational solution explaining these choices.
Must could should wont
•• Identified and explained with justification any
limitations of the proposed solution.
Prototype and feasibility complex bits
•• Specified and justified the requirements for the
solution including (as appropriate) any hardware
and software requirements.
•• Identified and justified measurable success
criteria for the proposed solution.
Proposed ft -> divide into, ui, functional ,stakeholder funct, ux, req ect….
Platforms you considered -> pg python pygame why
Other platforms you could have used -> why not
Muscow table table of features must could should wont justification + criteria
Ux requirements -> +3 iterations screen drawing / design
Limitations (project not language) -> v specific 3x pg each type of limitation
Limiting things on screen to prevent lag / different platforms due to time
Design
!!!!!!!!group ft together functional usability non functional
Factors that need including:
Input / ux design (must show software: ppt, canva, gliphy, paint)
o Interface design shows how info is input into system + how it is displayed
o Stakeholder evaluation
Output / ux design
o Users may be external entity or internal (bound with comp + manual sys)
o Triggered by user interaction
o Stakeholder evaluation
Data structure design
o What data needs storing
o Database:
ERD
Flat structure
Data Dictionary
Normalisation (up to 3 NF)
o Flat file
Show file data structures
o Key data structures: eg stack queue exc
System flowcharts
o Top level data flow shown
o Relatively simple
Broken the problem down systematically
into a series of smaller problems suitable for
computational solutions, explaining and justifying
the process.
•• Defined in detail the structure of the solution to
be developed.
•• Described the solution fully using appropriate
and accurate algorithms justifying how these
algorithms form a complete solution to the
problem.
•• Described, justifying choices made, the usability
features to be included in the solution.
Describe -> justify -> evaluate
Include embedded stakeholder feedback
3 iterations improving based on feedback each time
•• Identified and justified the key variables / data
structures / classes (as appropriate to the
proposed solution) justifying and explaining any
necessary validation.
•• Identified and justified the test data to be used
during the iterative development of the solution.
•• Identified and justified any further data to be
used in the post development phase.
Development & Testing
Where does testing occur:
End of design
o Paragraph on each type of testing used and how
Entire development and testing
o (incremental / white box in middle of each phase [show incremental errors + rectification with full justification + ss and
status of tests RAG]
o iterative/final/black box testing after full development Alpha testing [with some features that still don’t work]
o post alpha testing and improvements (post development evidence)
Beta testing
o Test for functionality, robustness, usability
o Still some improvements identified
o Post beta testing and improvement
Evaluation
o Ss all features with working / partial / full justification
must have at least 2 iterations
part 1 (Provided evidence of each stage of the iterative
development process for a coded solution) Must have >2 iterations (iteration – 5+ phases each phase has: description,
design, test strategy, code, output + errors + rectifications. everything justified explained and described, test plan for
phase [relating to test strategy])
ss must be large + readable with no pixilation, outputs must show title bar, test screenshots don’t have to be massive.
Later stages should have stakeholder feedback when justifying
After iteration 1 ,must show iteration review with stakeholder feedback with possible new features ect
Repeat all steps for iteration 2
part 2 (relating this to the break down of the problem
from the analysis stage and explaining what they
did and justifying why.) How do they meet requirements in analysis phase (relate to stakeholders ect)
•• Provided evidence of prototype versions of their solution for each stage of the process.
o Need prototype for each iteration
•• The solution will be well structured and modular in nature.
o Sub routines + OOP
•• Code will be annotated to aid future
maintenance of the system. (explained in year 13)
o Thoroughly comment code
•• All variables and structures will be appropriately named.
•• There will be evidence of validation for all key
elements of the solution.
o If and while statements
•• The development will show review at all key
stages in the process
o MUST show RAGed MuSCoW table
Provided evidence of testing at each stage of the
iterative development process.
•• Provided evidence of any failed tests and the
remedial actions taken with full justification for
any actions taken.
Test strategy table (what is being tested, description + type, data, rationale, expected result ) [before code] + test tables (what testing, data,
result, pass/fail) [after code], error and correction
Incremental throughout development
Incremental -> Alpha (whole code) -> beta
Evaluation & Final Testing
1. Beta test: After ALL alpha testing and changes done(some changes MUST be shown) - then show that whole system has been tested again-
all modules link to each other correctly as expected. 2. User testing; Get user to test the system(show photographic evidence where possible) -
then get user comments- likes and improvements (it is ok for user to suggest some limitations)
Provided annotated evidence of post
development testing for function and robustness.
•• Provided annotated evidence for usability testing.
Don’t forget robustness testing
Stakeholders clearly comment (w ss) on each test: function, robustness, usability
Your own comment + evaluation of stakeholder comments
MUST INCLUDE SCREEN SHOTS FOR ALL EVIDENCE
EVAL MUST START WITH A FULLY RAGGED RQUIREMENTS SPEC TABLE
Used the test evidence to cross reference with
the success criteria to evaluate the solution
explain how the evidence shows that the criteria
has been fully, partially or not met in each case.
Use ss to show they have / haven’t met requirements
!!!!!!!MUST HAVE SOME ELEMENTS PARTIALLY OR NOT MET!!!!!
Then describe how you can meet it in technical terms
Functional features
•• Provided comments on how any partially or
unmet criteria could be addressed in further
development.
•• Provided evidence of the usability features
justifying their success, partial success or failure
as effective usability features.
Show usability ft
•• Provided comments on how any issues with
partially or unmet usability features could be
addressed in further development.
•• Considered maintenance issues and limitations of
the solution.
What has been done to support future / contingency plans
Eg object oriented + modular
•• Described how the program could be
developed to deal with limitations of potential
improvements / changes.
•• There is a well developed line of reasoning which
is clear and logically structured. The information
presented is relevant and substantiated.