Wiki up and running

Not to many blog posts right now. Most of my time has been spent on the team Wiki rather than here.

We had our first team meeting last Saturday with Katherine conferenced in via cell phone. We were going to use google video, but the sound would not work. We used it for video, but the sound would not work so we used a cell phone for the audio. It worked somewhat but it was not ideal. We need to work on a better way to do this. As the professor said today, failure is not an option.

I was bale to share my original thouhts on how the system would go together based on my proposal. We talked about changes to the proposal, but the only real change that was accepted was the idea of moving the trending from the HW to the WP part of the project.

We got a fair distance on defining the HAP level 1 protocol. Unfortunately we are still refining it as we had to break up the meeting after several hours. The wiki has a good start on the HAP1 definition.

Class notes from 2-25-11

Today in class we talked about setting up software revision control. Apparently SVN has been used on previous projects in other classes so it has a large appeal to the rest of the students. I'll have to get caught up on this part as I have never used this software before. I've used other revision control products, just not this one.

We also talked about how to run a meeting, specifically Roberts Rules of Order. Although this works, it will probably be a bit formal for most of our meetings. I expect that we can water it down a bit and get a working set of rules for our meetings. This will need to be worked out when we meet on Saturday.

An agenda has been set for our first meeting, thanks to Ekaterina. She was also helpful in pulling together team members contact info and availability as well as establishing the SVN account on the CS servers. Thanks for the team support!

In class we were also told to establish a wiki for our class, Katherine has agreed to take this on because she has had experience doing this.

All in all it seems the team is already starting to work together!

One last requirement is that we prepare, as a team, a 10 minute pitch for out project that will need to be presented to the "venture capital hat" starting next week. We'll need to refine the proposal in preparation for this presentation to incorporate input from team members. 

Proposal Accepted

My proposal was accepted as one of the five that will be further developed in this class. I'm thankful to Katherine for sticking up for my proposal while I was away on business travel. Teams were formed on Wednesday and we have two members from Abq, John Donahue and April Suknot joining the rest of the Los Alamos group on the project. The telecommuting part of this should add some challenges, but I welcome the opportunity to learn some new tricks on how best to do this.

We have established working schedules and shared some of our skill sets with each other via e-mail over the past few days. The plan is to meet face to face on campus on Saturday and start looking at the proposal more critically.

Addendum to Proposal

I have posted an addendum to my proposal at Addendum Link. It is pretty much the same as my blog post from earlier today, but is available in pdf and has a few tweaks.

My Votes for the Class Project

We were asked to post our votes for our preferred class project. I'm quite excited about the opportunities my project presents to both myself, but also my fellow classmates.

With that I place all 5 of my votes for my proposal "AH". Sorry no more chivalry, no more obtaining from voting! 

I will be on travel for business on Wednesday, so hopefully there will be other classmates who can stand up for my proposal.

Proposal Selection Continued

Today in class we worked on the proposal selection. I was please to see my proposal in the top 10 and with the addition of my vote and a few other classmates stepping up it made in into the top 5 where it remained for the next few iterations of selection.

I really see this project as having a lot of learning potential. So much of the software developed today is in embedded applications (I meet a guy once at a show who was developing software for a toothbrush! No really!). Any CS student with this ability would be well suited to enter the marketplace with a unique and high demand skill.

In addition to this, the project spans three separate and distinct hardware platforms, each with its own set of programming skills needed. This allows a unique need for multiple programming skills that must all come together to form a complete system. Real world projects almost always end up this way.

One other added benefit to this project is that it does involve some hardware development. Not all software runs on a PC, and the idea of having to work in a different environment brings new challenges. Having a hardware designer on the development team also gives a unique experience to the project. I think it is an excellent opportunity for leaning that many of the other proposals would not include.

The concept mentioned by the professor in class of using a Arduino for the hardware development platform at first did not seem very practical. I had never worked with this product before, but have seen many similar products that "dumbed down" the hardware interfaces. I reviewed the Arduino site and it seems that it remains close enough to the hardware roots to be practical for development, at least from the aspects of this class project. I really believe a real world implementation of this project would require custom hardware to implement. Embedding an Arduino in a production run thermostat is not practical or cost effective.

