Monday February 28th, 2011

Lecture Notes:

• Well done job is the one that not even noticed (usually w/o complaining about its quality).
• #1: Recognize the chain of commands! Google. manual, classmates, instructor is the last one.
• #2: Rational: Define, defend, attack.
• OOP is to make large problem small enough.
• Ease of reading the language, high readability of the code without documentation.
• Schedule meeting with prof. Kniss this week for group presentation.
• Next week - midterm (self-eval),last class before Spring break; Can you be objective with yourself? What are capabilities and weakness? Where time focus should be? Importance of extracting the details and important key points from EVERY class lecture. Summary of activities, timeline.
• 9 weeks left (-1 finals week - should never counted as a development week!)
• SO ONLY 8 WEEKS LEFT for project development

Team Wiki had been started

Since all of the primary communication will be done on the team's Wiki, this blog will contain mainly my personal class notes.

Friday, February 25th, 2011

Lecture Notes:

• WC missed class and looking for the group
• Number of code lines difference is one of the example as a good measure for progress
• TODO: Think and research what other deltas that are good to measure SW progress
• TODO: Wiki is a required for the team blogging and communication
• TODO: Midterm is a self-evaluation of course work
• TODO: Argument for the midterm grade
• "Robert's Rules of order" - need to look it up, check a youtube video of it in action. What is the meeting like with this Robert's Rules of order?
• Agenda for the meeting is a must
• Focus on rules of discussions for group meetings
• TODO: Pick apart proposal, refine it, clarify
• TODO: Start preparing presentation for the customer(professor) ~10-15 minutes compact

Teams meeting was arranged for Saturday, 12:30pm. SVN repository had been set up, contact information was exchanged, and experience/skills were communicated among all team members.

Wednesday, February 23rd, 2011

Lecture Notes:

• Important to specify and credit the source of information
• It is hard to get logging the actions, thoughts into some journal form
• There was some noise in recording of votes, so E column and G column was added up

Teams had been formed:

SM proposal: SM,AK,IG,ALH,NS

JH proposal: JH,JD,RH,AS,BFR

AH proposal: AH,ED,KN,JD1,ANS

GIA proposal: MM,EA,GIA,TDG,K,LAG

DH proposal: DWS,E,VS,CJA,DH,AR

Team meeting must be done sometime before next class.

Review of Jacob Hobbs' Proposal

According to mentioned before reviewing scheme, here is a review of Jacob Hobbs' proposal

Summary of the proposal:

The proposed system is an automated management system that automates online game routine tasks. Farmville is an example of the such gave was given, where simple routine and boring tasks as collecting and planting plants, would be automated for end users.


Ratings:

Syntax = 5
Plausibility = 5
Support = 4
Novelty = 4
Stakeholders = 5
Scope = 4
Profitability = 4
Legal = 4
Security = 3
-------------------------------------------
Total score of the document = 4.22


Clarification on ratings:

• Syntax

Clearly formed ideas, professional language, and great grammar. I didn't see any typos nor grammatical errors. The minor detail, I didn't really like reference to automation tool as a bot, it is a slang afterwards, and it may scary some of the reviewers that have really bad associations with bots. Or may be it is just me, who really dislike the actual bots ;)

• Plausibility

I really liked an example presented as a potential UI look. Project seem to have great perspective, as well as the proposer seem to have the right set of qualifications for leading the project to the end.

• Support

Mainly most of the document had really great supported information. However, promised future salary to the involved stock holders and developers are somewhat arbitrary and would need some better support.

• Novelty

Unfortunately, Automation Labs had tried something similar, but that made me somewhat concerned why they didn't succeed in their product. I search for their name on google and any potential lawsuits. No lawsuits were found, however, they were wrongly blamed for violating privacy security of the users, which what might have put their success to end. This is something to be concerned with any product, especially if there were some similar attempts.

• Stakeholders

Developers would be the main stakeholders of the product, with some other potentially involved stakeholders.

