Wednesday, May 4, 2011

Redirecting port 80

Solution had been found on how to re-direct port 80 to any custom port:


You can redirect connections on port 80 to some other port you can open as normal user.

Run as root:

# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080 


From source: http://serverfault.com/questions/112795/how-can-i-run-a-server-on-linux-on-port-80-as-a-normal-user


Monday, April 25, 2011

Monday April 25th, 2011

Lecture Notes:

  • Next week - presentations following NW Angels presentation format
  • Rehearsing for presentation is highly important
  • Role of the slide is to support spoken points
  • 5 maximum bullet points per slide
  • Avoid any clip arts
  • Flow presentational guidelines: http://www.nmangels.com/entrepreneurs/presentation-guidelines/
  • Each point said has a maximum amount of information without a feel that it is spoken out fast
  • Summary on 2 pages to take away with them (Bring about ~15 copies)
  • Intellectual property - what level of disclosure this presentation will be held at
  • Watermarking, tracking of documentation
  • How to approach copyright and idea protection with tact
  • Re-iterate the key three points though out presentation and repeat at th bottom of the talk
  • Pain points - what caused, what were the symptoms for this project to start
  • Names: Joe Chavez president of NM Angles, Bob Coraley(sp?), Zack Grafe.

Monday, April 18, 2011

Monday April 18th, 2011

Lecture Notes:

  • Big picture, how it is different, where is this product fit in to be compatative
  • Specific presentation format ("New Mexico Angels presentation") that captured here http://www.nmangels.com/entrepreneurs/presentation-guidelines/
  • How things changed?
  • In-class presentation week.
  • Final is on ....
  • 10 minutes presentation + 10 minutes for questions and feedback
  • Dead week - 2 presentations Monday and Wednesday, one on Friday.
  • Every week must be prepared for Monday
  • Be prepared for a set of questions that might be asked and answers, how requirements met, how they thought through
  • Wrap up the SW and give the demo
  • Polish SW
  • "Looking at the team as a whole"
  • Well transitioning, well placed and well-driven demos

Monday, April 11, 2011

Monday April 11th, 2011

Lecture Notes:

  • Prioritization of the tasks helps with successful delivery of the product
  • Rational for prioritization
  • Iteration at the abstract level
  • Design patterns and programming approaches used for product development
  • Part of agile SW development is to have working code on each step
  • Delivery of SW - demonstrable product, a professorial looking polish
  • Set of the demos that will be shown in final demo
  • Test first is on the top of the list for chosen SW Development process
  • Find a set of users for testing the system
  • What is done vs. proposed
  • What changes were done, how it was tracked
  • How far off we are on the estimates? Matrix on the difference is a plus
  • What had been neglected and what was mentioned over several weeks in the row in the meetings
  • Test first and acceptance criteria
  • User doc, Developers Documentation, SW Process, Accounting how you and team worked together, Demo, Secret Sauce(something that can be pulled and re-used)

Monday, April 4, 2011

Monday April 4th, 2011

Lecture Notes:

  • System needs to be ready for demonstration with all of the requirements fulfilled
  • Secret sauce of the project to progress - true bit of intellectual property that we are generating during this semester (Key intellectual property - what is that you understand more than anyone else, what is that special about it that no one done before)
  • How to do group evaluation? Velocity is one of the metrics. Online evaluation resources. Set some goals to improve and exploit. Be objective with tact.
  • The biggest value in criticism is that is opens up the main flaws and areas for improvements
  • Self-evaluation ( looking for big delta, big accomplishments, how to make the self-eval better)
  • Recognizing in yourself what are the areas for improvement, ability to look at yourself objectively, understand the reader self-eval was prepared for
  • Make short and easy to read ( in consideration that the prof. have to read 30 of self-evaluations)
  • Necessary and sufficient conditions ("overly completed is less complete")
  • If you know how to do it right, then you should understand better how to do it even better next time
  • "Verification and Validation" method (doctest in python) - demonstrated by Jacob

Monday, March 28, 2011

Monday March 28th, 2011