If the professor allows my original proposal to go through unchanged I think I can work with the other classmates to make sure the implementation on "real world" hardware would not be taxing to the project. The proposal includes two complete hardware platforms each could be used for software development. I would assemble each, outside of my software development duties, so they do not impact the overall software development process, which is the main point of the class. The required hardware parts are in hand and the hardware design is complete, at least on paper. Once accepted it will only take a day or two to go to working hardware.

The software development can be done on MPLAB which is a free software development and debugging platform available from MicroChip (MPLAB link). The chip I have selected (PIC16F877 Datasheet Link) has a built in debugging interface that allows programming in-situ and allows full access to all memory and register locations as well as such features as single stepping the CPU or run to breakpoints.

All that being said there are a few obstacles to using the custom hardware platform:

1. To connect the chip to the computers USB an ICD3 (ICD3 Link) interface is needed. This is easy to obtain but cost $200 each (not bad compared to many of the other options in this market). I currently only have one, so another would need to be located. If this really became a show stopper, I'd find a way to fund this.
2. MPLAB is programmed in Assembly. On a PIC16F chip there are only about 32 different opcodes, so its not too hard to pick up, but there is no question Assembly is not for the weak hearted. MPLAB does have plug-ins for C and Basic, but these cost at least $100 and up, The use of these higher level languages can also lead to other issues when doing true embedded programming where having full control of the CPU at all times is needed for critical timing issues. 
3. Bringing a fellow student up to speed on this new environment could be a challenge.  I have been writing code in this environment for years, I would take it upon myself to tutor any other student that is up to the challenge and wants to learn this new skill. I really see this as part of what I want to learn from this class. In the past I have worked most of my software development in a bubble, with me being the only programmer. I really need to learn how to work with other programmers, particularly with those of different skill levels. If along the way I can pass some of my skills to a fellow programmer, then great! I hope there is at least one other student who has the desire to learn this new skill in the class.

A little background (history): The first assembly code I wrote was a monitor ROM program for an 8080 (Link to 8080 info) processor (Note, that is 8080, not 8086, or 80286, or 80386, or...) I had a memory limitation of 256 bytes (Note that is bytes, not KB, or MB, or...). I had to hand assemble the entire code on paper because I did not have a computer at the time. I think I had two bytes of memory left when I was done. It ran the first time, wow was I surprised! I still have that project in a box in the attic somewhere. If there is a student that would like to see a piece of history let me know. I'd be glad to pull it out and share a piece of history (it is sad when your old enough to use the work history to describe something you built).

Selection Process for Proposals

I believe the best way to select these proposals is as follows:

1. Take the top 10 proposals from the class scoring
2. Allow some class discussion about the pros and cons of each allowing proposal owners time to rebuttle
3. Go through each proposal and take vote asking "if this proposal was selected would you want to be a team member". Keep track of the number of votes for each proposal.
4. Use the top five proposals as the final selection.

I think this is a fair way to determine the selection and it ensures the best chance that there will be team members who would want to be on the project teams.

Class Notes from 2-16-11

We got through a little over half of the 2 min class presentations today. We'll complete the remainder on Friday. Everyone is given just 2 minutes for their presentation. It's tough getting everything in you would like to say in that time frame. I put together a few power point slides to add to my presentation. I figured that if a picture is worth a thousand words, then the slides gave me the equivalent of about 10 to 15 minutes more speaking time. So far I have not seen anything that makes me change my mind about the placing of the proposals. I only got time for one question about how I would implement the hardware platform for the t-stat. I've not addressed this issue much to this date as I realize this is not a electrical engineering class. I plan on keeping the hardware practical, useful but minimal in nature.I'd also not expect any of the other student to be heavily involved in that part of the project unless they want to. I thought I'd lay out the requirements for the hardware here so that it could be used for input into the software requirements later:

The t-stat will be based o a Microchip PIC16F877a chip which has on board the following:

1. Multi-channel, 10 bit analog to digital converter
2. A USART for serial communications
3. 8K of Program memory
4. 382 Bytes of RAM
5. 256 Bytes of EEPROM
6. Multiple on board timers with interrupt capability
7. Up to 33 general purpose IO lines

The chip has several other on board features, but the ones listed above are the ones need for this project.One other key feature is that it has internal hardware support for the Microchip ICD (in circuit debugger) interface which makes troubleshooting and programming easy. I all ready have the ICD3 interface modual and the programming software to support this function.

Other requirements of the t-stat are

