The document outlines the Rapid Portal Methodology (RPM) for rapid software development. RPM is based on the Rational Unified Process (RUP) and comprises best practices layered on top of RUP. The methodology has four phases - Inception, Elaboration, Construction, and Transition. The Inception phase involves analyzing business needs, documenting requirements, developing a vision and business case, and designing prototypes. The Elaboration phase focuses on gathering detailed requirements, completing the system design, and setting up change management. The Construction phase is dedicated to integration, testing, and iterative development. Finally, the Transition phase deals with production rollout, training, and phasing out legacy systems. Sample artifacts for each phase like use case diagrams, prototypes, and architecture

1. 1
Rapid
Softwarer Development Process
Thanh Nguyen
Technical Director,
http://smartbiz.vn

2. 2Nov 12, 2008
TABLE OF CONTENT
 I. Rapid Portal Methodology (RPM)
– I.1. Rational Unified Process (RUP)
– I.2. Tasks/Activities and Deliverables
 II. Inception
– II.1. Milestones & Deliverables
– II.2. Audience & Objectives
– II.3.3. Essential Activities
– II.3.4. Sample Artifacts
 III. Elaboration
– II.4.1. Milestones & Deliverables
– II.4.2. Essential Activities
– II.4.3. Sample Artifacts
 IV. Construction
 V. Transition

3. 3Nov 12, 2008
I.1. RPM & RUP
DomainKnowledge
TechnicalExpertise
Performance Guarantee
Fixed Time. Fixed Price.
 Benefits:Benefits:
 FastFast – product expertise, business savvy, and technical know-how
substantially reduce timelines.
 FlexibleFlexible - easily tailored to fit the specific needs of your organization.
 Cost EffectiveCost Effective – focus on off-the-shelf components, re-use, and integration.
 ProvenProven – used to deliver successful enterprise portal implementations
– high quality, on time, and on budget.
 RPMRPM is based on the
Rational Unified
Process (RUPRUP) and
comprises best
practices and lessons
learned from
implementations
layered on top of RUP.

4. 4Nov 12, 2008
I.2. Tasks/Activities and Deliverables
INCEPTIONINCEPTION ELABORATIONELABORATION CONSTRUCTIONCONSTRUCTION TRANSITIONTRANSITION
TASKS/ACTIVITIESTASKS/ACTIVITIES
Vision & Biz Case
With
Stakeholders:
–High-level scope
–Schedule/Budget
–Non-functional
Reqs
Software
Requirement Specs
Design Prototype
TASKS/ACTIVITIESTASKS/ACTIVITIES
Detailed discuss:
– Tech & Biz Users
– Infrastructure
Software
Architecture Docs
Complete system
design
Set up change &
configuration mng.
TASKS/ACTIVITIESTASKS/ACTIVITIES
Integrate with the
legacy enterprise
Frequent Code-
Reviews
Testing:
–Unit/Integration
–System &
Performance
–User Acceptance
TASKS/ACTIVITIESTASKS/ACTIVITIES
Production Rollout
Technology
Transfer
Training
Gradual Phase-Out
of Legacy Code
Base
DELIVERABLESDELIVERABLES
Vision Document
Risk list
Software
Development Plan
Product
Acceptance Plan
Software
Requirement
Specs
Prototype
DELIVERABLESDELIVERABLES
Risk list
Change/Config
Mng
Soft Architecture
Document
Design model
–Object/Class Model
–Sequence diagrams
–Interaction
diagrams
Data model
DELIVERABLESDELIVERABLES
Iterative system
builds
Code Base
Database Scripts
Test Model and
results
Deployment plan
Supplementary
specifications
DELIVERABLESDELIVERABLES
The fully
integrated Portal
system
System
performance test
results
Release Notes
User’s Manual
Client support
material

5. 5Nov 12, 2008
II.1. Inception – Milestones & Deliverables
Lifecycle Objectives
 Analyze business needs and document
requirements (Audience & Objectives)
 Develop Vision & Business Case
 Identify supporting portal features
 Design prototype
Evaluation Criteria
 Stakeholder concurrence on scope
definition and cost/schedule estimates
 Agreement that the right set of
requirements have been captured and
that there is a shared understanding of
these requirements.
 Agreement that the cost/schedule
estimates, priorities, risks, and
development process are appropriate.
 All risks have been identified and a
mitigation strategy exists for each.
Key Artifacts
 Vision: document the prioritized system
requirements, key features & main
constraints.
 Risk List: Initial project risks identified.
 Software Development Plan: Initial
phases, their duration and objectives
identified. Resource and cost estimation.
 Product Acceptance Plan: Reviewed and
baselined; refined in subsequent phases
as more requirements discovered.
 Software Requirement Specs: functional