• Scope of the project

Scope was somewhat unclear about features of the final product. To be more specific, on page 5 of the proposal, the author had referred to configuration settings as "[o]nce everything is configured", which was really broad and needs to be more specific, so the reviewer is aware of what to expect from the final product. The configuration settings in this particular automation tool are the main key in determination of the final product's capability.

• Profitability of the project

High profits promised in return to involved developers and stakeholders. However, the numbers of the promised/expected returns would need some better concrete support.

• Legal

No legal issues were discussed. Personally, I would be concerned about legal rights of Zynga as a main developer of majority of the online multiuser games for the social networks such as Facebook and Myspace. Some support seems to be needed to assure reviewer of legal intentions of the proposal's product.

• Security Concerns

Did see any major security concerns, other than may adding some greater detail about the how would the product provide the end user with the basic security measures. As well as put some thought about securing the licenses of the final product.

In overall, the product does have great potential beyond this class's time limit. The author of the proposal has great set of skills for leading proposed project to its successful end.

Voting for the team

With high consideration of all other projects out there, I willfully place all of my 5 votes for Allan Hayward's proposal.

Uniqueness of his proposal, as well as usefulness (which may let this project live a longer life beyond this class' timeline) made me highly interested in being directly involved in this project.

I would like to bring my contribution to the his project by helping with designing, coding, and testing of Web portal component of the Home Automation system. In addition, I would like to observe and learn as much as I can about the embedded hardware controller design and implementation process. Learning developing for Android OS is also bringing another reason for making me being being want to be involved in it.

As his proposal states, the Home Automation system would have three major sub-components that can be (and most likely will be) developed independently and later integrated to one system.

1. Embedded Controller

2. Web Portal

3. Remote Smart-Phone application

All three are very easily separated. The proposal has clear description and very clear scope that leads to better understanding of the project on a high and low levels.

I would also love to see more people working on this project with us, in Los Alamos. We all feel comfortable with meeting every once in Albuquerque with our remote members of the team, as well as using the video chat, IM, and e-mail as an additional communication tool.

Monday, February 21th, 2011

Lecture Notes:

• Ranking and scores had been posted on class website
• Available 5 votes for project selection

Friday, February 18th, 2011

Notes on presentations(Continued from Wednesday):

10. WC:

NOT HERE AGAIN

15. ALH:

Putting older online. Trying to keep the scope small.

16. EA:

Automated collaboration. Calendar schedule, meetings, etc.

17. MM:

Zombie survival game. Awesome demo on iPhone!

18. JD1:

Shopping try-on app.

19. JD2:

Sensors data collection from cell phone. Could be used for other app development.

20. DWS:

Post mark collection organizer. Inputs are in the form of data, not automated image processing.

21. VS:

Educational application for students. Coloring, writing, math modules. GUI is general enough from K to 6th grade.

22. AS:

Social network, chapter net. Doesn't seem to be unique.

23. ANS:

Army tutorial, introductory of all branches.

24. IG:

Robotics app.

25. ED: my proposal, my summary presentation.

26. RH:

Restaurant wait system through phone application.

27. TDG:

Scheduler for classes and rooms. Really interesting idea and has high potential.

28. AK:

Tech shop management proposal.

29. JH:

Pharmville proposal. Low cost bots SW for Farmville.

10. WC: finally HERE...

Virtual chat room(something like IMVU????)

Lecture Notes:

• Group selections, proposal evaluations, fair voting scheme.
• Elimination scheme for choosing one from the top proposals.

Wednesday, February 16th, 2011

Notes on presentations:

1. BFR:

Phat SW Proposal: something related to physics, didn't get an idea of the proposal.

2. AR:

Pattern generator for embroidery from an image.

3. E:

Affordable Network Enabled Tournament Management SW.

4. NS:

Locus Log: iphone app, social networking. Great final project views.

5. CJA:

iPhone multi-player game: listed some favorite games, don't know any of them and not clarified by speaker. Summary of the proposed game is too broad and unclear.

6. SM:

Chat with the gaming environment (out-compete yahoo IM and make it better). Scope is too large(many games promised).

7. LAG:

Zombie Earth Game: Google Earth as platform for the game. Copyright issue?

8. GIA:

Voice-based application launcher for Ubuntu OS: voice controlled application launcher. "rm -rf /*" command? Anyone?

9. K:

"Bullet Hell" game? Uncertain on completion of the game.

10. WC: PRESENTER IS ABSENT.

11. JD:

"Thaumaturgy" game: presenter didn't explain what was the game's prototype that he referred to. Clarified with some audience about some knowledge about it and continued on...

12. AH:

iPhone application: remote controlled thermostat. Great presentation.

13. KN:

Recipe organization SW: with DB for inventory.

14. DH:

Class Match: to help student to organize group work.

The rest presentations will be held on Friday.

Proposals Reviews

Since the professor posted listing of the proposals in reverse order when they were received, I will start from the bottom up to give some fairness and respect to the ones who submitted their final drafts right first.

(27) TDG score = 7/20

1 - 2: Hard to reference back to the time line without diagram no section devision

2 - 1: Pessimistic summary - proposer is not as enthusiastic about its own proposal

3 - 1: Presentational value (no sections, no graphs) lost my personal excitement

4 - 3: General component interaction diagram was presented, but no security, legal, ethical, and other potential issues were discussed.

(26) RH score = 6/20

1 - 1: Qualifications of proposer are great, however one thing really stood out as a warning flag: "I have fully completed several large-scale software projects from start to end." From learning perspective of this class and real world developing experience, it seems to be not feasible for one developer work on any large-scale projects by themselves. I would be highly interested to see actually what the proposer did and what had proposer considered to be a large-scale project. When the large-scale project was mentioned, something like OS scale project comes to mind.

2 - 0: Restaurant customers vary a lot. Proposed application is somewhat neat for 'geeky' customers, but not ready for the general public as not every one has smart phone with Android OS.

3 - 0: Seeing simple periods missing at the end of the paragraph, lowered my excitement even more after seeing no realistic usage of application as it was targeted to particular type of customers vs. a wider variety of regular restaurant customers.

4 - 5: Clear system description.

(25) ED This is my personal proposal, so as declared before, I am deferring from ranking my own proposal due to the conflict of interests.

(24) IG score = 1/20

1 - 0: Scope is very broad, so hard to estimate the feasibility of project's completion

2 - 1: There are many potential conflicts could be raised with proposed application: from approval of usefulness of application by School Administrations to parent's approval.

3 - 0: Excitement was reduced by misspelled words and poor formating of the document (Section "System Description" started at the end of the page with the text block starting on the next one)

4 - 0: Scope is too broad

(23) ANS score = 7/20

1 - 0: Scope is very broad. Number and scale of proposed quizzes, informational blocks, or games is not clear.

2 - 4: Seems to be a good tool used by many who have an interest in military services, but not necessarily aware of which particular branches might be the best fit and the most interest to the potential applicant.

3 - 3: Seems like a great useful tool that could be potentially used by many users. Great document structure, however, no system component design nor some sampler of the user's interaction (for instance no concrete game ideas).

4 - 3: Title shouldn't have been so generic, otherwise great introductory of the proposed product.

(22) AS score = 0/20

Caught eye attention to the high quality formatted report. Great and neat formatting.

1 - 0: There was no timeline (all described steps were not associated with any time restrains). Scope was unclear as well, and didn't see any qualifications of the proposer.

2 - 0: Interest for proposed project is very low level due to already created social networks (Facebook and others) that UNM students have available to them and actively using it: http://www.facebook.com/universityofnewmexico . Similarly smart phone applications available for those networks. It is seems to be much simpler to just create a new social group on Facebook.

3 - 0: Language seems to be very informal for proposal.

4 - 0: The key idea of making this product unique is barred on page 7, where introduction was very generally talking about the social network similar to FB. Very misleading and disappointing to see great idea to be barred like that and possibly lost due to the length of the proposal.

(21) VS score = 15/20

1 - 3: Scope of the modulars is very broad. Otherwise, proposed GUI application seems be feasible and clear

2 - 3: Personally, I can see some great usability of the product if the modulars are fun and application is easy to use

3 - 4: Proposal left a really good impression, and proposer seem to have right qualifications for leading this project to completion

4 - 5: Ideas were very clear

(20) DWS score=18/20

1 - 3: Scope seems to be clear and well defined, until timeline section where Identification Interface was introduced that was not mentioned before. There is no description of what it may look like or the functionality of it. Realizing that proposed project dealing with images identification, this part can be the most difficult by looking at the proposer's qualifications.

2 - 5: Proposed project have a high usability and idea is unique that feels in unfulfilled space of software applications

3 - 5: Project presented in the well clear format and in very professional manner

4 - 5: Ideas were well defined and clear

(19) JD2 score-0/20

1 - 0: Scope of the project seems to be too high for the given time constrains

2 - 0: Other products already out there, and proposed project's survival is seems to be very low

3 - 0: Idea of the project is not unique and products such a proposed already there. Also by looking at qualifications of the proposer, this highly graphical interface seems to be too high of the scope for the time constrains of this class. Budget table was cut off. One empty page right one the middle of the document looks really bad from the presentational perspective.

4 - 0: Scope was really broad.

(18) JD1 score- --/20

Kudos for making two proposals, but personally I would prefer to see one with higher quality and formatting. ;)