1. LED 7 segement, 4 digit LED display for time and temperature
2. Pushbuttons for user input
3. Other LEDs to indicate mode
4. Two temperature inputs (will be simulated by pots for now)
5. An RS-485 com port
6. A relay output for heat control
7. A 5V power supply to power the unit
8. Crystal oscillator for precision timing for RTC (Real time clock)
9. An ICD connection port for debugging/programming
10. A dip switch to set the units network address (4 place for 16 possible addresses)

Tonight I also spent some time laying out the t-stats hardware interface and some of the hardware. I'm not going to touch the software until the project gets the green light and the other classmates get involved. I'm trying to get some of the hardware design out of the way so that we can hit the software part without delay when and if we go forward with this project. If the project doesn't go, well, I enjoyed the hardware design effort anyway.

Final Proposal Review

I used the scoring system outlined in my previous blog posting and evaluated all of the proposals. The order from best to worst least desirable and the respective scores are listed below. For ties in scores the proposals are just listed in the order that they were posted (no attempt to tie break). I left my score out of the listing as I had suggested in my previous post (but I did score myself high on the list, self-reflection can be good for the soul)

AR - 23
BFR  - 22
JD - 22
DH - 22
JD1 - 21
E - 20
ALH - 20
RH - 20
KN - 19
NS - 17
SM - 17
GIA - 17
JD2 - 17
VS - 17
IG - 17
LAG - 16
EA - 16
ANS - 16
ED - 16
CJA - 15
TDG - 14
DWS - 13
MM - 12
WC - 11
AS - 11
K - 8

After I ranked all the proposals I want back to see which once came out on top. I was surprised with the results, but I think they are valid.

A Quick Proposal Review - Setting the Ranking Standards

I took the time this evening to scan through the other students proposals. I wasn't looking for detail this time through, I mostly wanted to get a general sense of what was being proposed. Once I got through the herd of zombies I found some real original ideas. Something I had not counted on was that as I was reading the proposals, the idea of who I would want on my team, and who I wouldn't want, was paramount in my mind.

I think I am going to base my rating on the following scores:

1. Is this project possible - Is it well defined enough, will it fit in the time line, do I believe the writer of the proposal knows enough to actually lead a team through this project.
2. Presentation - A good presentation score could be considered "judging a book by its cover", but in this case I think it reflects on the writers ability to be a potential leader. A poor proposal could mean a poor final product. Not something I want to be involved in.
3. Is it needed - Is there a good justification for this product even existing?
4. Completeness - Did the writer actually follow the requested general format or did they just "wing it". Is there a time line and a budget that made sense.
5. Excitement - Did I get excited about this project, would it be a fun project or just a coding exercise. Might as well enjoy the ride!

I'll grade each proposal on a scale of 1 to 5 on each topic and let the scores fall where they may. Hopefully this will result in a fair ranking of the proposals.

I really think that every student should abstain from ranking their own proposal, at least from the standpoint of establishing the rank in the class. We should all give ourselves a score as to how we compared to other students as part of the leaning process; self-reflection is always a learning experience.

PS: Sorry about the zombie comment at the beginning of this blog entry. The older I get , I guess the less influence pop culture has on me (something about old dogs and new zombie bones).

Preliminary Requirements Document

Due to the fact that my proposal describes a total system made up of three distinct software modules that all have to integrate together, there are some unique requirements for each sub piece.The three parts to the project are the embedded thermostat (t-stat), the web portal and the smart phone application.

General System Requirements:
Functional:

• User Interface
  -Out of the box interface (Default smart phone displays)
  -DIY interface (Smart phone expansion capability)
  -Hardware Platform interface (t-stat display and buttons)
• Internal Security
  -Web portal protection of server
  -User log on
• Reliability
  -High Reliability handshake mode
  -Embedded Watchdog
• Hardware Platform, Programming Languages
  -Microchip MPU Selection
  -Web portal PC with Static IP
  -Assembly (T-stat)
  -Java (Web portal)
  -Java for Android (Smart Phone)
• Communication Protocol
  -Custom t-stat to web portal
  -HTTP with embedded data transfer protocol.

Non-Functional

• Future Expandability
  - Prototype to final product considerations
• Coding Standards
• Bounding Conditions for Prototype
  -Limiting factors used in project for prototype development
• Documentation
  -Protocols used
  -DIY interface details
  -Hardware schematics
  -Web portal details needed to convert to future embedded web portal

Final Proposal Posting

My final proposal is available at the following web site: Final Proposal Posting Site. All comments by the reviewers have been incorporated.