& non-functional requirements.
Use-Case Model: important actors and
use cases identified and flows of
events/pages outlined for only the most
critical use cases.
 Prototype: One or more proof of concept
prototypes to support the vision & to
address very specific risks.

6. 6Nov 12, 2008
II.2.1. Audience & Objectives
- High-Level Requirements (1)
Who Define portal audience
(end users) Employees
What Define high-level
requirements to
support objectives
4 Unified Search
4 Knowledge
Management
4 Team
Workspace
4 Collaboration
Tools4 Single Sign-On
4 Internationalization
4 Threaded
Discussions
4 24x7 Uptime
 Define business
objectives
4 Promote
Collaboration
4 Reduce admin &
maintenance
costs
4 Increased
Efficiency
4 Reduce Time To
Market
Why

7. 7Nov 12, 2008
III.2.2. Audience, Objectives – Sample (2)
Objectives
 Improve Communication
& Collaboration
 Reduce Project
Turnaround Times
 Reduce Maintenance &
Support Costs
 Threaded Discussions
 Structured Workflow
 Document Sharing
 Team Workspaces
 Intuitive Navigation
High-Level Requirements
 Unified Search
 Access To Customer Data
(ERP/CRM)
 Remote Access
 Unified Platform
Vietnam
UK
US
Shared Project
Human
Resource
Enterprise
Resource
Planning
External
Data
Enterprise
Content
Management

8. 8Nov 12, 2008
 Analyze Business Needs and
Document Requirements
– Document the problem statement
• The Problem of [X]
affects [X]
the impact of which is [X]
a successful solution would be [X]
– Develop storyboards to define the
system
• List of portals and portlets
• Navigation flow for entry,
start/end of business transactions
and exit
• Usability design
– Review Portal-Server features and
constraints
• Provides several sample
applications
III.3.3.1. Inception – Essential Activities

9. 9Nov 12, 2008
 Analyze Business Needs and
Document Requirements
– Refine system definition based
on Gap Analysis and document
extension requirements
– Prioritize all functional and
non-functional requirements
• Performance/QoS
• Availability
• Security, etc
– Identify key actors and use-
cases
– Document product acceptance,
software development and
iteration plans
III.3.3.2. Inception – Essential Activities
(2)

10. 10Nov 12, 2008
ROI
(4,296)
10,540
(6,000)
(4,000)
(2,000)
0
2,000
4,000
6,000
8,000
10,000
12,000
DollarsinThousands
Portal Costs
Portal Savings
Total Savings from Portal
III.3.3.3. Inception – Essential Activities
(3)
 Develop Business Case
– Identify business drivers
– Identify technical drivers
– Cost of ownership and ROI
assessment for Portal
– Benefits assessment for
deploying a Portal
– Risks assessment
– Identification of initial audience
for the portal
– Identification of initial content
and services for the portal
– High-level project scope and
timelines
– Project funding/sponsorship

11. 11Nov 12, 2008
 Design Prototype
– List of key pages, or portals
and portlets, that the users
will visit.
– The layout of the pages and
the navigation options.
– A list of include files for
reusability of JSP code.
– The sample Portal
application that will be used
as a template, otherwise
start a new.
– Collection of images,
navigation bars, logos if
available; creative design
brief.
III.3.3.4. Inception – Essential Activities
(4)

12. 12Nov 12, 2008
III.3.4. Inception – Sample Artifacts
 Could start with UI prototypes
 Could start with a domain model:
– Depending on the nature and size of the
application being built: if the application does not
have a UI, then having UI prototypes obviously
makes no sense.
– Depends on priority: Customer may place more
emphasis on domain models.
– Stakeholder recognition: discover domain objects
better and easier when working with users on UI
prototypes.

13. 13Nov 12, 2008
III.3.4.1. Inception – Sample Artifacts
Domain Model
 A domain model helps to define major
business concepts (entities) and the
relationships among them

14. 14Nov 12, 2008
III.3.4.2. Inception – Sample Artifacts
UI Prototype & Storyboards
 UI Prototypes and Storyboards are initial screen
mockups to get a feel for how the customer visualizes
the application
 A storyboard (also known as UI Flow Diagram) shows
the flow of the screens

15. 15Nov 12, 2008
III.3.4.2. Inception – Sample Artifacts
Use-Case Model, Wire Frames, Site Map

16. 16Nov 12, 2008
III.3.4.3. Inception – Sample Artifacts
Context Diagram

17. 17Nov 12, 2008
III.3.4.4. Inception – Sample Artifacts
Use Cases, Wire Frames, Storyboard

18. 18Nov 12, 2008
III.3.4.5. Inception – Sample Artifacts
Vision Document and ROI Assessment

19. 19Nov 12, 2008
III.3.4.6. Inception – Sample Artifacts
Use Cases and Test Scenarios