1 - -- Really lost interest in looking for feasibility of the project

2 - 0: Doesn't seem to be appealing nor beneficial to the end user to have proposed application

3 - 0: Seeing the similar bad formatting of the tables and empty pages, just left me not wanting to go in greater reading detail of the proposal

4 - -- Really lost interest in looking for clarity of the project

With all respect to all of the proposals, from seeing how much reviewing does take time, I would still scan through all of them, but will not be providing any feed back, unless it truly caught my attention. All of the reviews provided here was the result of two nights worth of work, about 5 hours each day.

Note to all :

I tried to me as honest as I could, not being biased, and without meaning to offend anyone by reviewing their hard work. Most of the proposals are great and took time for completing.

I truly find this assignment as a given opportunity for great learning experience in seeing what qualities really attract reader's attention and what (even minor) flaws draw the excitement levels down.

Reviewing experience will definitely help me personally understand reviewing process and make be a better proposal maker!

Proposals ranking scheme

Ranking proposals isn't the easy thing. In order to have a good presentational value for each proposal, I will reference to the following scheme with the characteristics I personally find valuable for project considerations.

SCALE: from 0-'really bad' to 5-'just outstanding!'

CATEGORIES:

1. Completion feasibility (scope scale and time line)
2. Profits' perspective (Usability of the code: Will the code have high potential usage or is it just another 'shelf decoration')
3. Personal interest and excitement about proposed project
4. Clarity