Class notes from 2-8-11

On Monday we talked about development of software requirements. We broke the start of this process down into a tree that looked like this:
A. Functional
     1. User Interface
     2. Time
     3. Concurancy
     4. Hardware/Platform
B. Non-functional
     1. Documentation
     2. Trademark/Legal
     3. Aesthetics
     4. Coding Standards
C. Testing
D. Security

My understanding was we are to add to this list or to expand on one or more issues listed. Being primarily an embedded programmer I'll give my take on a few of the issues listed:

   Functional - Time: In reviewing information on the Android programming web site I watched a video on the do's and don'ts of android programming. One of the items that stood out to me was the need to have a "snappy" user interface. One of the things that drives me crazy with some of the new applications is the hesitancy in response to an operator action. Even if I can't expect an complete response immediately, at lest let me know something is happening. In the early days of web browsing the slow download speeds meant it took 10s of seconds for an image to download. The images came in as a blur that refined itself as data came in. Although annoying, at least you knew there was something going on (and that it was not time to reboot your Win 3.1 system again!). The video indicated that about 2 seconds was that maximum wait time, but in reality if something did not happen in about 200mS the operator would feel like the system was dragging.
   Timing can become not only a user response issue but a critical issue in embedded controls for many other reasons. In the case of a communicating device the maximum and minimum response time can make or break an interface. Respond too quickly and the receiver may not be ready to listen. Respond to slow and the receiver may think that the responder is offline and retry or go on to the next transmission. This can be one of the most tricky things to test and validate. I have often resorted to an old fashion O-scope to diagnose this type of problem.

   Functional - Hardware/Platform: Again in the embedded world this is a major issue. Even your "standard" programming languages like C undergo strange mutations in order to adapt to the special "features" of a given MPU. Finding a balance between a low cost chip and a chip with enough memory for the program can be an "Extreme Programming" problem ;). Pick too low, run into a memory overflow, and you may find that the entire project has to be slid into a whole new product line with a completely different hardware configuration. Things in the embedded world are getting bit better in the area, but still not a smooth transition. Maybe I should take the same attitude as Microsoft...memory is free, use as much as you want! Unfortunately the chip manufactures still think memory has a real cost associated with it.

   I put a bit more in my blog posting on "Extreme Programming?" about tying requirements to testing so I won't go into that here. 

   I did not see a location to post our proposals on the main class blog yet. I'll just hold onto my final proposal until I see more info

Extreme Programming?

I took some time tonight to read through the Extreme Programming links from the class blog. It had some interesting ideas, but quite frankly sounded like standard engineering practices wrapped in some computer jargon. Maybe I missed the point or maybe I'm getting to old to be taught new tricks. That being said, I did glean a few ideas from the process; spike programs and the idea of writing test code before the real code. I guess I have used the idea of spike programs since my early days in programming, but never really gave them much thought, and certainly never a name. I remember writing my first for-loop as a stand alone program just so I could see how it worked before I integrated into my program. For our class proposal I did a simple spike program on my computer to assure myself that a custom web application was possible and not out of the scope of the class. The idea of writing a unit test program first is novel. I'm not sure I buy it yet, but it might be interesting to try sometime.I do agree with the concept that the general requirements for test programs should be an up front development process. When you define a requirement, I think it is a real good idea to at least rough out the test plan that will validate the requirement. If no test plan can be developed with a go/no go result, then the requirement was probably not a real requirement (or at least it might belong in the non-functional category). I did like the idea of making the test process an automated function. Most of my life I have manually tested my software through a test harness, sometime repeating the same manual test hundreds of times before completing a section of programming. An automated test program might have save me hundreds of hours of tedious work. I could see some application for this in my proposed class project by providing a simulation and test results of each of the project sections without the need to integrate for each test. If my project is selected I will talk to the team about this option.  

Class Canceled - but life goes on!

Classes were canceled this Wednesday and Friday due to the gas shortage in the state of New Mexico. Unfortunately real life continued with my real job dragging me all around the Los Alamos Labs trying to keep buildings from freezing and server rooms from roasting. Sorry fellow student for the delay in getting your reviews out. What pays the bills takes the priority.

Review of Ekaterina Davydenko’s Proposal

Allen Hayward’s Review of Ekaterina Davydenko’s Proposal for CS-460