20. 20Nov 12, 2008
III.3.4.6. Inception – Sample Artifacts
high-level architecture diagram
 A high-level architecture diagram can help with
discussions about security, scalability, transaction
management, exception handling, and other important
application-wide issues.

21. 21Nov 12, 2008
III.4.1. Elaboration – Milestones &
Deliverables
Lifecycle Architecture Milestone
 Gather & document detailed requirements
 Complete system design
 Create a base configuration
 Setup change/configuration management
Milestone Evaluation Criteria
 System vision, requirements and architecture are
stable
 Prototypes have demonstrated that major risks
have been addressed
 The iteration plan for construction phase are of
sufficient detail to allow work to proceed and are
supported by credible estimates
 Stakeholder concurrence that current vision can
be met if current plan is executed as per current
architecture
Key Artifacts
 Prototypes: One or more executable architectural
prototypes to explore critical functionality and
architecturally significant scenarios
 Risk List: Updated and reviewed. New risks are
likely to be architectural in nature primarily relating
to the handling of non-functional requirements
 Technical Architecture Document: Detailed
technical architecture including network, hardware,
software, security design
 Design Model: Defined and baselined. Includes
use-case realizations for architecturally significant
scenarios. Object/component model and integration
interface definition/specifications
 Data Model: Defined and baselined. Major data
model elements (entities, relationships, tables)
defined and reviewed
 Software Development Plan: Updated and
expanded to cover the Construction and Transition
phases
 Use-Case Model: Approximately 85% complete. All
actors and use cases identified and their
descriptions captured
 Creative Design Document: UI design, wireframes
& templates

22. 22Nov 12, 2008
• Detailed Requirements
– Develop detailed Use-case
model and functional
requirements document
• Use BEA demo applications
and templates
• Facilitation and interviews
• Supported by Context’s
management tools
– Develop Creative design
document
• Use BEA demo applications
and templates
• Wireframe models
• UI Architecture and design
guidelines
III.4.2.1. Elaboration – Essential Activities
 Facilitation
 User Focus
Collaboration
Knowledge Management
Requirements Management
 Demos
 Interviews
 Goals &
Objectives
 Business
Expertise
 Product
Knowledge
 Branding &
Creative Design
User
Use
Case
Use
Case
Use
Case

23. 23Nov 12, 2008
• Complete System Design
– Develop technical architecture
document
• Detailed technical design
including software,
hardware, network and
security architectures
– Develop object and data
models corresponding to the
extension requirements
– Develop interface
specifications for all
integrations
– Update software development
plan, iteration plan and use-
case model
– Identify all major risks and
develop mitigation strategies
• More prototypes if necessary
III.4.2.2. Elaboration – Essential Activities

24. 24Nov 12, 2008
• Create a Base Configuration
– Create a rudimentary web
application for the portal
• Basic directory structure
• Deployment descriptors
• Placeholder JSPs
• Components from the prototype
and the sample web application
being used
– Set up infrastructure & tools to
support the portal
• Weblogic Server Domain
defining servers and clusters
• Weblogic Server Admin
Console
• A server with configured
services such as HTTP listen
ports, XML parsers, JDBC
connection pools, etc
• An enterprise application with
any supporting Webapps,
Weblogic Portal Admin Tools
Webapp, Weblogic Portal EJBs,
III.4.2.3. Elaboration – Essential Activities
Weblogic Domain
Weblogic
Server
Administration Console
Weblogic Cluster
Enterprise Application
Portal
Web App
Admin Tools
(Web App)
EJBs
Supporting
Web Apps
RDBMS
E-Business
Control Center
Networked Machine

25. 25Nov 12, 2008
• Create a Base Configuration
– Set up the database
repository & load sample
data
• Replace the Cloudscape
RDBMS with an enterprise
class RDBMS
• Weblogic provides scripts
for creating the default
schema and load sample
data
– Set up developer security
• CMS for all file based
assets and EBCC (E-
Business Control Center)
files
• Portal Admin Tool for
editing RDBMS data,
synchronizing EBCC data
and browsing ads, catalogs,
etc
• Server Admin Console for
granting access for
Weblogic server
III.4.2.4. Elaboration – Essential Activities
Weblogic Domain
Weblogic
Server
Administration Console
Weblogic Cluster
Enterprise Application
Portal
Web App
Admin Tools
(Web App)
EJBs
Supporting
Web Apps
RDBMS
E-Business
Control Center
Networked Machine