Lecture Notes:

  • Analysis of the progress and visual measurement of thus is a must for Wiki
  • Verifiability of correctness and completion of the requirement
  • Consistency: reference to original requirements
  • Traceability: a creditation for the work done.
  • User stories/cases describe user events and how the system responds to an event
  • User cases should be short clear and consistent in the format
  • Realistic expectations
  • Measurement of project velocity is highly meaningful
  • Design patterns, coding standards
  • "Every cut and paste code is a newly introduced bug to the code"
  • As an exercise -- Pick large task and complete by the end of the week no matter what - test sprint
  • Understanding clearly the boundary of the the problem, understanding of protocols on server/client communication
  • Re-factor code and try to build into components
  • Centralize, localize code and run tons
  • UML diagrams
  • Other team project disc.: proposed content is too broad; too vague; it was had to summarize and give a description of the project.

Wednesday, March 23, 2011

Remote Desktop as another way of pair programming

Today, I was able successfully configure Ubuntu OS sharing desktop option that will not just enable us to use our web portal PC with all it's available tools and widgets remotely, but also do some pair programming as we navigate through the same space with enabled Skype communication.

Just for any of my personal future reference, I would like to post the link with simple step by step instructions on how to set up remote desktop from Ubuntu OS:

Sunday, March 20, 2011

Installing MySQL tricks

Somehow when MySQL was installed with pre-downloaded files on Ubuntu 10.* OS, it corrupted some of the deb files.

After hours trying to figure our how to not just uninstall, but correct the deb packages, I finally ran over this site that saved me and Ubuntu OS from being re-installed:



Friday, March 11, 2011

Friday, March 11th, 2011

Lecture Notes:

  • Advantages online class - to review lectures later, but taking class notes saves all of that review time
  • One of many goals of this class and meetings - learning to be professionals, but other classes have higher priority to attend
  • Mondays - MEETING as a CLASS
  • Wednesdays - WORK TIME: pitch meetings with professor or lab time with the group
  • Fridays -WORK TIME: pitch meetings with professor or lab time with the group
  • Pitch meetings: Pitfalls, details, challenges of the chosen SW process for the team
  • The only stupid question is the one you didn't ask
  • Systems where people can be working at the same time (plugin for Eclipse? or similar tool)
  • HW vs. SW development: HW fixing or re-working is highly expensive
  • Managed scope control - allow feature change as the development goes (time, quality, or cost)
  • Mars mission example - miscommunication of requirements across modulars

Wednesday, March 9, 2011

Wednesday, March 9th, 2011

Lecture Notes:

  • SW Development process should make work easier and not harder
  • References of sources is highly important on any work and any material used\
  • TODO: Coding standards by the end of the week (indentation )
  • Procedure for check in/out
  • Checking per task completion
  • No submitting code that has warnings or errors
  • Stack SVN - tool for generating the stats for SVN commits and usage
  • -m "Detailed message for each commit"
  • Setting an alarm for every ~30 min for a break to increase work productivity
  • What is the process of potentially changing set process rules? What is the process of adding new rules to the process?
  • How to capture a requirement?
  • What is the evidence of requirement set? (Task Queue, Process Page, etc.)
  • Difficulty in terms of time and implementation

Tuesday, March 8, 2011

Midterm: Self-evaluation

Looking at myself objectively, even though it is hard to evaluate own work as it is always flawless in creator's eyes, I strongly believe that I deserve at least A- as a midterm grade for several reasons.

The objectives for the grade is that blogging was consistent through out the semester. All of the asked blogging posts were researched and posted as asked on time. I have actively participated in class's discussions when they arose and took a load on my shoulders of the leading role for the great team of developers.

Written draft and final version of team project proposal.

Presented my proposal to the class in the 2 minute summary.

Reviewed all of the classmate's proposals, where three of those were reviewed in higher detail and detailed feedback.

The only deduction I should take on is for failing to post a follow up post/comment for final proposals' review. I did reviews of the first ~15 (from the bottom) and after that commented that it was taking too much time on reviewing all of them because they were all unique and I wanted to read all them in the great detail. By promising to give reviews only to the ones that spark my high interest, I did fail to post that none of the rest sparked any high interest, for the exception of Allen's and Katherine's proposals, which I reviewed previously in the draft versions. All the rest that I read were game proposals, ideas of which didn't seem to be unique.

