RAD - System i - Presentation

System i – Rapid Application Development
Rapid Application Development is a concept for developing new software systems and enhancing
existing systems in a much shorter delivery time than conventional methods. The methods used in this
structure involve prototyping, system analysis, and development methods that shorten delivery times.
Although these methods are usually referred to for Object Oriented platforms they apply to System i
development as well. Managers should be aware of these concepts to make the proper decisions for
their organization on development standards and processes. Developers need to understand the
development techniques to employ to meet the demands.
Presented by : Chuck Walker
The System Solutions Group, llc

Presentation Outline
Rapid Application Development is a term that became prominent in the Information Technology
industry in the mid 1990’s. The concept of RAD (Rapid Application Development) as it is defined
involves two aspects in the software development process.
1. Considerable changes in the SDLC (Software Development Life Cycle) that bypass much of the
time consuming aspects of conventional development practices in favor of a quicker turnaround and
release deployment on a shorter schedule.
2. Taking advantage of the development tools and concepts that help developers to develop
applications in a shorter time frame.
In this presentation we will overview the SDLC concepts and the Pros & Cons and tradeoffs involved.
But, the primary focus will be on the tools we currently have in our System-i environment and how to
structure our applications so we can best take advantage of reusable code and shorten our development
process considerably.
SDLC Concepts & Methodolgies
How RAD applies to System i
Overview of Historical RAD Development Models
Advantages of RAD Development Cycles
Disadvantages of RAD Development Cycles
System i Rapid Application Development Methods
Reusable Code with ILE Bound Service Programs
Structuring our Relational Database Management System to do a lot of the work
Using Embedded SQL to Develop Applications Faster
Using Stored Procedures for enforcing Business Rules
Using existing API’s

SDLC Concepts and Methodologies
How RAD Applies to System i :
Rapid Application Development (RAD) is a term that is typically referred to for what the industry calls Object
Oriented development platforms. These Object Oriented platforms would include Visual Basic, Visual C++,
JAVA, etc. It is said that is because the Object Oriented platforms promote writing reusable code.
The differences in the Software Development Life Cycle (SDLC) we will be discussing can apply to any
development platform. The methods of requirements gathering, shortened development cycles, and version
releases are not exclusive to any platform.
On the System i we use objects in our development process. We define display files, printer files, physical and
logical files, data areas, etc. We control much of the way these objects look and act by setting attributes.
While the System i is not called an Object Oriented platform it uses Objects in much the same way as those that
are.
Many of the so called Object Oriented platforms also use objects such as Data Readers, XML Readers, etc.
But in many cases the code to process these objects is anything but Rapid.
On the issue of developing applications that have reusable code and actually reusing code multiple times within
the application really depends on the developer and / or the company standards (if there are any) for development
practices. Writing reusable code is completely dependant on the developer.
We will be discussing some of the development methods we can use on the System i that may make development
time much shorter going forward.

Overview of Historical RAD Development Models :
In general terms the SDLC has been a very structured and deliberate process that involves taking
business needs and system capabilities and developing application concepts to support the business
needs. From there it is a matter detail planning and design, detail documentation, and approval of all of
the involved parties before a single line of code is written. This has historically been a long and tedious
process. For some companies it has become even more lengthy with the Sarbanes Oxley mandates.
The RAD methodology tries to shorten the life cycle by starting with a generic bare bones system and
delivering smaller scale enhancements on a shortened time table. The plan may be to deliver a new
release every couple of weeks, but no longer than 3 months. To accomplish this the scope of
enhancements for each release must be kept small enough to fit into this time table. As well the
planning and documentation process will need to be shorter. The theory is that a small system can be
delivered in about 20% of the time of a full blown complete system. Then you build on the smaller
system after it is in use to make it as robust as needed. It isn’t uncommon to have the next 2 or 3
releases being worked on at the same time. While the next release is in testing the following one may be
in development and the one after that may be in the prototype stage.
Structured Programming has been around since the 1960’s. The aim of this methodology was to
provide reusable code through the extensive use of subroutines as well as provide a more structured and
maintainable system through the use of structures such as Do Loops, Case structures, etc.
The Cap Gemini SDM Methodology
Cap Gemini SDM, or SDM2 (System Development Methodology) is a software development method
developed by the software company PANDATA in the Netherlands in 1970. The method is a waterfall
model divided in seven phases that have a clear start and end. Each phase delivers (sub)products, called
milestones.
The method uses 7 phases which are successively executed, like the waterfall model. The phases are:
1. Information planning (IP): Problem definition and initial plan
2. Definition study (DS): Requirements analysis and revised plan
3. Basic Design (BD): High level technical design and revised plan
4. Detailed Design (DD): Building the system (and revised plan)
5. Realization (R): Testing and acceptance (and revised plan)
6. Implementation (I): Installation, data conversion, and cut-over to production
7. Operation and Support (O & S): Delivery to ICT support department
http://en.wikipedia.org/wiki/Cap_Gemini_SDM

