Incell Phonium Processor
Project Plan Document
Dale Mansholt
Aaron Drake
Jon Scruggs
Travis Svehla
A Brief Overview…
• Our clients:– The ECE team:
• Cris Wade• Adam Sloan• Phil Ness
• Their Goal: Design the “Janus” Digital Signal Processor (DSP)
The Concept…
Our Client’s Problem:
• No programs for their processor!
• No tools to create programs!
• The chip only exists on paper!
Our Solution:
• Create an assembler to convert code into programs
• Create an emulator to test out those programs
• Combine these components into an integrated environment with a GUI (Graphical User Interface)
What We’re Assuming…
• We can learn how to use QT
• We can develop our program Platform Independently
• The specifications of the “Janus” Processor don’t change significantly over time
Our Restrictions…
• Limited time– Must be complete by May 2003!
• Limited manpower– Just the four of us developing the software
• Development tools– Must be easily Cross-Platform capable
• May not know all details until later on – Specifications for “Janus” are not finalized!
• No experienced members!
Our Lifecycle: Design-to-Schedule
Why Design-to-Schedule?
• We have an immovable deadline – the end of semester!
• Prioritizes features by necessity – If the project isn’t done at the end of the semester,
only low-priority features are not implemented
• The downside: Possible design-time wasted– But this is acceptable! This is potentially a multi-
semester project, so future Senior Projects may use our unfinished designs
Our Timeline, In Depth (for this semester)
Our Timeline, In Depth(for next semester)
Risks We Face:
• Have to learn new technologies (QT, Linux, etc.) – Lack of technical expertise
• We have numerous Computer Science experts available
• May run out of time before project is completed• Using a lifecycle model to compensate
• Personnel problems – conflicts, people leaving• Use procedures conflict resolution document
• Clients may cancel project• Cannot be avoided
More Risks…
• Equipment failure• Frequently backup project materials
• Possible bugs in development tools• Ensure newest patches are applied, try different
code
Our Organization Plan
• Dale Mansholt, Project Leader, is ultimately responsible for the whole project
Our Organization Plan (Continued)
• Jonathan Scruggs, Lead Analyst, is responsible for understanding the customers’ needs.
Our Organization Plan (Continued)
• Dale Mansholt, Lead Designer, is responsible for defining a solution that meets the customers’ needs.
Our Organization Plan (Continued)
• Aaron Drake, Lead Documenter, is ultimately responsible for formatting and finalizing all documents.
Our Organization Plan (Continued)
• Travis Svehla, Lead Programmer, is responsible for all major programming decisions made.
Our Organization Plan (Continued)
• Jonathan Scruggs, Lead Tester, is responsible for deciding what kinds of testing will be performed and supervising the tests.
How Decisions Are Made…
• All non-trivial decisions will be discussed
• The leader of the domain in which a decision must be made will state his position, and if any other members disagree, a vote will be taken
• When a vote is taken, the leader of that domain will have two votes
Design Decisions We Have Made:
• Currently in the early stages of the design process; still discussing design issues
• We will use QT and C++ 7.0
• Divided system design into three components: assembler, emulator, integrated environment
Necessary Materials for Project:
• Possible purchase of QT
• Visual Studio 7.0 (C++)
• Access to Unix/Linux
• Microsoft Windows Environment
Necessary Activities for Project:
• Learn full details of Visual Studio 7 usage
• Obtain development tools
• Learn how to use QT to create a GUI
• Become familiar with Linux
Documentation Plan
• Lead Documenter will handle all documents.
• Responsibilities:– All documents have same format.– Grammatical checking– Final review– Approval– The documents get distributed (web, printed..)
Test Plan
Levels of testing from lowest to highest:
• Module Testing
• Integration Testing
• System Testing
• Acceptance Testing
• Site Testing
Module Testing
• Ensure module does what it should
• Check if the functions work
• Platform independent
• Create test interface with added features
Integration Testing
• Check to see if functions are called right
• Platform independent
• Create a test interface
System Testing
• Make sure functions work together correctly
• Test the user interface
• User interface does not need to be platform independent
• User interface can be used to test the whole system
Acceptance Testing
• This test will be done after completion of each of the three previous tests– The specs may change– Find flaws in clients’ ideas
• Easier to change the programs at the Module Testing level.
• Clients can easily see if the system is performing as expected
Site Testing
• We need to make sure the emulator and assembler run on:– Unix/Linux/Solaris/BSD– Microsoft Windows
• These tests do not need to be performed on the ECE Departmental computers
Installation Plan
• We will not install any of the software on the clients computers
• Compiled binaries and source code will be available on our project forum
• Full documentation of the software will be provided.
• Installation is easy: just make sure all the files are in the same directory.
Project Status…
• Have met with clients to perform problem analysis and requirements elicitation
• Have completed R.A.D. and Project Plan
• Currently in early stages of design process
Questions?