Good Information regarding Agile Software Development from http://www.agile-process.org/

Agile Software Development: A gentle introduction

Computer science is a young science. Computer programmers my age were trained by engineers. That training dictated how we approached software development for an entire generation. But now after decades of building software to be expensive, unwanted, and unreliable we have come to realize software is different. Building software is more like creating a work of art, it requires creativity in design and ample craftsmanship to complete. Software remains malleable, often illogical, and incomplete forever. Agile software development is based on fundamental changes to what we considered essential to software development ten years ago. The most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile. We realize the way a team works together is far more important than any process. While a new process can easily improve team productivity by a fraction, enabling your team to work effectively as a cohesive unit can improve productivity by several times. Of course to be eligible for such a big improvement you must be working at a fraction of your potential now. Unfortunately, it isn't that uncommon. The most brilliant programmers alive working competitively in an ego-rich environment can’t get as much done as ordinary programmers working cooperatively as a self disciplined and self-organizing team. You need a process where team empowerment and collaboration thrive to reach your full potential. The second change is making the customer, the one who funds the software development, a valuable and essential team member. When the dead line gets close a traditional approach to reducing scope is to let the developers decide what will work properly and what won't. Instead let the customer make scope decisions a little at a time throughout the project. When your customer, or domain expert works directly with the development team everyone learns something new about the problem. True domain expertise and experience is essential to finding a simple, elegant, correct solution. A document can have plenty of information, but real knowledge is hard to put on paper. Left alone programmers must assume they know everything they need. When asking questions is difficult or slow the knowledge gap grows. The system will get built, but it won't solve the problem like one guided by an expert on a daily basis. Perhaps the biggest problem with software development is changing requirements. Agile processes accept the reality of change versus the hunt for complete, rigid specifications. There are domains where requirements can't change, but most projects have changing requirements. For most projects readily accepting changes can actually cost less than ensuring requirements will never change. We can produce working software starting with the first week of development so why not show it to the customer? We can learn so much more about the project requirements in the context of a working system. The changes we get this way are usually the most important to implement. Agile also means a fundamental change in how we manage our projects. If working software is what you will deliver then measure your progress by how much you have right now. We will change our management style to be based on getting working software done a little at a time. The documents we used to create as project milestones may still be useful, just not as a measure of progress. Instead of managing our activities and waiting till the project ends for software, we willmanage our requirements and demonstrate each new version to the customer. It is a hard change to make but it opens up new ways to develop software. Take a guided tour of Agile Development by following the  buttons starting here. Or continue your guided tour of Extreme Programming by following the  buttons. Let's look at how we manage by features next.

What is bespoke software??

I really wonder how I missed this term "bespoke software". May be some of you find this info useful.. Bespoke Software

ASP.NET 4.0 Videos

This series of short videos introduces you to the new features of ASP.NET 4.
http://www.asp.net/learn/aspnet-4-quick-hit-videos/

MOSS 2007 403 forbidden error after .net framework updates fail to install

After unsuccessfully trying to install .NET framework 3.0 or 3.5 on your MOSS 2007 front end server, users cannot access any of the SharePoint sites including central or shared services administration sites. Error in IE is 403 forbidden. Using a NON-IE browser, the error is Directory Listing Denied.

Open IIS Manager and go to Sites, then Properties, then Home Directory Tab, then Configuration, then in the Wildcard Application Maps box, add the aspnet_isapi.dll located in C:\windows\microsoft.net\"framework" or "framework64"\v2.xxxxx

Ensure that the checkbox "Verify that the file exists" is UNchecked, otherwise error 404 page not found  ill be displayed. This is because the data is rendered from the SQL database and not from IIS locally, and SharePoint will process this on the run while the site is being accessed.

Official Google Blog: Went Walkabout. Brought back Google Wave.

Official Google Blog: Went Walkabout. Brought back Google Wave.

PMP Tips: Point of total assumption