Structured Systems Analysis and Design Method (SSADM) (originally released as methodology) is a
systems approach to the analysis and design of information systems. SSADM was produced for the
Central Computer and Telecommunications Agency (now Office of Government Commerce), a UK
government office concerned with the use of technology in government, from 1980 onwards. This is
also a Waterfall type methodology.
http://en.wikipedia.org/wiki/Structured_systems_analysis_and_design_method
The waterfall model is the sequential development approach, in which development is seen as flowing
steadily downwards (like a waterfall) through the phases of requirements analysis, design,
implementation, testing (validation), integration, and maintenance. The first formal description of the
method is often cited as an article published by Winston W. Royce[3]
in 1970 although Royce did not use
the term "waterfall" in this article.
The basic principles are:
 Project is divided into sequential phases, with some overlap and splashback acceptable between
phases.
 Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire
system at one time.
 Tight control is maintained over the life of the project via extensive written documentation,
formal reviews, and approval/signoff by the user and information technology management
occurring at the end of most phases before beginning the next phase.
The Waterfall model is a traditional engineering approach applied to software engineering. It is the
model that has been used in traditional SDLC processes for decades. It has been widely blamed for
several large-scale government projects running over budget, over time and sometimes failing to deliver
on requirements due to the Big Design Up Front approach. Except when contractually required, the
Waterfall model has been largely superseded by more flexible and versatile methodologies developed
specifically for software development.
Although the Waterfall model is also used in many, if not most, of the RAD methodoligies the real
difference is the concept of an iterative development cycle.

http://en.wikipedia.org/wiki/Software_development_methodology#Waterfall_development

Software Prototyping is the development approach of activities during software development, the
creation of prototypes, i.e., incomplete versions of the software program being developed.
Not a standalone, complete development methodology, but rather an approach to handle selected parts of
a larger, more traditional development methodology (i.e. incremental, spiral, or rapid application
development (RAD)).
Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more
ease-of-change during the development process.
Users are involved throughout the development process, which increases the likelihood of user
acceptance of the final implementation.
Small-scale mock-ups of the system are developed following an iterative modification process until the
prototype evolves to meet the users’ requirements.
While most prototypes are developed with the expectation that they will be discarded, it is possible in
some cases to evolve from prototype to working system.
Screen and report mockups can usually be done with office tools such as MS Word. It’s fairly easy to
create a Word doc that resembles a green screen, a GUI screen, or a report. In the case of protyping
Web Applications I may simply save each Web page as an HTML doc and add links from one doc to
another, just to give a close visualization of the screen design flow and what the user will see once the
application is completed.
With most RAD methodologies JAD (Joint Application Development) is incorporated. This involves
brainstorming sessions including all of the business major stakeholders as well as the developers to
determine the requirements list. The first order of business must be to determine the initial functionality
in the original development iteration or the enhancement requirements for subsequent iterations.

