One of the ebooks (1311 pages) is Programming Windows Store Apps with HTML, CSS, and JavaScript, Second Edition, by Kraig rockschmidt.

MVA has added 3 New Free ebooks. You can access them here.

Do you have more mistakes to suggest? Please feel free to add to the list.

There are three different acronyms for Cloud Computing, the 3 faces,

1. SaaS: Software as a service
2. IaaS: Infrastructure as a service
3. PaaS: Platform as a service

SaaS applications are run from your browser. Usually you do not have to install something to run  them. Email services like Yahoo or Gmail are SaaS applications. Google search is a SaaS application. Using these services you do not care on what type of servers are run, who makes the OS (operation system) updates, who writes the code, where your data is stored, how the vendor load balances the traffic to the application. You only care on the availability of the service and the security of your data.

IaaS gives companies or individuals the opportunity to move their computers or servers on the cloud. Why you may choose to do that? Because of cost benefits, space benefits, stuff benefits, scale benefits etc.Infrastructure means that the provider of the service (Amazon, Google, Rackspace and many others) provides the tools to create a virtualization platform with storage and networking services. To give you an example, assume that you have two servers running your applications and sharing files / information at you premisses . When you decide to move them to the cloud you have the ability to create two virtual servers on a stronger physical machine. You can do it on your premisses too, but by putting them on the Cloud gives you more advantages like you will stop worrying about hardware issues, bandwidth, network infrastructure and scalability issues.

PaaS is a great way to create distributed applications that can have 99.999% availability. To leverage the benefits of a PaaS you have to architect your solution to take advantages of the platform offerings in queues, blobs, storage and other areas. Why to choose PaaS to develop your application? You have numerous benefits such as scalability, reliability, no OS administration time and costs and many other advantages. I will discuss in another blog post how to architect such solutions.

You have to remember that by just putting your application on a cloud server you do not transform them to a PaaS application or to a SaaS application. In almost all the cases you will need to rewrite parts of your application.

Which of the 3 faces of Cloud computing is suitable for you?

IBM has also built a new programming language and a new software ecosystem that supports the full software development lifecycle. The new generation of applications will mimic the brain’s abilities for perception, action and cognition.

The new chips will allow the creation of many interesting applications including autonomous robots. I am wondering how far IBM is for creating the first artificial life with self -awareness.

The research was conducted by Chao Zhang and Keith Ross of NYU-Poly; Stevens Le Blond of the Max Planck Institute for Software Systems (MPI-SWS), Germany; and Arnaud Legout and Walid Dabbous of the French research institute I.N.R.I.A Sophia Antipolis.

It is important to mention that  even when a user blocks callers or connects from behind a Network Address Translation (NAT) , it does not prevent the privacy risk.

By using commercial geo-location mapping services, the researchers, found that they could construct a detailed account of a user’s daily activities even if the user had not turned on Skype for 72 hours. In one example, they accurately tracked one volunteer researcher from his visit at a New York university to a vacation in Chicago, a return to a New York university, lodging in Brooklyn, then to his home in France. “If we had followed the mobility of the Facebook friends of this user as well, we likely would have determined who he was visiting and when,” the authors said.

How do we value our privacy?

The researchers has informed Skype and Microsoft for these vulnerabilities.

Code review or software inspections are used to spot software errors, omissions and anomalies. The code review as the name implies is to look at the source code for errors and defects. To successful perform a code review a team of at least four people must be formed. The roles are:

1. Author – programmer: the one who owns the code and is responsible for fixing the errors.
2. Inspector: Inspects the code and/or the documentation to find errors – omissions.
3. Reader: Presents the code – documentation
4. Scriber: Writes the findings of the code review meeting.
5. Moderator: Manages the process and facilitates the inspection.

It is very important to keep any questions or comment to the code and not to criticize the developer. When done correctly code review is a positive experience for the team and a learning tool for all levels of developers.

In order to initiate a code review you must:

• Have a complete and precise documentation of the code under inspection.
• The team must know the coding standards that the organization uses.
• The code must be updated and must compile, prior to the inspection. It is a waste of time to inspect code that does not compile.

During one hour of inspection about 120 lines of code are reviewed. It is not recommended for the code inspection to last more than one and a half hours.
It is very important during the inspection to read and translate the code in plain English, based on the specifications. This way everyone can examine the logic and validity of the code.

Why should somebody prefer code reviews from testing?

• During the testing, there is a possibility that an error can mask other errors.
• Testing does not guarantee the code quality and code efficiency.
• In applications that use threading errors cannot be caught with testing but only with a thorough code review.

An advice to software project managers:
I would recommend planning time for code reviews in every project. Code reviews is a great way to mitigate code related risks during the early stages of development.

References and useful links

