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.

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:

http://www.ubuntugeek.com/share-your-ubuntu-desktop-using-remote-desktop.html

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:

http://journalxtra.com/2010/03/fixing-the-dreaded-errors-were-encountered-while-processing-errors/

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

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

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

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

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 "