Incremental development - Various methods are acceptable for combining linear and iterative systems
development methodologies, with the primary objective of each being to reduce inherent project risk by
breaking a project into smaller segments and providing more ease-of-change during the development
process.
A series of mini-Waterfalls are performed, where all phases of the Waterfall are completed for a small
part of a system, before proceeding to the next increment, or iteration.
Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of
individual increments of a system, or
The initial software concept, requirements analysis, and design of architecture and system core are
defined via Waterfall, followed by iterative Prototyping, which culminates in installing the final
prototype, a working system.
The spiral Development model is a software development process combining elements of both design
and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. It is
a meta-model, a model that can be used by other models.
Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments
and providing more ease-of-change during the development process, as well as providing the
opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle.
"Each cycle involves a progression through the same sequence of steps, for each part of the product and
for each of its levels of elaboration, from an overall concept-of-operation document down to the coding
of each individual program."
Each trip around the spiral traverses four basic quadrants:
(1) determine objectives, alternatives, and constraints of the iteration
(2) evaluate alternatives; Identify and resolve risks
(3) develop and verify deliverables from the iteration
(4) plan the next iteration
Begin each cycle with an identification of stakeholders and their needs for the iteration, and end each
cycle with review and commitment. Although there are four milestones in each iteration listed above
each one of the four quadrants will likely have a mini waterfall structure within it.

SCRUM and AGILE / SCRUM Methodoligies :
The SCRUM Methodology has increased in popularity over the last 15 years. The Wikipedia website
It has a pretty good outline of SCRUM. It says : Scrum is an iterative and incremental agile software
development framework for managing product development. It defines "a flexible, holistic product
development strategy where a development team works as a unit to reach a common goal", challenges
assumptions of the "traditional, sequential approach" to product development, and enables teams to self-
organize by encouraging physical co-location or close online collaboration of all team members, as well
as daily face-to-face communication among all team members and disciplines in the project.
SCRUM defines specific roles of Product Owner, Development Team, and SCRUM Master. It also
defines specific events of Sprint, Meetings, and Extensions. Certain considerations are laid out for the
Product Owner and SCRUM Master such as Sprint Backlog, Product Increment Sprint Burndown Chart,
and Release Burndown Chart.
Another good place to get the details of the SCRUM Methodology is http://scrummethodology.com/ .
This site has some very good documentation in the SCRUM Reference Card as well as The SCRUM
Master Check List.
Some Major companies are using the SCRUM Methodology for maintenance programming such as bug
fixes and minor enhancements to existing programs while using Waterfall methods for new development
projects.
Scrum-ban is a software production model especially geared towards maintenance projects or (system)
projects with frequent and unexpected work items or programming errors.
Other Specific software development methodology frameworks include:
 Rational Unified Process (RUP, IBM) since 1998.
 Agile Unified Process (AUP) since 2005 by Scott Ambler

Advantages of RAD Development Cycles
RAD methodology enables quick development of software products by using Computer Aided Software
Engineering (CASE) tools, in combination with methods of iterative development and rapid prototyping.
It aims at reducing the time involved in the planning phase. It drastically reduces the time required for
software development, usually taking somewhere between 30 to 90 days for the complete development
life cycle. RAD is a combination of a well-defined methodology, dedicated and trained staff, and proper
and efficient management practices. Such a fast-paced approach, may, at times, come with its own set of
compromises in terms of product features and scalability. However, the advantages of rapid application
development greatly surpass these few drawbacks.
Disadvantages of RAD Development Cycles
The RAD Methodologies promote and use the Software Prototyping process. In a nutshell that includes
brainstorming type sessions that includes software developers and users from all business interests that
have a stake in the process. The theory is that issues may be raised by users from different departments
of the company that may be relevant to developing a successful application that satisfies the business
needs. It also insures that the different business users are more likely to signoff on the end product since
they have been involved in the development process and have ownership in it.
The downfall of this type of situation can be that it turns into a free-for-all for any and all concerns
throughout the parties included and the scope of the current project is forgotten or changed. It requires a
Project Manager or Team Leader that can keep the group focused on the current scope of the next
release. Without that the developers may leave the session with a longer list of questions to get resolved
before development than they walked into the session with. The result is obviously that the Prototyping
process is extended well beyond the planned time frame. As a result of that the development process
will be extended as well.
The developers developing the applications and writing the code for these systems need to have a good
understanding of the business, or at least the assistance of a developer or project manager that does.
Otherwise critical functions within the application may be left out because the programmer simply
didn’t know that they needed to be included. The users and senior developers may know some things by
nature that a novice in the particular industry may not. This could result in the final product being
unusable or requiring a rewrite to make it functional.
Because the documentation in a RAD environment is less detailed and in some cases completed after
development the developers knowledge of the industry and business are even more critical. Many IT
managers are uncomfortable as well if they don’t have a stack of documentation several inches thick
before continuing with the project.