The point of total assumption (PTA) is a point on the cost line of the Profit-cost curve determined by the contract elements associated with a fixed price plus incentive-Firm Target (FPI)contract above which the seller effectively bears all the costs of a cost overrun. The seller bears all of the cost risk at PTA and beyond, due to a dollar for dollar decrease in profit beyond the costs at the PTA. In addition, once the costs on an FPI contract reach PTA, the maximum amount the buyer will pay is the ceiling price. Note, however, that between the cost at PTA and when the cost equals the ceiling price, the seller is still in a profitable position; only after costs exceed the ceiling price is the seller in a loss position.

Any FPI contract specifies a target cost, a target profit, a target price, a ceiling price, and one or more share ratios. The PTA is the difference between the ceiling and target prices, divided by the buyer's portion of the share ratio for that price range, plus the target cost.

PTA = ((Ceiling Price - Target Price)/buyer's Share Ratio) + Target Cost

For example, assume:

Target Cost:	2,000,000
Target Profit:	200,000
Target Price:	2,200,000
Ceiling Price:	2,450,000
Share Ratio:	80% buyer–20% seller for overruns, 50%–50% for underruns

PTA = ((2,450,000 - 2,200,000)/ 0.80) + 2,000,000 = 2,312,500.

If for a moment, PTA is given and you are trying to calculate the ceiling price for the buyer (maximum amout that the buyer will have to spend),the calculation will be

(2,000,000 (target cost) + 200,000 (the profit the buyer pays to the seller) + (2,312,500 - 2,000,000)*0.8 = 2450000.

This is a term used in project management when managing specific fixed price contracts.

For cost reimbursable contract, the Point of Total Assumption does not exist, since the buyer agrees to cover all costs. However, a similar incentive arrangement with similar components, called a Cost-Plus-Incentive_Fee (CPIF) contract sometimes is used. The CPIF includes both a minimum fee and a maximum fee. The share line in combination with the Target Fee, Maximum Fee and Minimum Fee can be used to easily calculate the points at which the incentive arrangement affects fee. The range between these points is called the "range of incentive effectiveness." Edited by oldPCO

For contracts subject to the Federal Acquisition Regulations, FAR 16.403-1 provides the Government description of FPI. The contract type is implemented by calling out FAR Clause 52.216-16 Incentive Price Revision - Firm Target. This clause captures the Ceiling Price as well as the government share ratio(s). If multiple line items are identified as FPI type, the individual line item information shall be included here, otherwise final contract costs and price are reconciled at the contract level.

The idea of a "Point of Total Assumption" is an extremely recent one, and even high-level government logistics specialists often don't know what the term means, or how to calculate it. In the government's efforts to cut cost overruns, however, the PTA is being introduced to FPIF contracts on an increasingly wide basis. Moreover, high-level professional examinations for industry certification, such as the Project Management Professional certification, are beginning to test applicants' knowledge of this concept and its application.

 

PMP Tips: Be Wary of Absolutes

You will find that the some answers to PMP or CAPM questions may contain absolutes such as always, completely or must. As you have studied for your exam you should have learned that in many cases project management is not clear cut. There are many factors to consider in each situation so an absolute in the answer should arouse your suspicions. Make sure that the absolute in the answer is appropriate for the answer you choose.

For instance, you may be given a hypothetical situation in which you as the project manager encounter a problem with scheduling. One of the choices might be that you must immediately inform management to ensure Real Time Issuers Disclosures. The use of an absolute might trigger a subconscious decision to choose that as the right answer, whether it is or not. When you see an absolute used in one of the answers be sure to think twice before choosing that answer. A PM must maintain his/her cool and avoid making snap decisions in a tight spot.

Many of the questions will also contain information that has no bearing on the problem posed. These are usually two paragraphs long and describe a scenario that might arise on a project. Rather than succinctly state the problem, you are given extraneous information that may make it difficult to ferret out the actual situation you're theoretically dealing with. Be careful to focus only on the facts of the case and not the noise surrounding it! These questions are not posed to frustrate you but to prepare you for the real world of project management where very few situations are crisp and clear.

Take many sample tests and/or collaborate with another candidate to create tests for each other. Seeing questions with such unnecessary information will prepare you for encountering them on the real exam and train your mind to focus on the problem and not the mitigating circumstances.

Thanks to Cornelius Fichtner of the PMPrepCast Fame for the above tips.