Due to conflict of interests, I will defer from evaluating my own proposal. For the same reasons, I highly hope most of the students find that it is the right thing to do.

Monday, February 14th, 2011

Lecture Notes:

• Only realistic projects usually get accepted
• Think about scheme for evaluating proposals
• Review posted proposals and leave some feedback
• Quality of proposal writing is highly valuable
• First paragraph (abstract - executive summaries) should catch attention of the reader
• Ratio of acceptance in this class will be close to the real world acceptance ratio ( ~ 20%)
• Pros and cons of the document
• As in real world, the one should never reviewing your own proposal / in class, it is up to proposer to decide about reviewing your own proposal or not. If decided to follow with review of your own proposal, be honest and critical to your own work

Link to picture for proposal's brief presentation

Link to the picture of European prototype

Requirement List for proposed DTCS

The list of project requirements for proposed DTCS

Definitions:

Agent - any independent system element that is has its basic behavior and makes independent decisions, but based on its signals and information received from the central database(DB).

Sensor - sensors that detect traffic changes and report signals from emergency vehicles.

Central Database (DB) - basic database that is accessible to all the agents for reads and for writing only information about itself.

Requirements:

1. The Central Database(DB) shall be accessible by all agents.

2. If for any reason the DB is down, each agent shall have default values to go by until the connection is re-established with the DB and data is available.