System i Rapid Application Development Methods
There are a number of IDE’s (Interactive Development Environments) on the market, such as Rational, and Agile
that tend to make the development process a little smoother and saves development time. Aside from these
development tools we can also save ourselves development time if we structure our applications to incorporate
many of the other basic tools built into the system.
Reusable Code with ILE Bound Service Programs
I prefer to build service programs as a library of useful functions geared toward a particular section of the system.
Many businesses will have an AR System (Accounts Receivables), an AP System (Accounts Payables), a GL
System (General Ledger), maybe an Inventory Control System, etc.
Let’s talk for a minute about designing a service program for common AR functions. We might start with just a
few functions such as :
RtvCreditStatus that returns the credit status (On Credit Hold or not) based on the Customer Number.
Another might be RtvCurrBalance that returns the Customer’s current outstanding balance.
Another could be RtvTermsCode to return the customer’s terms code (Collect, Net 30, Net 60, etc).
Another might be RtvTermsDesc to return the Terms Code Description for the terms code.
Let’s say we’re working on an Order Entry program and this data needs to be displayed on the screen so the
customer service rep has it handy. Our code for loading these values to the screen fields might look something
like this :
ScrCeditStatus = RtvCreditStatus(CusNum)
ScrCurrBal = RtvCurrBalance(CusNum)
ScrTermsCd = RtvTermsCode(CusNum)
ScrTermsDesc = RtvTermsDesc(ScrTermsCd)
Notice how short and concise this is opposed to having to chain to the Customer Master file, maybe an AR
Transaction file, and a terms code definition table. Development time may take a couple of minutes to get the
values to be displayed instead of an hour.
Once a service program is established it is then available to any program you want to bind it into. The same
common AR functions may be useful in an AR Payment Entry program, AR Ageing routines and reports, etc.
This is also a good place to put in complex calculation functions such as a price calculator so that you don’t have
to copy or rewrite those calculations all the time. The other advantage is that when modifications are needed to
those calculations it only has to be done in one place.
Although it may take a little upfront time investment to establish these kind of service programs if you start out
small and build on them as needed the initial time investment will be small also.
You will be surprised how much faster you can develop programs when this sort of structure is already in place.

Structuring our Relational Database Management System to do a lot of the work
There are a number of ways we can use the functionality available in our Relational Data Base that can save us
from having to put extensive edits in our RPG programs.
Defining Physical and Logical files with DDL instead of DDS
Most programmers wouldn’t think that this will shorten development time but it will likely save plenty of
debugging time later just because of the data validation differences. Data validation for a DDL defined file takes
place at the time a record is written or updated rather than on the Read. It may even seem to be a hassle at first to
chase down where invalid data is trying to be written to a file column. But that is a lot easier than spending hours
or possibly days to straighten out data files that have been corrupted with invalid data. And just think, no more
Data Decimal Errors.
Write
Passed
Read
Failed
Read
Passed
Write
Failed
DDS
PF
Data
Validation Application
Program
Exception Error
DDL
Table
Data
Validation
Application
Program
Exception Error

Referential Integrity
Referential integrity is a fundamental principle of database theory and arises from the notion that a
database should not only store data, but should also actively seek to ensure its quality. Referential
integrity is a database constraint that ensures that references between data are indeed valid and intact.
Referential integrity is usually enforced by the combination of a primary key and a foreign key.
It ensures that every foreign key matches a primary key.
Below is a graphic showing the logical relationships between four different tables.
Referential Integrity is an example of how we can use the built in database functions instead of
traditional editing routines to validate data. We can use a File Information Data Structure to determine
if Referential Integrity rules are being violated.
As you can see in the example below the chain function that would normally be used in the editing
function can be left out by simply testing the status code after an insert attempt.
Item Master
Item Number
Item Description
Vendor ID
Item Category
Item Cost
Item Price
Status Code
Reorder Level
Order Detail
Order Number
Line Number
Item Number
Qty Ordered
Unit Price
Extended Price
Line Status Code
Order Header
Order Number
Customer Number
PO Number
Order Date
Ship Date
Order Amount
Customer Master
Customer Number
Customer Name
Status Code
Credit Limit
Street Address
City
State
Zip Code

