Integration Process

• … defines the sequence of activities to be done in

a disciplined manner in order to successfully
develop an integrated information system
• Sound practices are
– Interative development
– Incremental development
– Prototyping
– Reuse
 Recommended Reading
• Martyn Ould, Managing Software Quality and
Business Risk, Wiley 1999
 A Priori
• Identify cardinal aims
– Whole life costs
– System goals
– Side effects
• Develop a risk management plan
– Risk = any threat to one or more of the cardinal aims
– 4 generic steps
• Risk identification
• Risk analysis
• Risk response planning
• Risk resolution and monitoring
– Result = Risk Register
• Lists the risks and their cause-effect relationships
• Every risk has a cause with some probability and an effect with some
size or impact
 A Priori - Part I
• For each risk in the risk register, we decide
– Event of uncertainty or estimating uncertainty
– A first estimate of the scale of the risk in terms of probability and impact
– If we need to take action
• In case that we decide to take action, we
– Identify one or more risk reducing measures
– Determine which (if any) are cost-effective
– Record those chosen
– Note the switching criteria for a contingency plan
• For each risk, we
– Quantify the residual risk and record it against the risk in the Risk Register
• Part of the risk reduction strategy is to select the proper project model
– In order to give a risk-reducing structure to a project
 Risk Register Entries
• R No
• R Description
• Causes Rs
• Source of uncertainty
• Nature of uncertainty
• Probability (discrete)
• Impact (discrete)
• Chosen R reducing measures
• R owner
• Residual R
• Best case value
• Chosen case value
• Worst case value
 Process Models
• Boehm’s Spiral (risk driven!)
1. determine the objectives, alternatives, and constraints
2. Evaluate the alternatives; identify and resolve the risks
3. Develop and verify the next level product
4. Review the outcome of the cycle & plan the next cycle
• V-Process Model = 1 cycle
– User model: requirements expressions & system specification
– Architectural model: system design
– Implementation model: component specification
– … should be used when there is either a good system specification
and a predictable solution, or a good requirements expression and
the prospect of a good system specification and a predictable
solution
 Process Models
• VP-Process Model = V-Process Model + Prototyping
– … should be considered when there are risks related to open
questions about functionality and feasibility
• Evolutionary Delivery Process Model = several cycles
– Iterative development: subsolutions
– … should be considered when the final form of a system cannot be
decided until something has been tried, or exact relationship
between the system and the business is complex or may change
• Incremental Delivery Process Model = lots of small cycles
– Stepwise adding new functionality
– … should be considered when we can only see part of the
functionality at the outset, or we cannot deliver everything on one
day, or the business could not stand the change all in one go
 Process Models
• DSDM Process Model
– After a feasibility and a business study,we run three indepent
cycling task forces
• Functional model iteration
• Design & build iteration
• Implementation
– The business study produces a business area definition, a system
architecture definition, and an outline prototyping plan
– … should be considered when
• One of the cardinal aims is quick business benefit, or
• The business environment is changing rapidly, or
• Deployment of the system might be resisted, or
• Ownership by the users might be hard to establish
 Process Models
• Exploratory Process Model
– any kind of unwinding Boehm’s Spiral
– … should be considered when the goal is very vaguely specified
and itself Must be discovered, or the route is very poorly
understood and must be found
• Mixed Process Model
– … combines the above strategies

• Risk and project management planning finally provides

– Risk Register
– Overall Process Model
– Skeleton Work Breakdown Structure
 A Priori - Part II
• Construct the quality achievement strategy for the project
– Characterize the future system in terms of its computational model
(units of decomposition & sorts of relationships) and criticality
– Identify any expectation or requirements of the software
engineering processes
– Select a set of methods that match the computational model and
cover all aspects
– Check for their V&V (validation and verification) potential
– Identify the activities that arise from the use of the chosen methods
– Choose appropriate tools to support them …
– Define the development, target, and maintenance environments …
– Record all decisions in the Quality Achievement part of the
Quality Plan
 A Priori - Parts III-V
• Construct the quality control strategy for the project
– Results in the Quality Control part of the Quality Plan
• Construct the quality preservation strategy for the project
– Results in the Quality Preservation part of the Quality Plan
• Construct the Resource Plan for the project
 Integration Process Activities
• Technical Activities
– Requirements gathering
• Requirements specification, modeling with use cases, revising the use
cases, setting the priorities, obtaining the requirements model
– Analysis of existing applications
• Functional analysis, technical analysis, overlapping analysis, existing
integration analysis
– Selection of the integration infrastructure
– Problem domain analysis
– Design
– Implementation
– Testing
– Deployment
 Integration Process Activities
• Support Activities
– Project management
– Configuration and change management
– Communication with the environment
• 4 Phases
– Data level -> Application interface level -> Business method level
-> Presentation level
• Main iterations for each phase
– Inception -> Elaboration -> Construction -> Transition
 Integration Process Activities
• Functional Analysis
– Identification of functionality
– Setting the experiment environment
– Black box analysis
– Logical architecture identification
– Dependencies analysis
– Data model identification
– Integrity analysid
– Transactional behaviour analysis
– Security analysis
 Integration Process Activities
• Black box analysis records
– Function
– Description
– Access (UI or API)
– Requency of use
– Required inputs
– Outputs
• Security mechanisms
– Authentication
– Authorization
– Communication channel security
– Auditing
 Integration Process Activities
• Technical Analysis
– Identification of application interfaces
– Application architecture identification
– Position of the application in the IS
– Sensibility to failures
– System load and performance analysis
– Identification of technologies used
– Source code availability
 Integration Process Activities
• Overlapping Analysis
– Functional overlapping
– Data model overlapping
• Existing Integration Analysis
– Identification of applications
– Type of integration
– Integration procedure