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?