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.

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”

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”