Windows Azure. The new cloud platform from Microsoft

Microsoft’s Windows Azure Platform is a cloud computing platform offering that “provides a wide range of Internet services that can be consumed from both on-premises environments or the Internet”. That’s what the official Azure’s website says. And we see that Microsoft is moving to cloud computing like Google Apps, Amazon, SalesForce and some other already does. Azure is a PaaS or “Platform as a Service” and it used to be free to use but now (starts from June 28 there is some additional charges for computing time, storage and data transferring).

Some words about cloud computing. Cloud computing is Internet-based computing, whereby shared resources, software and information, are provided to computers and other devices on-demand, like the electricity grid. Cloud computing layers could describe this architecture the best and shows the difference from client-server (client – application server – server) architecture. Cloud computing layers are:

Continue reading “Windows Azure. The new cloud platform from Microsoft”

.NET Framework review. Basic design features

In this entry will be described .NET Framework principal design features. Brief description to get quick overview of .NET basic design.

Portability
The design of the .NET Framework allows it to theoretically be platform agnostic, and thus cross-platform compatible. That is, a program written to use the framework should run without change on any type of system for which the framework is implemented. While Microsoft has never implemented the full framework on any system except Microsoft Windows, the framework is engineered to be platform agnostic, and cross-platform implementations are available for other operating systems (see Silverlight and the Alternative implementations section below). Microsoft submitted the specifications for the Common Language Infrastructure (which includes the core class libraries, Common Type System, and the Common Intermediate Language), the C# language, and the C++/CLI language to both ECMA (Ecma International is an international, private (membership-based) non-profit standards organization for information and communication systems) and the ISO (International Organization for Standardization), making them available as open standards. This makes it possible for third parties to create compatible implementations of the framework and its languages on other platforms.

Continue reading “.NET Framework review. Basic design features”

Is there an XP equivalent of RUP’s activities?

Yes there is, but XP’s “activities” are not formally identified or described. you’ll find it headed “Define requirements with stories, written on cards” and then throughout the chapter is a mixture of process description and guidance about what use stories are and how (and by whom) they should be produced. And so it goes on, as the books describe XP under major headings; “things done” and “things produced” are described with varying degrees of prescription and detail. RUP’s apparent prescription comes from its completeness and greater formality in its systematic treatment of activities, and their inputs and outputs. XP does not lack prescription, but perhaps in the attempt to remain “lightweight”, the formality and detail are simply omitted. The detail that is present in RUP will have to be added when XP is implemented on a project. Lack of specificity is not a strength or a weakness, but you should not confuse the lack of detailed information in XP with simplicity. At some point, the people on the project will need to know what to do and at that time will need the detail.
Continue reading “Is there an XP equivalent of RUP’s activities?”

Rational Unified Process Core Workflows: Requirements, Analysis & Design

Rational Unified Process Core Workflows: Business Modeling

Based on Rational Software White Paper “Best Practices for Software Development Teams”

The core process workflows in RUP are divided into six core “engineering” workflows:

  • Business modelling workflow;

  • Requirements workflow;

  • Analysis & Design workflow;

  • Implementation workflow;

  • Test workflow;

  • Deployment workflow;

Requirements

The goal of the Requirements workflow is to describe what the system should do and allows the developers and the customer to agree on that description. To achieve this, we elicit, organize, and document required functionality and constraints; track and document tradeoffs and decisions.

Continue reading “Rational Unified Process Core Workflows: Requirements, Analysis & Design”

RUP vs XP. Why doesn’t XP need all of the RUP artifacts?

One reason is that XP doesn’t have the scope of RUP. This is quite intentional: XP is about programming to meet a business need. How that business need occurred and how it’s modeled, captured, and reasoned about is not XP’s main concern. The XP team member who is the customer presents the distillation of requirements as stories to the XP development team;
they are also the arbiters of business value. The magic of how the stories came to be expressed (or expressible) in that form is not the concern of XP. So, for example, what RUP describes in its Business Modeling discipline is outside the scope of XP (Business Modeling in RUP has ~14 artifacts). XP describes a process that has regular releases to the customer. The logistics of deployment of these releases are not the concern of development,
so the RUP Deployment discipline is largely outside the scope of XP (Deployment in RUP has ~9 artifacts). Therefore, for a small project amenable to XP, you would expect to omit ~23 artifacts when tailoring RUP.

Continue reading “RUP vs XP. Why doesn’t XP need all of the RUP artifacts?”

RUP for a small and medium size projects and teams

In the begining we would like to specify what is small and medium size project:

  • Small project: Has a budget of less than $100,000, a team size less than six, including team members who can be switched between this project and others on a daily basis, and a duration of less than six months.
  • Medium project: Has a budget of $100,000-$500,000, a team size of six to twelve, and a duration of six months to two years.
  • Large project: Has a budget over $500,000, a team size of thirteen or greater, and a duration of more than 2 years.

There seem to be two currents that push this “RUP doesn’t know small projects” perception:

Continue reading “RUP for a small and medium size projects and teams”

Key principles for business-driven development

From The Rational Edge: As a major update of IBM Rational’s six best practices for software development, this summary description articulates a new set of principles that characterize a mature approach to the creation, deployment, and evolution of software-intensive systems.

Continue reading “Key principles for business-driven development”

Rational Unified Process Best Practices

The RUP describes how to effectively deploy commercially proven approaches to software development for software development teams. These are called “best practices” not so much because you can precisely quantify their value, but rather, because they are observed to be commonly used in industry by successful organizations. The Rational Unified Process provides each team member with the guidelines, templates and tool mentors necessary for the entire team to take full advantage of among others the following best practices:

1. Develop software iteratively;
2. Manage requirements;
3. Use component-based architectures;
4. Visually model software;
5. Verify software quality;
6. Control changes to software.

Continue reading “Rational Unified Process Best Practices”

Upstream IT Reference Architecture and RUP Software Development

Today’s oil and gas industry needs a common IT reference architecture for use by upstream organizations, system integrators (Sis), solution providers and software development companies.

A single architectural approach will encourage simplification and unification in the upstream sector. It will also give Sis, solution providers and software development companies an established environment within which to design and build solutions, while allowing upstream operators to design architectures as a requirement for potential vendors.

The oil and gas IT community is now adopting Service-Oriented Architectures (SOA) as a more flexible and responsive alternative to traditional hard connections between applications and source data.

Continue reading “Upstream IT Reference Architecture and RUP Software Development”