3. It shall only be possible to add new information to the DB from sensors in the system. It should not be possible to modify any of the existing records in the Central DB.

4. Agents shall only have read access to the data.

5. A script shall clean old data from the DB and save it all into a log file, for cleaning purposes. It should not be possible to delete data manually.

6. Only an authorized user (privileged, such as a system administrator, who clearly understands his/her responsibility) shall be permitted to run the specially created script to clean old data from the DB.

7. Data dump (backup) files of the DB shall be created on a regular basis, in case of any data loss for easier data restoration.

8. All agents shall have constraints for maximum and minimum values, in order to avoid any potential data corruption from the DB as a safety switch.

9. Reports shall be created on a regular basis which document the performance and availability of the system, for the purpose of verification and statistic gathering.

10. Documentation on all available reports, files, DB dump files created by the system.

11. All classes shall have JUnit test suite.

12. Every class shall have detailed description in its header comment block.

Friday, February 11th, 2011

Lecture Notes:

• New assignment posted
• Make refined version available
• List of requirements for system(functional, non-functional)
• Requirements is the hardest problem to nail down for SW Engineers
• Prepare short oral presentation (1-2 minutes) - Monday and Wednesday classes
• Link by the end of the day
• Last time, requirements were covered in detail
• Function of every system is different
• Non-functions requirements: Usability, maintainability, ecstatics, marketing, all process aspects of developing SW(testing planning, code standards), security and privacy
• Unix password system(hashing) - inversion is really difficult
• Saving time for possible adaptation of existing standards (why is that the correct way to go)
• Consideration of the end user, as well as possible other types of users (see Example below)
• Testability - some way of verifying that the requirement was met
• Traceability (SVN, logs, team queues, requirement traceability as they change and increase)
• Requirement MUST be unambiguous
• Completeness of requirements
• Is the requirement is realistic?

Vendor machine example (user types)

• purchasing user
• person that maintains vendor machine with the inventory
• hackers :)

First group meeting

Due to unexpected class cancellation, we decided to proceed with the group meeting and decide what project we all would agree to proceed with. Cancellation was unexpected and since we already did loose couple of the lectures last week, we agreed the time is really critical and essential at time point, and we would like to make the most of it.

With consideration about future usage of our work, we decided to go with Allan's proposal.

We discussed what potential problem we might run into with his project and what initial steps would be in setting the system up.

We also discussed an opportunity of one more developer involvement from the main campus if anyone would be interested.

Wednesday, February 9th, 2011