*========================================================*
* File definition used for insert. *
*========================================================*
FEMPDSP CF E WORKSTN
FEMPLOYEE O E K DISK RENAME(EMPLOYEE:EMPFMT)
F INFDS(FDBF)
*========================================================*
* The file information data structure will be used *
* to determine if the referential restrict rule is *
* violated. *
*========================================================*
DFDBF DS
D STATUS *STATUS
D MSGID 46 52A
*========================================================*
* Get a new employee record from the display. *
* Loop until the department is valid. *
*========================================================*
C MOVE *ON *IN61
C DOW *IN61
C EXFMT A
*========================================================*
* Write to the EMPLOYEE file. Referential integrity will *
* check to see if a department for the employee exists *
* If it does not, return a message to the screen. *
* In V3R6, this same technique can be used to detect a *
* trigger error via 01023 (*BEFORE) or 01024 (*AFTER) *
*========================================================*
C WRITE EMPFMT 61
C STATUS IFEQ 1022
C MOVE *ON *IN60
C ELSE
C MOVE *OFF *IN60
C ENDIF
C ENDDO
*
C RETURN
http://www-03.ibm.com/systems/i/software/db2/ri02.html
*IN61 is on if
the Write fails
*IN60
displays an
error message

Database Triggers
There is a multitude of uses for trigger programs. Let’s say we are working in an industry that uses a lot
of EDI communications. Many of your customers may require an ASN (Advanced Shipping Notice) to
be sent within an hour of shipment.
A trigger could be setup whenever an order is marked as shipped to see if the customer should be sent an
ASN and write a record to a table of ASN’s to be generated. A scheduled job could run each hour to
read through these records and send the ASN’s.
Another example might be the need for an Audit Trail whenever inventory levels are changed. A trigger
could be executed whenever the values in the Item Balance file is changed to log the changes. The
trigger alone would handle inventory adjustments, inventory receipts, customer returns, order shipments,
etc without adding code to all of these transaction programs.
Once a trigger program is established to handle certain events it doesn’t matter what program generates
the event, the Database will take care of it.
DB2 Sequence Objects
A sequence is an object that generates a sequence of numeric values according to the specification with which the
sequence was created. Sequences, unlike identity columns or row ID columns, are not associated with tables.
Applications refer to a sequence object to get its current or next value.
Example :
INSERT INTO ORDERS (ORDERNO, CUSTNO)
VALUES (NEXT VALUE FOR ORDER_SEQ, CUSTNO);
The NEXT VALUE expression in the INSERT statement generates a sequence number value for the sequence
object ORDER_SEQ.
So, when using a Sequence object for an order number instead of a data area all that needs to be done in a SQL
Insert statement is a NEXT VALUE clause referring to the Sequence Object in the Values clause of the Insert
statement.
Historically we have used Data Area values to store the last number used, increment it by one, and update the data
area. Although it’s not a great deal of code to do this it’s obvious that using the NEXT clause in an Insert
statement is less code.

Using Embedded SQL to Develop Applications Faster
One of the primary advantages of using embedded SQL within our RPG programs is the shortened
development cycle when database changes are necessary. Because no F Specs are needed when using embedded
SQL then no level check errors occur.
If we are using SQL within our programs and we are field level specific in our programs then we only
have to recompile the programs that need to use the new fields. The others will still function as designed
without recompiling. If you are lengthening a field you would only need to recompile the programs that
use that specific field. By being field level specific I mean actually spelling out the field names in the
SQL statements. Example : Select CusNo, CusName, CusStatus, CusAdd1, CusAdd2, CusCity,
CusState, CusZip from CUSMAST. If you use Select * from CUSMAST then you will still likely need
to recompile all programs that use this method.
This can significantly reduce the amount of time development and deployment takes and therefore reduce the
development time.
You may also sort record sets dynamically without the need for a new logical and join files without a join logical.
This can cut down development time considerably in situations where these options are needed.