26. 26Nov 12, 2008
• Set Up Change/Configuration
Management
– Set up source code control tool
• CVS, Visual SourceSafe,
Interwoven, etc
– Domain and Server files
• Include config.xml,
fileRealm.properties,
SerializedSystemIni.dat, others
– Enterprise application and Web
application files
• Include
Applications/portalAppName/*
• Exclude *_tmp_war* files/folders
– E-Business Control Center files
• Include
portalAppName/application-sync/*
files/folders
– Miscellaneous files/folders
• PORTAL_HOME/db/*
• Backup/rotate log files
• Custom properties files, java, jsp,
images, system admin scripts, etc
– Change control process
• Change requests,
III.4.2.5. Elaboration – Essential Activities

27. 27Nov 12, 2008
Component
Interactions are
CRITICAL to
discover
III.4.3.1. Elaboration – Sample Artifacts
Components Identify Sub-Systems

28. 28Nov 12, 2008
III.4.3.2. Elaboration – Sample Artifacts
Decide How to Satisfy Each Component
Configuration?
Portal Feature Change?
New Component/Feature?
Portal Feature Extension?

29. 29Nov 12, 2008
III.4.3.3. Elaboration – Sample Artifacts
Identify Events/Data/Page Flows

30. 30Nov 12, 2008
III.4.3.4. Elaboration – Sample Artifacts
Artifacts – Design Documents

31. 31Nov 12, 2008
III.4.3.5. Elaboration – Sample Artifacts
Object Model, Data Model
e.g. Lighting, plumbing, etc.
scheduled-shared, or
scheduled-non-shared
EJBHome
remove()
remove()
getEJBMetaData()
(from ejb)
DayCategory
shortName : String
description : String
dayCategoryID : int
getCategoryOfDate()
ScheduleConstraint
availableFrom : java.util.Date
availableTo : java.util.Date
+theScheduleConstraint
+theDayCategory
ServiceRequestCategoryHome
find()
refresh()
remove()
remove()
getEJBMetaData()
getHomeHandle()
ScheduleHome
findScheduleByResourceID(resourceID : int)
findScheduleByServiceRequestID(serviceRequestID : int)
remove(arg0 : Handle) : void
remove(arg0 : Object) : void
getEJBMetaData() : EJBMetaData
getHomeHandle() : HomeHandle
PropertyResource
propertyResourceID : int
(from com.workspeed.user)
+thePropertyResource
ServiceInfoCategory
categoryName : String
description : String
WFMEngine
getAllActiveProcesses()
getTemplates()
getTemplates()
getCategories()
getWorklistFor()
(from com.workspeed.workflow)
Template
templateName : String
category
initiate()
initiate()
(fromcom.workspeed.workflow)
Process
processID : String
getHistory()
terminate()
setValue()
getValue()
startProcess()
(from com.workspeed.workflow)
WorkItem
workItemdID : string
setValue()
getValue()
acquire()
complete()
release()
(fromcom.workspeed.workflow)
ServiceStatus
serviceStatusID : int
description : String
ServiceRequestHome
create()
findAll()
find()
findAllClosed()
findByNotificationID()
remove()
remove()
getEJBMetaData()
getHomeHandle()
findWorkList()
ServiceRequestCategory
serviceRequestCategoryID : int
description : String
Schedule
serviceRequestID : int
startDate : java.util.Date
expectedCompletionDate : java.util.Date
+theSchedule+theScheduleHome
+thePropertyResource
ServiceInfo
serviceInfoID : int
serviceInfoCategory : String
requestID : int
text : String
modifiedTime : java.util.Date
modifiedByID : int
+theServiceInfoCategory
ServiceRequest
serviceRequestID : int
requestCategoryID : int
serviceStatus : String
processID : int
creatorID : int
createDate : java.util.Date
modifiedDate : java.util.Date
resolutionDate : java.util.Date
assignedToID : int
assignedToDate : java.util.Date
closedDate : java.util.Date
resolvedByUserID : int
isAuthorized : Boolean
elementarySpaceID : int
serviceDescription : String
isImmediate : Boolean
locationDescription : String
propertyID : int
notificationID : int
isChargeable : Boolean
isTaxable : Boolean
isSignOff : Boolean
isEstimateSignOffRequired : Boolean
estimateCost : int
finalCost : int
approvedByUserID : int
approvedDate : java.util.Date
routeTo : int
hasWorkItem : Boolean
formatXML()
update()
cancel()
authorize()
addServiceRequestInfo()
getServiceStatus()
requestInfo()
complete()
signOff()
inspectionPassed()
+theServiceStatus
+theServiceRequest
+theServiceRequest
+theServiceRequestHome
+theServiceRequestCategory
+theSchedule
+theServiceRequest
+theServiceInfo
+theServiceRequest
ServiceRequestEventLogHome
findByPrimaryKey()
findAll()
findByServiceRequestID()
create()
ServiceRequestEventLog
eventTime : java.util.Date
modifiedByUserID : int
previousServiceStatus : int
newServiceStatus : int
description : String
value : double
executedByUserID : int
+theServiceRequestEventLog
+theServiceRequest
Does the Portal server have this object?
Is this the most appropriate object or do we
need to extend it?
Does an adapter need to be constructed?

32. 32Nov 12, 2008
III.4.3.6. Elaboration – Sample Artifacts
Technical Design Documents

33. 33Nov 12, 2008
III.4.3.7. Elaboration – Sample Artifacts
Artifacts – Technical Architecture Doc
Ethernet
Cisco 5500
Cisco 5500
Cis co5500
Cis co5500
Cisco7507
DMZ
Netcentric (VLAN 2)
O&M (VLAN 4)
ROL (VLAN 8)
Certification
(VLAN 24)
Secure Zone
fw72vu91
st72vu91
rt72vu86
lb72vu91
fw72vu92
lb72vu92
Primary 10.14.158.4 (eth1)
IP Address (eth0) -198.241.180.7
x-over
x-over
x-over
x-over
x-overx-over
DMZ Switch 1
Sup. (VLAN 132) 10.14.132.254
Loopback 10.14.159.1
MSFC (VLAN 158) 10.14.158.2
HSRP (VLAN 158) 10.14.158.1
MSFC (VLAN 157) 10.14.157.2
HSRP (VLAN 157) 10.14.157.1
MSFC (VLAN 130) 10.14.130.2
HSRP (VLAN 130) 10.14.130.1
MSFC (VLAN 132) 10.14.132.2
HSRP (VLAN 132) 10.14.132.1
MSFC (VLAN 134) 10.14.134..2
HSRP (VLAN 134) 10.14.134.1
MSFC (VLAN 155) 10.14.155.2
HSRP (VLAN 155) 10.14.155.1
MSFC (VLAN 156) 10.14.156.2
HSRP (VLAN 156) 10.14.156.1
DMZ Switch 2
Sup. (VLAN 132) 10.14.132.253
Loopback 10.14.159.17
MSFC (VLAN 158) 10.14.158.3
HSRP (VLAN 158) 10.14.158.1
MFSC (VLAN 157) 10.14.157.3
HSRP (VLAN 157) 10.14.157.1
MSFC (VLAN 130) 10.14.130.3
HSRP (VLAN 130) 10.14.130.1
MSFC (VLAN 132) 10.14.132.3
HSRP (VLAN 132) 10.14.132.1
MSFC (VLAN 134) 10.14.134..3
HSRP (VLAN 134) 10.14.134.1
MSFC (VLAN 155) 10.14.155.3
HSRP (VLAN 155) 10.14.155.1
MSFC (VLAN 156) 10.14.156.3
HSRP (VLAN 156) 10.14.156.1
External Firewall 1Internal Firewall 1
Primary
10.14.157.4 (VLAN 157)
10.14.30.4 (VLAN 30)
External Firewall 2
VIP (Web Servers) 10.14.130.70
VIP (Cert Servers) 10.14.130.71
Circuit1 (VLAN 130) 10.14.130.254
Circuit2 (VLAN 134) 10.14.134.254
Mgmt (VLAN 132) 10.14.132.252
Mgmt2(VLAN 132) 10.14.132.251
Redundancy VLAN (primary) 172.16.3.1
Redundancy VLAN (Sec.) 172.16.3.2
st72vu92
fw72vu81
fw72vu82
st72vu81
st72vu82
fw72vu71
fw72vu72
Secure Zone Switch 1
Sup. (VLAN 4) 10.14.4.254
Loopback 10.14.31.1
MSFC (VLAN 30) 10.14.30.2
HSRP (VLAN 30) 10..14.30.1
MSFC (VLAN 2) 10.14.2.2
HSRP(VLAN 2) 10.14.2.1
MSFC (VLAN 8) 10.14.8.2
HSRP (VLAN 8) 10.14.8.1
MSFC (VLAN 24) 10.14.24.2
HSRP (VLAN 24) 10.14.24.1
MSFC (VLAN 4) 10.14.4.2
HSRP (VLAN 4) 10.14.4.1
MSFC (VLAN 5) 10.14.5.2
HSRP (VLAN 5) 10.14.5.1
MSFC (VLAN 29) 10.14.29.2
HSRP (VLAN 29) 10.14.29.1
Secure Zone Switch 2
Sup. (VLAN 4) 10.14.4.253
Loopback 10.14.31.17
MSFC (VLAN 30) 10.14.30.3
HSRP (VLAN 30) 10..14.30.1
MSFC (VLAN 2) 10.14.2.3
HSRP(VLAN 2) 10.14.2.1
MSFC (VLAN 8) 10.14.8.3
HSRP (VLAN 8) 10.14.8.1
MSFC (VLAN 24) 10.14.24.3
HSRP (VLAN 24) 10.14.24.1
MSFC (VLAN 4) 10.14.4.3
HSRP (VLAN 4) 10.14.4.1
MSFC (VLAN 5) 10.14.5.3
HSRP (VLAN 5) 10.1.5.1
MSFC (VLAN 29) 10.14.29.3
HSRP (VLAN 29) 10.14.29.1
Terminal Access Router
10.14.4.245(VLAN 4)
10.14.5.245 (VLAN 5)
10.14.31.33 (loopback)
Demarc Firewall1
Primary 10.14.29.4 (eth1)
Primary 10.12.12.4 (eht2)
IP Address (eth0)-TBD
Demarc Firewall2
Web Servers
(VLAN 134)
Cert Web Server
10.14.134.200
Production Web Server1
10.14.134.16
Production Web Server2
10.14.134.17
Performance Monitor
Server1
10.14.4.16
Performance Monitor
Server2
10.14.4.17
Net Backup Server1
10.14.4.28
Net Backup Server2
10.14.4.29
Logging Server
10.14.4.34
DNS Server1
10.14.4.39
DNS Server2
10.14.4.40
Report Server1
Boot IP 10.14.8.16
Standby IP 172.16.1.1
Report Server2
Boot IP 10.14.8.17
Standby IP 172.16.1.2
WAS Server1
10.14.8.25
WAS Server2
10.14.8.26
DB2 Server1
Boot IP 10.14.8.31
Standby IP 172.16.2.1
DB2 Server2
Boot IP 10.14.8.32
Standby IP 172.16.2.2
VTRS Conn1
10.14.8.40
VTRS Conn2
10.14.8.41
Conten t Services
Switch
Secondary 10.14.158.5(eth1)
IP Address (eth0) -198.241.180.8
Secondary
10.14.157.5 (VLAN 157)
10.14.30.5 (VLAN 30)
3/1-4
3/1-4
4/1-4
4/1-4
4/1-44/1-4
3/1-43/1-4
3/5
3/5
3/5
3/5
4/5
4/5
4/5
4/5
3/6-8
3/6-8
3/7
3/7
eth1
eth1
eth1
eth0
eth1
eth0
eth1
eth1
eth5
3/25-26,
4/25-26
3/25-31,
4/25-31
3/32-36,
4/32-36
3/37-41,
4/37-41
3/42-46,
4/42-46
eth5
eth0
eth0
eth5
eth5
eth5
eth5
eth1
eth1
Secondary 10.14.29.5 (eth1)
Secondary 10.12.12.5 (eth2)
IP Address (eth0)-TBD
Etherchanel
0/0
0/1
Etherchanel
3/47
3/47
3/47
3/47
Cisco 550 0
Cisco 550 0
LDAP Server1
10.14.2.16
LDAP Server2
10.14.2.17
Policy Server1
10.14.2.22
Policy Server2
10.14.2.23
Portal Server1
10.14.2.28
Portal Server2
10.14.2.29
Cisco 5500
Cisco 5500
OC
Switch
Core
Switch Firewall
DEX
4/7
4/6
4/7
4/6
eth2
eth0
eth2
eth0
8/2
8/2
2/3
2/3
2/4
2/4
Netcentric Production Physical Design
Report Server1
Service IP: 10.14.8.18
DB2 Server
Service IP 10.14.8.33
LDAP Server
10.14.24.16
Portal Server
10.14.24.22
Policy Server
10.14.24.27
VTRS Conn.
10.14.24.33
WAS Server
10.14.24.38
DB2 Server
10.14.24.45
Report Server
10.14.24.54
Cisco 5500
Cisco 5500
DEX WAN
Internal Firewall 2
eth
3,4
, m
gm
t
eth/3,4,mgmt
198.241.180.0/24
Cisc o7507
Cisco 7507
rt72cv25
rt72cv26
Internet
UUNET
Internet
Genuity
x-over
x-over
Dist.
Switch
Cisco 5 500
Cisco 5 500
7/10
7/10
Visa
Corporate
Network
st72cv44
st72cv45
Sys. Mgmt Server1
Boot IP 10.14.4.22
Standby IP 172.16.4.1
Sys Mgmt Server2
Boot IP 10.14.4.23
Standby IP 172.16.4.2
Sys Mgmt Server
Service IP 10.14.4.24
3/37-41,
4/37-41
3/25-31,
4/25-31
3/32-36,
4/32-36
3/42-46,
4/42-46
3/25-26,
4/25-26

34. 34Nov 12, 2008
III.4.3.8. Elaboration – Sample Artifacts
User Interface Design and Usability

35. 35Nov 12, 2008
III.4.3.9. Elaboration – Sample Artifacts
Project Plan

36. 36Nov 12, 2008
III.5.1. Construction – Milestones &
Deliverables
Initial Operational Capability
Milestone
 Set up a development site
 Set up basic services
 Set up personalization, commerce and
campaign services
 Integrate with the extended enterprise
 Deploy in a test environment
 Conduct System & Integration Testing
Milestone Evaluation Criteria
 Is this system release stable and mature
enough to be deployed in the user
community
 Are all the stakeholders ready for the
Key Artifacts
 “The System”: The deployed platform fully
integrated ready to start system testing
released in successive iterations
 Deployment Plan: Initial version developed,
reviewed and baselined
 Test Model: All tests designed and
developed to validate system through
construction iterations
 Design Model: Updated with new design
elements identified during the completion of
all requirements
 Data Model: Updated with all elements
needed to support the persistence
requirements (tables, indexes, object-
relational mappings)
 Supplementary Specifications: Contains all
non-functional requirements, e.g.
performance, QoS, availability, scalability, etc
 Use-Case Model: Updated with any use
cases discovered during the construction
phase
 Iteration Plan: If construction and elaboration
phases will occur in multiple iterations

37. 37Nov 12, 2008
III.5.2.1. Construction – Essential Activities
Source-Control System
Enterprise
Application
Bank_Pat
Enterprise Application
Bank_Mauricio
Enterprise Application
Development Server
EBCC
Bank_Pat
Enterprise Application
Bank_Mauricio
Enterprise Application
Administration
Console
(Web Application)
Source-Control System
Enterprise
Application
3a
3b
Development Server
EBCC EBCC
Bank
App Data
Bank
App Data
Source-Control System
Update and check out
local source files
Pat’s Workstation Mauricio’s Workstation
EBCC EBCC
Bank
App Data
Bank
App Data
Bank_Pat
Enterprise Application
Bank_Mauricio
Enterprise Application
Data Sync
( Web Application )
Data Sync
( Web Application )
Invest
Web App
Invest
Web App
Development Server
EBCC EBCC
Bank
App Data
Bank
App Data
Source-Control System
Check in modified files
EBCC EBCC
Bank
App Data
Bank
App Data
Source-Control System
• Set Up a Development Site
– Allow for concurrent
development
– Organize tasks into discrete
units, e.g. promotional
campaign, webflow
modification, etc
– Create a separate instance of
EBCC for each task/developer
– 1 EBCC instance  1
Enterprise Application, each
under a unique name
– Use source control to manage
the data between separate
instances and the master server
– Similar set up for all
application source code and
content
– Keep an audit trail/history of

38. 38Nov 12, 2008
III.5.2.2. Construction – Essential Activities
• Set Up Basic Portal Services
– Develop the user interface
• Portal, portlets, graphics, skins,
layouts
• Use EBCC
– Implement the data/page flow
• Construct JSPs and data
processing nodes
• Create Webflows through
EBCC
– Set up customer profiles
• Authentication/authorizations
• Integration with LDAP
• Develop Profiles & Property
sets
• Customize data entry JSPs
– Develop customer segments
• Dynamic categorization of
customers
• Use EBCC for creating rules
– Set up the product catalog
• Extend/modify schema
• BEA Weblogic Commerce
Server Admin Tool
– Set up a content management
system
• Interwoven, Vignette

39. 39Nov 12, 2008
III.5.2.3. Construction – Essential Activities
• Set Up Personalization, Commerce
and Campaign Services
– Add JSP tags for retrieving personalized
content
– Set up payment, order and shipping
services
• Use JSP, Webflow and Pipeline
templates
from BEA provided sample e-commerce
reference portal application
– Set up campaigns
• Use EBCC to create user and
global discounts
• Create ad placeholders
• Create email templates
• Design and implement scenario actions
• Use template from BEA
provided sample personalization

40. 40Nov 12, 2008
CRM
ERP
SCM
Mainframe
Partner Systems
III.5.2.4. Construction – Essential Activities
• Integrate with the Extended
Enterprise
– CRM, ERP, SCM,
Mainframe systems
integration
– Partner, customer,
supplier systems
– BEA Weblogic
Integration Server
– Other EAI vendors like
Tibco, IBM,
webMethods,
SeeBeyond, Vitria
– JCA/JMS, Web
services, SOAP, WSDL,
UDDI
– Service based
architecture
– Well defined interface
between Portal and all
external systems

41. 41Nov 12, 2008
III.5.2.5. Construction – Essential Activities
• Deploy in a Test Environment
– Install Weblogic Portal on a test
server
– Set up RDBMS and
load/migrate data
– Copy domain and server config
files from source control system
– Copy and deploy the enterprise
application from source control
system into test environment
– Use EBCC to synchronize data
from source control system to
test environment
– Copy all other assets like
graphics, properties files, etc
– Set up integration with external
test systems
Enterprise
Application
Test Server
Source-Control System
EBCC
Content Management
System
Data Repository

42. 42Nov 12, 2008
III.5.2.6. Construction – Essential Activities
• Conduct System and Integration
Testing
– Execute all system and
integration test plans
– Implement “continuous”
testing during development
• JUnit scripts for unit testing
• Execute all scripts every day,
even multiple times if
possible
– Each iterative release is unit,
system and integration tested
– Automate system and
integration testing if possible
• LoadRunner, JTest, etc
– Validate against user
acceptance criteria and other
system specifications

Integration
Testing
Functional
Testing
Employee Portal
Company
New Products
My Support
My Account
Configure
User
Acceptance

43. 43Nov 12, 2008
III.5.3.1. Construction – Sample Artifacts
Class & Package Diagram
 Class Diagram
 Package Diagram

44. 44Nov 12, 2008
III.5.3.1. Construction – Sample Artifacts
- Over-modeling an EJB
 A lot of content but the model is just verbose.
 If entire design document filled with this level of "fluff"
 quickly getting bored and dismissing the design document as "useless."
 Model the important parts of the system, not the trivia.

45. 45Nov 12, 2008
III.5.3.1. Construction – Sample Artifacts
- modeling an EJB
 Removes the fluff and focuses more on the important content.
 Use Stereotypes to model orthogonal information:
– Provide some hints to your architects and designers about what kind of
information should be included with each stereotype
– Introduce some modeling standards to your organization.

46. 46Nov 12, 2008
III.5.3.2. Construction – Sample Artifacts
QA Plan, Supp Specs, Deployment Plan
Test Cases

47. 47Nov 12, 2008
III.6.1. Transition – Milestones &
Deliverables
System Release Milestone
 Tune performance for the production
environment
 Deploy in the production environment
Milestone Evaluation Criteria
 Are all stakeholders and user representatives
satisfied
 Are actual resources expenditures versus
planned expenditure still acceptable
 Has all operational system knowledge been
transferred to the maintenance personnel
Key Artifacts
 “The System Build”: Complete in
accordance with all system requirements. The
final release should be useable by the
customer
 Release Notes: Complete
 Installation Artifacts: Complete
 Training Material: Complete to ensure that
the customer can become self-sufficient in the
use of the system
 Client/Operations Support Material:
Complete to ensure that the customer can
become self-sufficient in the use of the
system
 System Capacity Model: For on-going
scaling of the system as user load increases

48. 48Nov 12, 2008
III.6.2.1. Transition – Essential Activities
• Tune Performance for the Production
Environment
– Create & run performance test
scripts using tools like
LoadRunner
– Develop Quality of Service
(QoS) capacity model based on
system resource limits
– Tune system and iterate
measurements
– Measure and monitor production
system QoS capacity limits
– Set up and test Weblogic Server
cluster configuration for high
availability
– Document system tuning and
maintenance procedure
– Set up system dashboard
HIGH PEFORMANCE ARCHITECTURE BEST PRACTICES & GUIDELINES

49. 49Nov 12, 2008
III.6.2.2. Transition – Essential Activities
• Deploy in the Production
Environment
– Set up production
infrastructure
• Firewalls, load balancers, web
servers, application server
clusters, RDBMS servers, file
servers, etc
– Install Weblogic server and
other software
– Deploy application in the form
of an EAR archive
– Data load/migration into the
production RDBMS and
content load through CMS
– Set up integrations with
external production systems
– Set up/verify system security
• SSL certificates,
authentication & authorization
– Browse through production
site for sanity check before

50. 50Nov 12, 2008
III.6.3.1. Transition – Sample Artifacts
Cap Model, Perf Charts, Release Notes
Throughput
0
10
20
30
40
50
60
70
5 10 20
Concurrent Users
Requests/sec
SSL
Non-SSL
Poly. (Non-SSL)
Poly. (SSL)

51. 51Nov 12, 2008
III.6.3.2. Transition – Sample Artifacts
Deployment Model (1)
 Modeling the obvious: "App-Inf," "webapp," and "meta-inf"
directories add no value to the diagram.
 ONLY models the "definition" of the module

52. 52Nov 12, 2008
III.6.3.2. Transition – Sample Artifacts
Deployment Model (2)
 A deployment model needs to show the "definition" and the "context.“
 Good models answer some questions and raise others:
– SCM need to configure a JMS queue and a JDBC driver in the environment.
– Besides, critical information on the JMS queue and JDBC driver are also included.
 UML-Diagram Tip: every diagram should have a specific purpose.

53. 53Nov 12, 2008
III.6.3.2. Transition – Sample Artifacts
Deployment Model (3)

54. 54Nov 12, 2008
III.6.3.2. Transition – Sample Artifacts
Deployment Model (4)