The lecture was cancelled today... :(

Final draft of the proposal with corrections

Final draft available here, in PDF format, at my course list site.

Corrections for Katherine Nystrom's review

Thanks for taking time to review my proposal, I really appreciate it!

Here is an update about the corrections that had been done:

Typos
- change "smoothly drive" to "drive smoothly"

Rephrased, thanks!

- p. 5 "somewhat become easier" to "become somewhat easier"

Rephrased, thanks!

- p. 6 "in" should be "is" in "harmonizing speed limit signs in not exactly a complete traffic control system"

Great catch!

- p. 7 add the word "of" to "variety techniques"

Another great catch! Thanks!

- p. 11 "team meeting" should be "team meetings"

Corrected, thanks again!

Corrections for Allan Hayward's review

Thanks for detailed review, I really appreciate you taking your time!

Here is an update for the corrections been done:

Syntax:
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.

Good catch, corrected

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

I would argue about the general comment about the font size and spacing. It was a recommendation during lecture and not a requirement as the document does not say anything specific on the font size and/or style. I used template for technical paper acceptance guidelines.

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

The word is in correct form, however, rephrasing definitely needed for clarity.

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

Thanks, corrected!

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

Thanks, corrected!

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

Re-phrased.

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

The dates allowed for implementation are from 03/02 to 03/22, which is three calendar weeks, with 15 business days. So the reference to time line is correct. I am kind of confused where four weeks come from. JUnit testing does run for about four calendar 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.

LOL, Thanks!

System Requirements Specification (In greater detail)

Prof. asked to think and place a more detailed break down of what should be in our System Requirements Documentation.

System Requirements Specification (SRS) is basically an organization's understanding and agreement completed in writing about proposed client's system dependencies and requirements provided to customer prior any actual design or work.

List of what SRS document should include ( contains previously discussed items along with expansion and newly added items):

• High level goal (tree structure) - while most of implementations done in bottom-up approach
• (A) Functional requirements

A.1 User

A.1.1 User qualifications (assumed or required)

A.1.2 User interface and environment

A.2 Performance

A.2.1 Time requirements - specify at which speed system must operate

A.3 Concurrency - how multi-threading must be handled by the system

A.4 HW requirements, platform requirements

A.4.1 The hardware to be used

A.4.2 Hardware limitations (s.a. minimum memory amount required)

A.4.3 Compiler to be used (version, distributer, etc.)

A.4.4 Any SW and OS dependencies, s.a. what OS and what versions system required for operation, what other SW packages, programs, or libraries expected to be installed on PC/Mac prior to system's installation and run

A.5 Data flow diagrams, high level highlights on how the system is working and responding to certain events

A.6 Quality requirements

A.6.1 Quality assurance planning

A.6.2 Configuration management of the system

A.7 Reliability requirements - can be specified by Mean Time Between Failures and/or Mean Time to Repair.

A.8 Maintanability requirements

A.8.1 Trace and repair of defects (logs)

A.8.2 Modularity of SW

A.8.3 Readability of the code

• (B) non-functional

B.1 Documentation

B.1.1 Operational requirements - how system will be used and usage in hostile environment, prioritization of failed events (emergency planning)

B.2 Trademark, legal

B.3 Aesthetics (look & feel)

B.4 Coding Standards

• (C) Testing

C.1 Specify how and what tests will be done during development, test data.

C.2 Acceptance testing - specifies the tests will be used for the user acceptance of the system ( Integration test suite and data sets)

• (D) Security

D.1 Security requirements and concern for the system's normal operation and how security bridges will be handled by the system if any to occur

Monday, February 7th, 2011

Lecture Notes:

• Final proposal document due by Wednesday
• Quick demo in class, next week (hopefully, next Monday)
• Projects grading - how well proposed specifications of the project were implemented
• "Extreme programming" rarely used in practice
• "Waterfall" process is widely used and widely adapted at the SW project planning. It is also a luxury to have it in some cases.
• All testers are not alike; testing time is expensive.
• "Recapture" (training set for system learning)

System requirements document:

• High level goal (tree structure) - while most of implementations done in bottom-up approach
• (A) Functional requirements

- User

- Performance, timing

- Concurrency

- HW requirements, platforms requirements

• (B) Non-functional

- Documentation

- Trademark, legal

- Aesthetics (look & feel)

- Coding Standards

• (C) Testing
• (D) Security (not sure where it fits, it is overlapping possibly more than one particular requirement, so placed in its own category for now)

Friday, February 4, 2011

UNM had been closed due to gas shortage caused by extremely low temperatures. No class notes today.

Wednesday February 2nd, 2011

All UNM classes got canceled due to a heavy snowstorm, so no lecture notes for today.

Proposal Reviewing

Here in Los Alamos, since there are only three of us, we decided to review all of the proposals in effort of optimal and valuable feedback. Regardless of reviewing process taking a long time, I am really glad to have this experience.

Review of Katherine Nystrom's Proposal

Summary of the proposal:

The proposed system organizes recipes in database storage, as well as by keeping track of a food inventory, system is capable in preparing an ultimate grocery list.

Proposed system will have two modes: web based and stand alone application.

Ratings:

Syntax = 3
Plausibility = 4
Support = 5
Novelty = 4
Stakeholders = 3
Scope = 3
Profitability = 4
Legal = 5
Security = 4
-------------------------------------------
Total score of the document = 3.8


Clarification on ratings:

• Syntax


(1st page, 1st paragraph, last sentence)
"As a follower of many top food blogs and a home cook and baker I feel
qualified to advise and participate in this project."

This sentence above somewhat unclear and have too conjunctions with no commas or other clause/sentence breaks. I would strongly suggest rephrasing this sentence into something as follows:

"As a follower of many top food blogs, a home cook, and a baker, I feel
qualified to advise and participate in this project."

(2nd page, 2nd paragraph, 3rd sentence)
"However keeping..." is missing a comma, and should be written as "However, keeping..."

(3rd page, 1st paragraph, 2nd sentence)
"Products range in cost from $80-free.

The formatting of this sentence would generally look better and more professional as follows:

Products range in cost from $80 to free.

Formatting of the time line spread sheet was in non-viewable format. Table is over several pages, probably larger scale of the time line range should have been selected.

In general, though out the document, there are few clauses that are missing clause breaks, which decrease document's readability and clarity.


• Plausibility


Scope of the project is somewhat unclear. Author mentions two modes of the final product, however, due to highly competitive market of proposed product, it seems to be logical for the end user to expect all of the features listed in "Background" section of the document.


• Support


Author of the proposal done great research on the proposed product and have great listings as an attachment for viewing.


• Novelty


Highly competitive market with ready to use applications at no cost to the end user. However, keeping database for inventory control is the main attraction for this product compare with the ones listed. I would suggest to put a higher emphasis on this distinguished characteristic to attract higher number of potential stakeholders.


• Stakeholders


Proposer places high emphasis on proposer's personal usage of the product. That is not generally what the stakeholders want to see in the proposals.

In addition, the following wording as a reference to potential users needs to be carefully thought through:

• " young tech savvy professionals."
Such specific and narrowed categorization of the end user, might draw away interest in a product from many potential users as well as stakeholders.


• Scope


Scope is unclear on what particular features will be implemented and what features will not be included in implementation. But I like optimistic mood of the proposer when she referring to add-ons if project will get "ahead of schedule." ;)