Summary: The proposal is to develop an automated dynamic traffic control system that would provide improvement in traffic flow under varying conditions. The system would include interfaces for future development of emergency vehicle override capability and historical data collection interfaces used for tuning of the system. The system would use road sensors and remotely automated displays to tune road speeds and redirection of drivers to maximize throughput of existing road systems.

Scores based on a 1 to 5 rating with a 5 being the best

Syntax = 4: Technical information is well presented. Some sentences lack smooth reading flow. Has a nice content, figures list and general format.

1.      Page Numbering – The use of roman numerals for the cover pages should not flow into the Arabic numbering used on the body of the proposal. Restart the Arabic numbering at page 1 where you have page 4 now.

2.      General – Proposal guidelines from professor specified 12pt text and double spacing.

3.      Page 5 – First paragraph, second sentence – “number” should be “numbers”

4.      Page 5 – Third paragraph – After traffic add the word “conditions”, After commutes add “have become”. Change “conjunction” to “junction”. Delete “certain” from last sentence

5.      Page 6 – Change the word “harmonization” to “harmonized” is several locations. Last paragraph, change “initiative” to “innovation”. Change “fully” to “full, ”.

6.      Page 9 – First paragraph, change “The system that we design will…” to The system design will…”

7.      Page 11 – the second paragraph indicates three weeks for implementation but the gnat chart seems to show 4 weeks.

Disclaimer – Being an engineer my proof reading skills are not the best. Consider having someone with real writing skills look at this proposal for grammar, spelling and punctuation.

Plausibility = 3: I believe with the right team and some work on better definition of scope this is a very viable project. The biggest problem is not having the full scope defined. This will impact the size of the project greatly. See Scope below for more details

Support = 4: The proposal was adequately supported by citing other examples of similar systems already implemented or in the process of implementation. The system does not push the limits of current technologies too far and thus is relatively safe. The challenge is more an issue of scope. The writer provided adequate programming experience background information to make it clear she is qualified for the job.

Novelty = 2: Based on the fact that other systems are already in place this is not a very novel project. If more details on how AI might be implemented to solve the problem this might make the system more unique.  Traffic light coordination is commonplace in big cities already. Tacoma, WA had traffic light coordination implemented back in the 80s.

Stakeholders = 3: It seems a system of this type would have many regulations from the DOT thus probably gaining it’s funding from the DOT. I could easily see this being a government-funded project. This project has a definite interface with the public, as such the public is a big part of the stakeholder group and will want to be part of the design of this type of project. No mention of public feedback was included.

Scope = 2 : Being such a large project it is necessary to ensure that the scope is clearly defined. Certainly the entire implementation of such a system is far from the scope of this class. Consider redefining the project as a small-scale prototype based on a specific implementation (i.e. a set of 10 traffic lights or a 10 mile stretch of highway with a fixed number of on/off ramps or maybe a selected actual part of an existing cities roadway (Trinity Drive?)). Clearly define the number and type of feedback/output devices. Also indicate what will be used to test the system. Are you really going to setup a functional system or simply provide simulated data to the system to prove it works? What will be the proof that your system does what it says it will (10% improvement in traffic flow)?

Profit = 5: If such a system was constructed and proved to be viable I could see a significant profit for such a system. I could see ongoing improvements and maintenance of systems of this type turning into a potential new market place with significant growth possibility.

Legality = 1: Although not to be a big issue in this class, the reality is this system has the potential for significant legal issues. Automated signs going dark or miss informing drivers could result in traffic accidents and possible fatalities. This should at least be mentioned in the challenges section of the report. All systems fail eventually, what is the risk and how will the risk be mitigated?  You can push a lot of this out of this project by indicating that it is a prototype and will not be used in actual traffic control at this time. (low score due to not mentioning it, easy to fix)

Security = 1: Another big issue for this system is how secure is it. Hacking a system of this type could result in brining traffic to a halt in a big city with major impact to the city’s reputation and its ability to conduct commerce. Being known as the “most hacked city” is not a good thing. At least mention the need for security to assure your customer that you understand the potential issues that must be addressed. (low score due to not mentioning it, easy to fix)

Expense Budget:

A budget number is provided but it does not have a breakdown of how it was developed. As an investor I’d like to see how a large number of $120K was developed. That would give me some assurance that this was a real number and not just a wild guess.

Time Line: Correct format and reasonable but could use some more detail.