In any case, I did provide three full reviews(with one being required) of draft proposals for Allen Hayward, Katherine Nystrom, and Jacob Hobbs.


Monday, March 7, 2011

Monday, March 7th, 2011

Lecture Notes:

  • All teams highly suggested to have a consultation with marketing representative outside the class
  • In this class economy is our time
  • "Never use your own money" for any business start up
  • BLOG ASSIGNMENT: Statistics on the success rate of the starting the company(not a survival time) - technical company
  • Any profit is a profit!
  • Think about the market available for our developed product, who would be the buyer, how large is the number of such buyers
  • Study upfront and understanding of the market value of the product is highly important for the success
  • Comparison with any existing products similar to the proposed project
  • Within a process there is a way capture requirements
  • TODO: Self-evaluations by WEDNESDAY
  • Use the process before involving QA person

Saturday, March 5, 2011

Friday, March 4th, 2011

Lecture Notes:

  • Group presentations going through
  • Accountability and communication in the team of developers is highly essential
  • Some process better and than others for different development methods
  • A process should help to match customer expectations with the delivered product
  • Defined SW process models commonly combined for the best achievement of the goals
  • Feature creep kills the good products
  • Keeping an eye on the critical path through out the SW development process
  • Teams need to identify their critical paths

Wednesday, March 2, 2011

Software Development Process

SW process, or as commonly referred to as SW lifecycle, is a set of rules and procedures applied to the development of SW product in individual and team disciplines.

