July 2008 Archives
COnstructive COst MOdel II (COCOMO II) is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity. COCOMO II is the latest major extension to the original COCOMO (COCOMO 81) model published in 1981. It consists of three submodels, each one offering increased fidelity the further along one is in the project planning and design process. Listed in increasing fidelity, these submodels are called the Applications Composition, Early Design, and Post-architecture models.
COCOMO II can be used for the following major decision situations
- Making investment or other financial decisions involving a software development effort
- Setting project budgets and schedules as a basis for planning and control
- Deciding on or negotiating tradeoffs among software cost, schedule, functionality, performance or quality factors
- Making software cost and schedule risk management decisions
- Deciding which parts of a software system to develop, reuse, lease, or purchase
- Making legacy software inventory decisions: what parts to modify, phase out, outsource, etc
- Setting mixed investment strategies to improve organization’s software capability, via reuse, tools, process maturity, outsourcing, etc
- Deciding how to implement a process improvement strategy, such as that provided in the SEI CMM
The original COCOMO model was first published by Dr. Barry Boehm in 1981, and reflected the software development practices of the day. In the ensuing decade and a half, software development techniques changed dramatically. These changes included a move away from mainframe overnight batch processing to desktop-based real-time turnaround; a greatly increased emphasis on reusing existing software and building new systems using off-the-shelf software components; and spending as much effort to design and manage the software development process as was once spent creating the software product.
These changes and others began to make applying the original COCOMO model problematic. The solution to the problem was to reinvent the model for the 1990s. After several years and the combined efforts of USC-CSSE, ISR at UC Irvine, and the COCOMO II Project Affiliate Organizations, the result is COCOMO II, a revised cost estimation model reflecting the changes in professional software development practice that have come about since the 1970s. This new, improved COCOMO is now ready to assist professional software cost estimators for many years to come.
�Today, I ran across a new Knowledge Base article, 940791, which described a set of symptoms that were a perfect match for mine:
You install an automatic update for Microsoft Office Word 2007 on a Windows Vista-based computer. Additionally, the computer must be restarted after the automatic update is installed. However, if Word 2007 is running when you restart the computer, you may experience the following symptoms:
- The mouse does not work when you use Word 2007.
- You cannot open a Word document from the Search window in Windows Vista.
- You cannot open a Word document from Windows Desktop Search.
- Word crashes when you try to start or to exit Word.
The fix is fairly simple, As explained in the original article, just delete the following Registry subkey:
The primary goal of the Handbook of Software Architecture is to fill this void in software engineering by codifying the architecture of a large collection of interesting software-intensive systems, presenting them in a manner that exposes their essential patterns and that permits comparisons across domains and architectural styles. Reflecting on his work on patterns, Christopher Alexander notes that he and his colleagues “made observations, looked to see what worked, studied it, tried to distill out the essentials, and wrote them down12.” This approach is at the core of all good science.
The second goal of this work is to study these architectural patterns in the context of the engineering forces that shaped them and then to expose a set of proven architectural patterns that may be used to construct new systems or to reason about legacy ones.
The third goal of this work is to feed my insatiable curiosity. Whenever I encounter an interesting or useful software-intensive system, I often ask myself, “how did they do that?” By exposing the inner beauty of these systems through a study of their architectural patterns, I hope to offer inspiration to developers who want to build upon the experience of other well-engineered systems.
software development project management
the new experimental developer toolset, Volta that allows developers to build standards-conformant, multi-tier web applications using established .NET languages, libraries and development tools.
“Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.”