Other considerations: You did not mention that fact that by improving traffic flow the need for road upgrades could be deferred or eliminated by making the existing infrastructure capable of carrying traffic more effectively. Also have you considered the need to tie the system into the road construction department? A busted water main (i.e. main hill road last week) needs to be inputted into the system quickly so it can reroute traffic. Also, planned road construction should be easy to input in to the system so that it can compensate for it.

Review of Katherine Nystrom's Proposal

Allen Hayward’s Review of Katherine Nystrom’s Proposal for CS-460

Summary: The proposal is to develop a recipe organization program with unique features directed at the food blogger community.  The program will either work as a home computer based system or a web-based service. Based on Katherine’s experience I believe she would be capable of directing a team for this project. Her insight into the food blogger world would be of utmost importance to ensuring the success of the project.

Scores based on a 1 to 5 rating with a 5 being the best

Syntax = 5: Well written with very few typos or recommended enhancements.

1.      Page 1 – change the word would to will in the first sentence. Make the reader feel like this is something that will happen. A proposal is a sales pitch – “I can see you driving home in this fine car today…”

2.      Page 1 – add comma after the word however in the second paragraph or consider rewriting this sentence. I had to read it a few times to get the meaning.

3.      Page 2 – Change dash between $80 and free to the word “to”. It makes the sentence more readable.

4.      Appendix 1 – No reference in main body of text or header describing what the appendix is for. Add a title and make a reference from the main body of text.

Disclaimer – Being an engineer my proof reading skills are not the best. Consider having someone with real writing skills look at this proposal for grammar, spelling and punctuation.

Plausibility = 4: I believe with the right team this is a very viable project. It might need to be paired down to either the home-based computer version OR the web based implementation to fit within the time line. My lack of web-based design may be showing in my recommendations.

Support = 4: Supporting details were provided in terms of why this is a viable product in the body of the text as well as indications of detailed background investigation were provided in appendix. The writer’s qualifications are spelled out as part of the proposal.

Novelty = 2: I’m not sure that I could completely identify what made this project novel. I recognize that it is intended to be directed towards the food blogger community, but I had a hard time identifying the difference in needs between the “home cook” and the “food blogger”. This may be because of my lack of knowledge in this field (even though I do watch the food channel almost every night). The proposal should provide the details the reader needs to fully understand what makes it novel with the assumption that I am neither a “home cook” nor a “food blogger”. 

Stakeholders = 4: Stake holders in terms of end users is well defined, Stake holders in terms of business arrangements could use some additions. How will this be funded – the venture capitalist should identified as the funding source (at least in this class room scenario). When I finished reading the proposal I didn’t feel like I had been asked to contribute to the project as an investor. Would this software be the basis of a new company or a one shot development and placed on a vending web site? Maybe just a bit more roll playing is needed.

Scope = 2 : After reading the proposal twice through I still not feel like I had a good picture of the scope. I recognize that the proposal indicates that the team would have a lot of input into how this application would be “fleshed out”. In my past experience the proposal either becomes the contract or is a major input into the contract. If it is not very clear, both sides have a bad time identifying when the agreement has been fulfilled. You stated many things that the current products do; will these be part of your project? Identify exactly what new features will be added or at least provided some concrete examples of where you will be guiding the team in trying to make the product “food blogger friendly”.

Profit = 3: I believe the statement that there is a large market for this improved product does exists. The fact that cable television has an ever-growing number of shows dealing with cooking is a good sign of this growing niche market. You provided a list of current product and prices, but never stated what you though the target price might be for this product. As an investor this is a detail that I would be interested in. I think this is targeted towards a mid to upper cost bracket, but you never stated this.

Legality = 5: Probably not a big issue for this project. Only issue might be security of personal recipes. Maybe a small mention of providing a protection for this might be in order, but not a big deal (unless KFC decides to use it to store their secret recipe of 11 herbs and spices in your program).

Security = 5: See legality above

Expense Budget:

I’d recommend that the software developers’ budget indicate the anticipated number of hours and at what rate. Also several of the line items are $0, which is probably unrealistic. Taxes will always be a cost but you can defer that part of the cost to the customer (i.e. investor) by stating that it is as an additional cost not included in the budget. Office supplies, like paper, blank CDs for backups, pencils (which your employees will take home in their pockets), ect is a real expense.  Web server space is also a real expense that should be accounted for.

Time Line: Well laid out. Getting it into a more readable format would be helpful.