1. Rober Bogue (2006) Effective Code Reviews Without the pain http://www.developer.com/tech/article.php/3579756/Effective-Code-Reviews-Without-the-Pain
2. Josh Poley(2007) Best Practices: Code Reviews http://msdn.microsoft.com/en-us/library/bb871031.aspx
3. Sommerville I (2006) Software Engineering. Addison Wesley; 8th edition
4. Wikipedia (2010) List of tools for static code analysis http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#.NET_.28C.23.2C_VB.NET_and_all_.NET_compatible_languages.29

There is a difference between open standards and open software. It is very important to note that open standards can be used by both open source and closed source software programs. There are cases that the reference implementation of an open standard can be available for non-commercial use. (Dave Welsh, 2004).

The open source initiative gives guidelines about what is open source. Open source does not mean only access to the source code of a software program but also includes guidelines for the distribution of the source code.  The license must allow derivate works and modifications.  The license must not restrict the use of the source for a specific field, such as only for non-commercial use or only for research.

The simplest way to make software public is to put it into public domain without any copyright. This method does not protect the source code and the creator of the source code from someone else (individual or corporation) to copy the code, and create proprietary software. Open source licenses come to solve many problems involving with open source. The license is needed for a simple reason to protect open source.  There are many types of licenses including:

• The GNU General Public License (GPL),
• The Lesser GPL,
• The Apache license 2.0
• and many others.

There are also licenses of free software that are incompatible with the GPL licensing. Such licenses include:

• The Apache license 1.1,
• The IBM public license,
• The Microsoft Public license
• and many others.

There are many variations of licenses regarding free software. A company must invest a lot of time to read and comprehend the various licenses especially if you want to use some open source library in a commercial product. Some licenses may allow only the distribution of the source code along with the source code of the derivative work or that someone can use the source code and the derivative work can be a closed system. It is worthy to note that open source software does not necessarily means free software.

Richard Stallman initiated the GNU project and the free software movement. The main idea was that users should have the freedom to change the programs in whatever ways they wanted and not to be locked in to a specific product. IBM and Oracle used Linux which is open source and free to weaken Microsoft. Companies started using Linux to and a lot of other open source free software to save money. Companies like Red Hat and Novell are making money by distributing Linux for free and charging for support. The model for free software is not to charge for the software but for the support or the training about the software. Venture Capitalists have invested more than US$ 3 billion in 163 open-source firms between 1997 and 2008. (Economist, 391, no. 8633 p. 69)

Having a free open source product can help a company to have a pull driven marketing approach in contrast to a push marketing approach that closed system companies have. (McInnis, G., 2009, p.81).

As a conclusion, it is evident that open standards with open source is totally different.  Open standards promote interoperability of systems. Open source promotes knowledge because the source code is exposed to everybody to see, learn and correct it. Giving open source software for free has many benefits both to the user and to the producer. The benefits for the producer are:

• Income from services
• Income from training
• Potential large user base (pull marketing)

The benefits for the users are:

• freedom,
• Security because the company has the source code and if the publisher of the software disappears they have the source to correct problems,
• Increased reliability, more eyes inspect the lines of code for errors.

References

Karen Coyle (2002).  “Open source, open standards. ” Information Technology and Libraries  21.1 (2002): 33-36. ProQuest Nursing & Allied Health Source, ProQuest.

McInnis, G.. Competitive actions of companies whose revenue relies on open source software.  Diss. Carleton University (Canada), 2009. Dissertations & Theses: Full Text, ProQuest.

Dave Welsh (2004). Distinguishing between Open Standards and Open Source — Part III of III Available from: http://blogs.msdn.com/dave_welsh/archive/2004/08/28/222206.aspx

Why do we use software prototypes?
As software engineers it is possible to use prototypes in order to be able to investigate concepts, visualize design options and help research alternative solutions for the problem on hand. A software prototype helps in many ways:

1. Having a prototype helps the elicitation of further system requirements. When customer stakeholders actually see a prototype, from experience, most of the times say that something is missing. This process is very helpful in validating system requirements.
2. User interface design is a key factor for the success of the software under developement. Presenting and collaborationg wirth end users using a UI prototype is a very nice way of producing widley accepted interfaces.
3. A prototype can be used in the testing process comparing it with the system to be delivered to the customer. That means, entering in both systems (prototype and application) the same data and compare the output results. If the results are identical then there is no fault detected. (Sommerville, 2006, p.409-410)

Although prototypes have great benefits for the software project, they hide some dangers. One major danger is to use a prototype and develop it further to a product. The prototype is for experiments and proof of concept. It has no “depth” or quality build in it.

Using a prototype can be viewed as a risk reduction process. This process may introduce new risks to the project if not handle carefully. Except the risk mentioned above there are also other risks involving the software prototype. The risks are:

1. The customer gets a wrong impression on the stage of development. Seeing a working prototype is confusing to him and thinks that the software is almost ready. It is of paramount importance not to let stakeholders to think of the prototype as an early version of the software system.
2. Users may confuse the hows of the user interface and not focus on what’s of the prototype. The prototype will be used to validate the requirements of the system and not how the system will look and how it will operate.
3. Users may believe that the prototype performance will be the end software product performance. It must made clear to customers that in the prototype are not any security features or optimized algorithms. A good habit is to use a delay timer to simulate the actual system response time.
   (Wiegers, 2003)

From personal experience I know that stakeholders confuse the prototype as an early version of the system. I was building hotel management software to handle the front office jobs of a hotel. I delivered a prototype to the customer soon after we had finalized the description of the software requirements. The prototype was to test what the menu navigation would be, what critical functions (reservations) the software will perform. After the demonstration of the prototype the customer refused to believe that it will take several months of development to finish the product. It took me several meetings with the customer to convince her that it was a prototype and not an early version of the software. Sometimes managing customer expectations can be very difficult.

As a conclusion software prototyping can reduce the ambiguity of functional requirements and shorten development schedules. We must include time in the project schedules for building several prototypes and state why we want to build them. (Wiegers, 2003)

From my experience even early prototyping screen mock-up on paper can help describe the requirements of a software project.

What software can be used to create prototypes?
I have used pencil sketching for Mozilla Firefox, I know that Adobe’s Dreamweaver can be used for fast prototyping. An idea is also to use Iron Speed designer. There are many more tools listed in Cunningham & Cunningham wiki.

References

Sommerville, I (2006). Software Engineering. Addison Wesley / Pearson 8th Edition. ISBN: 0321313798

Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press. ISBN: 9780735618794

1. known risks and
2. unknown risks.

For a project to be successful risk management should be done early in the project planning. The plan risk management should identify the risks, perform qualitative risk analysis, perform quantitative risk analysis and plan risk responses. Defining a Risk Breakdown Structure helps to identify project risks. Typical categories where risk might occur in a project are technical, external, organizational and project management.

Shenhar (3) discusses the technological uncertainty for four types of projects: Low-Tech (ex. road building), Medium-Tech (ex. Existing product improvement), High-Tech (ex. New systems) and Super High Tech (ex. the Hubble telescope). Ways to reduce uncertainty involved design cycles and design freeze.

There are mainly three categories of risks relating to software projects:

Project Risks which affect the availability of resources or the time constrains of the project. From experience I know that usually developers are very optimistic when setting deadlines. They do not anticipate difficulties that may occur in the development phase of the project. This easily creates a problem with time and completion of the project. It has also implications with the total cost of the project.

Product Risks which affect the performance, scalability or the quality of the software under development. Again, from experience I know that is totally different a design that supports a few hundred users to one that supports simultaneously thousands of users. Creating multithreaded code and introducing locks into the system to avoid race situations involving shared resources increases the complexity of the code and complicates the testing of software components. I have more than 20 years of programming experience and I have seen good and bad quality code. I have also seen code that was fully commented, not well documented having no bugs but it was unnecessary complicated. This type of code can be spotted only from experience and the cause of it is job protection. Programmers thought that by writing code the way they did they were protecting their jobs because no one else would be able to deeply understand the code. In my opinion quality of the code cannot be counted by bugs and bug fixes as many organizations practice but with internal and external (if possible by an independent consulting firm) code reviews.

Business Risks which affect the business itself. For example a change in technology that a system assumed.

To have a plan ready to respond to risks that might occur, can save the project depending on the severity of the risk. The risks that are worst are the ones that are unknown and have an unknown outcome. There are several strategies available to reduce or control the risks:

• Avoidance. Taking proactive actions to avoid the occurrence of that risk.
• Transference. Insurance or subcontracting.
• Mitigation. Reducing the risk to an acceptable level for the organization
• Acceptance. Identifying the risk but making no plans to mitigate or avoid the risk.
• Contingency planning. Having an alternative plan to follow if a risk occurs.
• Independent verification and validation. A third-party oversees the project.

As a conclusion the most certain thing about projects is that risk factors will occur in one form or the other. Reducing or controlling the risk is a task that is performed by a team.

From experience I know that is also important to take under consideration the external environment when devising risk plans. This post is an introduction to possible risks associated with software development projects. I will continue with more in depth postings on the subject.

References

1. Heldman, Kim (2005). Project Manager’s Spotlight on Risk Management. SYBEX
2. PMBOK(2008) A guide to the project management body of knowledge. PMI 4th edition.
3. Aaron J. Shenhar (2001) “One Size does not Fit All Projects: Exploring Classical Contingency Domains” Management Science, Vol. 47, No. 3 (Mar., 2001), pp. 394-414 INFORMS
4. Sommerville, I (2006). Software Engineering. Addison Wesley / Pearson 8th Edition.