Using Stored Procedures for enforcing Business Rules
Whenever possible Stored Procedures should be used to Insert. Update, or Delete records.
If all of your application programs use the same stored procedures for these functions then the obvious
place to enforce business rules restrictions is in the stored procedure.
If your applications are structured in this manner then there is only one place to make changes to your
business rules logic when needed.
The reason a Stored Procedure should be used is that it can be called from any platform (Web, Windows,
etc) as well as a static call from an RPG program.
So many of our companies rely on multiple platforms these days. It’s not uncommon to have green
screen order entry program as well as a web application for customers to order on line. Some companies
even have web applications for in house use by their customer service staff. Orders could be coming in
through EDI as well.
Instead of embedding the business rules within the code for each application a far more efficient process
would be to run all orders through one pipeline.
Let’s refer back to the example we used in the Bound Service Program section. A Service Program
cannot be registered as a Stored Procedure. Therefore the functions within the Service Program are not
available as Stored Procedure calls. But we can access bound functions through a registered Stored
Procedure.
So, if we already have the functions needed in service programs writing an External Stored Procedure to
execute a Service Program function to retrieve or calculate values and return them to the calling
application is a short and easy process.
Order Entry
Manual Input
Telephone Sales
Incoming
Order – Web
Application
Stored Procedure
Order validation
/ post
Order
Header
Table
Order
Detail
TableIncoming
Order
EDI Order

Using existing API’s
IBM currently supplies over 2,500 API’s. Many of these perform common functions that can save us the
time of writing the code ourselves. No need to reinvent the wheel if it’s already been done.
One obvious example is the REGEXEC() Function is used to validate a regular expression or
value based on a predetermined pattern. This function can be used to verify the format of e-mail
addresses, zip codes, credit card numbers, and more.
Most of our Customer / Member profile maintenance programs require at least a couple of these
values to be entered by a customer or a customer service representative. We could try to write
the code to validate the format of the data entered or we could just use the REGEXEC ()
Function to do it for us.
http://www.experts-exchange.com/Programming/System/Unix_-_Posix/Q_10013138.html
Another example, although not needed as often, is the CEERAN0 function that returns a random
number within a number range. We could write code to do this but it’s very tedious and time
consuming. This is particularly helpful if you have to select employees for random drug testing
or select employees / customers for random prize awards. It’s like picking a piece of paper out
of a hat with your program.
http://comments.gmane.org/gmane.comp.hardware.ibm.midrange/9183
If you get familiar with the API’s available you could save yourself a lot of coding time in the
future by simply spending a few minutes to see if there is an API that will do the job for you.
IBM provides an API Finder at the following web site.
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp

On The CD
Type Name Description
PDF RAD System i -
Presentation
A copy of this presentation in PDF format.
PDF DB2 for i5 OS - SQL
Reference V5R4
An IBM published SQL Reference for iseries SQL. V5 R4
PDF Advanced_Database
functions and
administration on DB2
UDB_for iSeries
This IBM Redbook covers some of the more advanced functions of
database administration such as Referential Integrity and other
constraints, data import and export, and commitment control. It
also goes into detail on the IBM tools available for these tasks.
PDF DB2 UDB SQL
Programming – V5R3
This IBM publication covers in detail the iSeries server
implementation of the Structured Query Language (SQL) using
DB2 UDB for iSeries and the DB2 UDB Query Manager and SQL
Development Kit Version 5 licensed program.
PDF System i Database
Programming - V5R4
This Publication covers all aspects of database programming
including Triggers, UDFs, and Referential Integrity.
PDF DB2-StoredProcedures-
Triggers-UDFs
This IBM Redbook Publication covers the concepts and details of
Stotred Procedures, DB2 Triggers, and UDFs (User Defined
Functions).

Helpful Links
Link Description
http://en.wikipedia.org/wiki/Cap_Gemini_SDM Wikipedia web site that concentrates on the Software
Development methodologies
http://en.wikipedia.org/wiki/Structured_systems_analysis_and_design_m
ethod
Wikipedia site that outlines the details of the Structured
systems analysis and design method (SSADM).
http://en.wikipedia.org/wiki/Waterfall_model Wikipedia subject site that discusses the Waterfall Model
concepts.
http://en.wikipedia.org/wiki/Agile_software_development#External_links Wikipedia site that discusses Agile and it’s concepts as well as
external resources from Database Modeling through
deployment.
http://en.wikipedia.org/wiki/Rational_Unified_Process Wikipedia site that discusses IBM Rational process and it’s
concepts as well as external resources from Database Modeling
through deployment.

RAD - System i - Presentation

More Related Content

What's hot

Similar to RAD - System i - Presentation

RAD - System i - Presentation