• Profitability


It is hard to compete with the 'free' stuff out there, as well as advertising new product that is somewhat similar to many others.


• Legal


Nothing mentioned on legal issues, but personally, I don't see any problems with this product.


• Security


Nothing was mention on how would the proposer would manage protection of database and its back-ups. Safety of collection of data is major concern of the end user, especially if it took one to collect something over a long period of time.

In overall, the product idea is very interesting and promising. The author seems to be competent for successful completion.

Review of Allan Haward's Proposal

Summary of the proposal:

The proposed system automates remote access to the building's control devices through smart-phone's application using wireless connection. Proposed system will have a flexible and configurable user web interface and reliable alert notification system.

Ratings:

Syntax = 5

Plausibility = 5

Support = 5

Novelty = 5

Stakeholders = 5

Scope = 5

Profitability = 5

Legal = 5

Security = 5

----------------------------------------

Total score of the document = 5

Well prepared and presented proposal. Time line and cost break down tables have great details. However, need verification with the customer's deadlines as the proposed time line does include finals week.

Minor suggestion(1st page, 3rd paragraph, 1st sentence):

"This proposal describes a system that integrates the need for people to remotely access their building/home with the new capabilities of the smart-phone."

This sentence somewhat unclear and misled me to think that the user will be able gain access to the building itself through the remote application, so I would suggest to be more specific by replacing "building/home" with "building's devices".

In overall, author has great prior experience that well prepares him for this project. The project has high potential.