Category: RUP

Rational Unified Process

IBM’s development process best practices

IBM is a company with RUP best practices. Its VP talks about developers productivity and more…

IBM has plenty of application development tools at its disposal, including those from its own Rational Software line and Rational Unified Process. But tooling and process can only go so far to assure code quality. System scores application developers based on the volume and quality of their work. Today we representing the interview with IBM’s VP at global business services division Pat Howard.

SoftElegance is a company with RUP as a core software development process and we are attended at Rational Unified Process best practices, news, and useful facts.

IBM RUP logo

Pat Howard led application development at IBM, where he was responsible for delivering applications across all of Big Blue’s brands and overseeing its global development teams. On the talent front, he helped implement a system for analyzing individual application developers based on the volume and quality of their work.

Continue reading “IBM’s development process best practices”

Rational Unified Process Core Workflows: Project Management and Change Management

The Rational Unified Process® is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.

Rational Software Logo

“RUP Core Workflows: Project Management and Change Management.” is the next post from series Rational Unified Process Core Workflows.

Continue reading “Rational Unified Process Core Workflows: Project Management and Change Management”

Rational Unified Process Core Workflows: Implementation, Testing, Deployment.

The Rational Unified Process® is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.

Rational Software Logo

A mere enumeration of all workers, activities and artifacts does not quite constitute a process. We need a way to describe meaningful sequences of activities that produce some valuable result, and to show interactions between workers.

A workflow is a sequence of activities that produces a result of observable value.

Continue reading “Rational Unified Process Core Workflows: Implementation, Testing, Deployment.”

Using RUP for reengineering projects

The goal of a reengineering project is to restructure a legacy software system so that some of its quality attributes are improved. This restructuring could imply a change in the technological framework, such as a migration to an SOA framework. Whatever the technology, the reverse-engineering project should assess the feasibility of the restructuring. In fact, even if the target of the reverse-engineering is to remodel a system, it must also prototype the migration of some key component to the new architecture to check that it is possible.
Continue reading “Using RUP for reengineering projects”

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 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”

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”

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”