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 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?