Month: April 2010

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”

RUP artefacts in a context of phases

Software development process according to the Rational Unified Process is broken intro phases. Each phase has a cycles, each cycle working on a new generation of the product. The results in a cycle in general calls artifacts.

Summary description of the possible artifacts after each phase and evaluation criteria are represented.

Inception Phase

Typical artifacts that could be produced:

• A vision document: a general vision of the core project’s requirements, key features, and main constraints.

• A initial use-case model, 10% -20% complete.

• A business model, if necessary.

Continue reading “RUP artefacts in a context of phases”

What’s new in .NET Framework 4.0 for business?

Of course new .NET Framework 4.0 has features that could be used by developers mostly.
In general for business .NET 4.0 Framework main focus is on performance and security improvement.
There are some features that could be useful for end users, development enterprise and business application, business application design and architecture.

– Memory-Mapped Files.
The .NET Framework now supports memory-mapped files. Developers can use memory-mapped files to edit very large files and to create shared memory for interprocess communication.

– 64-Bit Operating Systems and Processes.
Developers can identify 64-bit operating systems and processes. This will increase performance of both server and desktop side application.

– Client Profile.
Main features is integration with MS Office applications. All Office 2007 and Office 2010 project templates.

– Integrated Windows Authentication.
A lot of existing troubles with authentication could be solver.

– Networking performance.
Support for Network Address Translation (NAT) traversal using IPv6 and Teredo.

– Windows Workflow Foundation
This tools could be used for UML modeling. It could help software architects to design business architecture and describe business logic.
The main feature is Workflow Activity Model also known as ‘Activity diagram’ with rich composite activity options and Built-In Activity Library.

Continue reading “What’s new in .NET Framework 4.0 for business?”

Rational Unified Process Core Workflows: Business Modeling

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;

Business Modelling

One of the major problems with most business engineering efforts, is that the software engineering and the business engineering community [1] do not communicate properly with each other. This leads to the output from business engineering is not being used properly as input to the software development effort. The Rational Unified Process addresses this by providing a common language and process for both communities, as well as showing how to create and maintain direct traceability between business and software models.

In Business Modeling we document business processes using so called business use cases. This assures a common understanding among all stakeholders of what business process needs to be supported in the organization. The business use cases are analyzed to understand how the business should support the business processes. This is documented in a business object model. Many projects may not to do business modeling.
Continue reading “Rational Unified Process Core Workflows: Business Modeling”

Mapping XP phases in to RUP model

General XP’s phases are exploration, commitment and steering. At the release level, these align with particular collections of activities, called workflow details in the RUP Project Management discipline.
Exploration and Commitment phases could be mapped into the Plan for Next Iteration and Steering could be mapped into Monitor and Control Project phase.

In Extreme Programming by Kent Beck, there is a lifecycle of an ideal XP project, and the first level headings are exploration, planning, iterations to first release, ‘productionizing’, maintenance and death . These appear to be the top-level phases, but it turns out this is not quite accurate. An XP project will be bounded by an initial exploratory phase and “death” when the project is closed out. But the major beat is the release and each release has an exploration phase . So the exploration phase that brackets the project (and leads into the first release) is a special case in that there is an initial gate to pass at which a decision is made on the wisdom of continuing at all. Both XP releases and iterations have the three phases exploration, commitment, and steering. “Maintenance” really characterizes the nature of the XP project after the first release.
Continue reading “Mapping XP phases in to RUP model”

Subcontracting in the RUP Scope

The Subcontracting Scenario Concept

We can define typical scenarios to understand the multiple subcontracting strategies based on the Rational process. Each scenario has a remarkable characteristic that predominates in the set, and many other secondary characteristics that result from the first one. A real project case can use more than one scenario to represent its problem.

The main characteristic of a scenario is to define what point, in the development process, the contracting organization wants to reach. In other words, which software models the contracting party wants to produce internally. This subset of models can give it internal communication security, control over the problem, and is probably already part of the developer and manage experience. The immediate implication in terms of RUP is to ask which artifacts the contracting party will it execute and which ones will purchase from third parties. This can be said in a different manner: based on which model (Artifact) does the contracting party want to contract service execution?

Continue reading “Subcontracting in the RUP Scope”