According to Wikipedia, there are four distinguishable disciplines (models) that commonly used in SW development process:

  • Waterfall Model
  • Spiral Model (combines Waterfall model and rapid prototyping with the emphasis on risk analysis)
  • Interactive and Incremental Model (commonly used in incremental development when the customer doesn't know how to define what is wanted/needed in the final product)
  • Agile Development (XP and SCRUM)

The following are less commonly used practices:
  • Model-driven engineering, which is focuses on the user domain models rather than algorithmic concepts
  • User eXperience (UX) concentrates on the end user's demands with high emphasis on the ease of use
  • Chaos Model provides methods to solve bugs and other technical difficulties as well as helps to manage development process and maintain deliverables schedule
  • Software Prototyping Model refers to the creating incomplete versions of SW. Prototype usually simulates only few aspects of the final product
There are many more models that are used by SW developers that can be viewed on Wikipedia

Wednesday, March 2nd, 2011

Lecture Notes:

  • Setting up inner group communication could be challenging. There are some tools out there to help with that.
  • Treat information provided from professor as questions to be asked
  • Knowing how to intelligently ask the right question with right support and background search
  • SCRUM for group dynamics
  • Waterfall Engineering
  • Systematic development process for the team is a must

Tuesday, March 1, 2011

Ideal Measurement of Software Development Process and Individual Effort Evaluations


Does the ideal measuring tool even exist?

It is so hard to measure programmers performances through basic measurements usually done and are common. Here is the list of such and how thus can fall through the loops as being the worst measurement:
  1. Lines of Code (some developers just pile up useless lines of code, while others may over-engineer simple tasks or have increasingly high code block repetition)
  2. Number of Bugs found in the code (the onces that don't code, don't have ANY bugs)
  3. Number of Bugs fixed (some bugs are very trivial and some are not)
  4. Completion time against their own estimate (one can always add some slack time in their estimation)
  5. Number of JUnit test failed (if no JUnit tests are written, then there is nothing to fail)
  6. JUnit test coverage (tests can be written weakly that do not fail, but do not test code properly)
And there are many more measuring units can be easily added to this list.

In many of the researched articles people suggesting measurements I have listed, but I believe it is just not enough to measure a developer's performance. From personal experience, personally I strongly believe it take a great manager who is great in understanding people and who can look at each individual subjectively to determine weighter they are doing a great job or not.


In my personal opinion, the optimal performance measurement was suggested on one of the StackOverflow.com discussions:

"
  • Lines of code
  • Number of check-ins
  • Hours in the office
  • WTFs per minute
  • Number of daily page visits to stackoverflow.com "

  • Monday, February 28, 2011

    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

    Sunday, February 27, 2011

    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 25, 2011

    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.

    Thursday, February 24, 2011

    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.

    Monday, February 21, 2011

    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 18, 2011

    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 16, 2011

    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.

    Monday, February 14, 2011

    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

    Sunday, February 13, 2011

    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 11, 2011

    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 :)


    Wednesday, February 9, 2011

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

    Tuesday, February 8, 2011

    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!

    Monday, February 7, 2011

    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

    Friday, February 4, 2011

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

    Wednesday, February 2, 2011

    Wednesday February 2nd, 2011

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

    Tuesday, February 1, 2011

    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.

    Monday, January 31, 2011

    Monday January 31st, 2011

    Lecture Notes:

    Reviewing proposal review is essential part of proposal writing.

    Expectation from feedback(with the scale [1..5], where 1 is too low and needs improvements, 5 is excellent):
    • SYNTAX: Clarity, Detail, and Completeness
    • SYNTAX: Restate idea(to assure the reader was clear of the understanding of the project) - about 1-2 sentences
    • SYNTAX: Inconsistencies within documents
    • SYNTAX: Structure - Grammar, typos, legibility of figures, diagrams, spread sheets, etc.
    • Plausibility (feasibility of implementation and completion)
    • Support (evidence for any claims)
    • Novelty
    • Stakeholders(identification: investors, end user, etc.)
    • Scope of the project
    • Profitability of the project
    • Legal (Copyrights)
    • Security concerns
    • Total Score of the document
    The feedback must be posted as a comment on the proposal's posting as well as an independent posting on the reviewer's site(with identical text).

    DO NOT clarify anything to the reviewer, he/she must review the document by itself with providing the feedback of the document.

    The proposal paper should be professionally done.

    Sunday, January 30, 2011

    Homework: Requirements on selected object

    The main object I rely on every morning is my coffee maker and a coffee mug. So my selected object will be the one I carry around for the first half a day, just about every day - coffee mug!

    Here is the list of 'must' have requirements:
    1. Must be large enough to hold medium drink.
    2. Must easily fit in one's hand (by either have a good grip or a handle).
    3. Must fit into the car's cup holder!
    4. Must have good isolation for preventing burns to the carrier, as well as for preserving drink's temperature for a longer time periods(either cold or hold).
    5. Must have secure lid that functions as a isolator and spill proof cover.
    And here is the list of 'desired' characteristics:
    1. Would be preferred to have nice stylish design to attract a potential buyer.
    2. Would be preferred to be make of some durable materials that will last and don't break from the first fall to the ground.
    3. Would be preferred to be microwavable.

    Proposal for Dynamic Traffic Control System

    Here is my proposal for the team project. Download PDF here

    Friday, January 28, 2011

    Background research

    I just want to add this link to the blog which describes already implemented the actual Speed Harmonization Signing system in Netherlands and Germany. I have never been in neither country and never heard of this system used, but according to this website they have used this system since about 1970s.

    I am actually kind of shocked, but pleasantly surprised by this discovery that people already been thinking and making a huge effort in building such systems to relief the stress on the roads.


    Friday January 28, 2011

    Lecture Notes:
    • Reviewed UML. Cheat sheet with the arrow diagram - here
    • Modeling is an important learning milestone in this class, understanding of UML eases this learning.
    • Training and budget: sometimes need to set some time aside and budget for training time.
    • IBM 360 example: adding new person to the project isn't always good because there is time consumed for training
    Important Considerations for SW products development
    • Maintainability is an important factor for the design of SW products
    • Financial Profitability - even for the open source SW
    • SW product must be within legal bonds
    • American society is very entertainment and service based
    • Copyright - important to have legal considerations about SW development
    • Licencing SW, maintaining the ownership of the SW and renting SW licences.
    • Privacy
    • Testing
    • Security factors and concerns: 'Fuzz test' - blast SW with garbage (Can't potentially protect yourself from every possible bridge, but this test could potentially reveal at least some of the most obvious)
    • Liability
    Think about it:
    • Take some device from daily life and break down design of it down what considirations used for design of this particular product ( ex. used in class - alarm clock)
    • UML cheat sheet on the blog