Windows Server 2008

http://blogs.msdn.com/vijaysk/archive/2008/02/11/using-windows-server-2008-as-a-super-desktop-os.aspx

http://h0bbel.p0ggel.org/windows-server-2008-as-desktop-laptop-os

ShopEasy v1.1

I am happy to release this software for Windows mobile devices.

About ShopEasy v1.1:

Ever been to a super store, walked through all the isles and been back home just to find that you forgot to buy something? or simply don't have the memory to remember the long list of shopping items. Then this is for you.

ShopEasy is a software designed for Windows Mobile 6.1 devices and helps you to shop!

It helps you to maintain your shopping list in a simple and easy to use manner. Before you go shopping, just run the software, select them items you want to shop and away you go, never to forget an item. You can keep track of items as you buy using the software so that, you are never in doubt if you have bought it or not. 

Features:

1) Easy and Simple way to maintain your shopping list.

2) Help Facility for software.

3) Fast and efficient.

Specifications and Requirements:

Devices: Windows Mobile 6.1 devices. Screen shots from HTC Touch Diamond.

You will need: 1) Microsoft .Net Compact Frame work 3.5 to run the software. You can download this from Microsoft Website.

Your experience and suggestions in using ShopEasy are welcome. Enhancements will added and new versions will be uploaded soon.

Download:

v 1.1

-----

Link: http://www.filefactory.com/file/ahb4046/n/ShopEasyInstaller_CAB

To prototype or not to prototype

All engineering disciplines frequently use scaled down models to prove a concept before actually building something real or the real thing. This is the case, be it related to building architecture, bridges or aircraft manufacturing. So what about software? As an answer comes up the word, prototyping. The question is whether to or not to prototype? The question deserves special attention in software domain. This is due to the following reasons. First, software is created by developers who are unfortunately not the end-users of the product. Second, the end-user is not usually involved in specifying what they want, be it to see, type in or interact. In addition to that, the so called requirements get passed through quite a lot of hands and is perused and interpreted by the lot too. The funny thing is that, each will have an idea of what needs to be done, let alone how and with what. When this comes to the developer again there will be an interpretation of what is to be done. Finally, what the user wants is in his/her head and cannot be elicited in one go or so. The end result of this can be an unhappy user who thinks the software is useless or an irritated client who thinks the real objective was not met. For the developer this result can manifest as anything from, burning down new screens the user wants, dealing with the so called ‘changes’ to re-doing the whole thing.

If you have been in any of the above situation then you need to think of prototyping. First about what benefits it brings. Prototyping can help in the following ways

- If your team has thought of a concept which is core to building the solution. Prototyping can help in proving this concept. If the prototype proves your concept wrong, then you are in a position to plan accordingly rather than having to re-trace in the middle of development. It can also uncover any mistakes in your concept.

- You might have designed the solution with application layers and so on. Prototyping would be helpful in making sure things will get along as they were planned in the first place. If things do get along, you have something to look at when you build the real thing, a distinct advantage.

- It can help in comparing technologies that can be utilized to deliver a solution.

- You can identify bottle necks earlier which otherwise unnoticed will surface as impediments. i.e you make things as risk free as possible at an early stage.

- Above all, the user/client when presented with the prototype will start talking more than you expected. You will get a clear idea of ‘what they want to see’ and how they want to interact with the solution. I.e your interface will be change-proof as much as possible. There will be a better understanding between the two.

As for the downside of prototyping, besides the fact that it takes time, there is nothing horribly wrong with the idea at all. The problem stems from the fact that, not many people in the field understand the need to prototype and if they do, they lack the knowledge of how to prototype. The followers of the perfect world of waterfall model where things go in order or anything similar fall into this category.

In short, prototyping does help a software development team to move in the right direction based on facts and deliver what the user wants in the first go itself. i.e if you have not been able to deliver the right product in the first pass, you should think about prototyping.

Six Sigma and Software Development

The software domain has its own set of tools, concepts and management processes, techniques to ensure quality and the success of a project.  Some of these are development methodologies like Agile development and others are process management techniques like CMM and its process areas. But, Six Sigma, its ideas and concepts did not evoke an interest in Software engineering domain as it did to the manufacturing doamin. In fact, software engineers and IT project managers are still confused as to how and where to apply this concept and related tools in software 'product' development. 

At the end of its life cycle software is a product that, is used by a user/client to realise their goal. Quality, reduced variation from user requirements, reducing cost, well informed decisions, increased customer satisfaction are all important to the IT software industry as it to the manufacturing industry. These are things that Six Sigma aims for and the way to do this is even better in Six Sigma. If so, then software engineering and management can adopt quite a lot if not all, from this strategy. The initial skepticism can be removed by replacing the terms client/user (in Software domain) with customer (Six Sigma), issues (Software) with defects/variations (Six Sigma) and Software/System with product.  The only hurdle in the case of softwares is tangibility.  Again, 'Changes' are common to software development processes. Also, it is most unwelcome and software engineering processes tend to be brittle when it comes to managing changes. This is because most of the process models such as CMM tend to keep processes prognosticative. So they are uncomfortable with Changes. This 'Change' is also core to Six Sigma and But, is addressed very effectively.  In short, Six Sigma should not be alien to Software Engineering companies which in turn can definitely reap great benefits by applying this strategy.