Project #25361 - IT426

 

Week 4: Individual Project

 

Measurable Terminal Objectives: Demonstrate how enterprise integration approaches and best practices are used by organizations.

 

[Make sure that your document fulfills the following requirements:

 

  • Update the previous sections based on the instructor's feedback.

  • Support your information with scholarly sources (2 minimum).

  • Cite each source in-text and with a References page, using APA style.

  • Name the document “yourname_IT417_IP4.doc.”

  • Minimum length is 3-4 new pages.]

 

Best Practices

 

[Include the following new content:

 

  • Research the Internet and library for some best practices in system integration, and locate at least 1 reference that could be applied to your project.

  • Summarize the related best practices and how they would affect your plan.

  • Revise the system integration plan according to the best practices material you reviewed. This will be the rough draft of your plan.

  • Provide a summary of the changes in the Best Practices section of the plan.

 

Students will be expected to perform adequate research on best practices in system integration, and locate at least 1 reference that could be applied to their project. The best practices should then be related to the students' plans.

 

The system integration plan should be modified based on the material reviewed. Changes should be summarized in the Best Practices section of the plan.

 

Formatting should adhere to APA guidelines.

 

Grammar, spelling, punctuation, and format should be correct and professional.

 

<<Insert Best Practices here>>

 

(Example:

 

A Best Practice is an industry-accepted technique, method, or process that standardizes the best means to accomplish a desired outcome. If an organization follows the best practice, the desired outcome will be achieved with minimal complications. In the IT industry, best practices are prevalent because of business’s dependence on data and business processes and IT’s desire for tested and proven techniques (Lee, 2014).

 

Systems Integration through Best Practices

 

Systems Integration, is one aspect of the SEIT (Systems Engineering, Integration, and Test) process, essentially it is the process of assembling the constituent parts of a system in a logical, cost-effective way (Houser, 2011). Systems Integration greatly benefits from best practices where both the new system is developed and integrated (high-level) and in the new system’s configuration (low-level):

 

High-Level Best Practices:

 

Pete Hauser (2011) lays out ten best practices in his Northrop Grumman presentation “Best Practices for Systems Integration”:

 

  1. Adopt a continuous integration model

 

 

Figure 4: Continuous Integration Model

 

  1. Emphasis on Subsystems – Subsystems satisfy sets of system-level requirements for capabilities and performance
  2. Create a systems integration team – the system integration team should be composed of Responsible Engineers, each of whom owns and is responsible for their subsystem’s capabilities.
  3. Create a System Architecture Skeleton (SAS) – The SAS provides an environment that mimics the actual system physical architecture enabling early milestones that can be demonstrated to the customer
  4. Define a Configuration Management process – The Configuration Management and Systems Integration teams should own the hardware and software configurations (not the Hardware and Software Teams) and should use controlled source code to perform software application builds and system builds (ensuring all configuration settings & files are controlled)
  5. Develop component and subsystem specifications

 

  • Requirements – System and derived requirements

  • Design – High level and detailed designs (models)

  • Verification – Systems requirements verification and component checkout

 

  1. Perform component-level checkout – Software checkout is performed using written procedures and includes:

 

  • Unit testing – exercise all new software using test drivers

  • Component testing – verify component interfaces and compliance with requirements

  • Device integration – verify that device controllers communicate correctly with the associated devices

    Hardware / Fabrication checkout is performed using written procedures and includes:

 

  • Physical configuration check – audit against the drawings

  • Cable check – check cables for continuity, shorts, and cross pins

  • Built in test – exercise each device’s built in test

 

  1. Track integration process

 

  • Track successful subsystem integration and verification

  • Understand dependencies through tracking component releases

 

  1. Perform regression testing – The SAS and all integrated components are continuously tested to detect regression and promote robust performance.
  2. Testing

 

  • Stress testing includes:

    • Processor and storage measurements in various system conditions.

    • “Corner condition” testing.

    • System operation beyond required system capacities.

    • Endurance testing and “woodpecker” testing.

  • Long mission thread testing includes:

    • Operationally relevant scenarios.

    • User testing (focus groups) to ensure suitability.

       Low-Level Best Practices:

      Ferrier & Petrini (2010) describe some best practices for WebSphere 7.0:

      Design and Use System Topology Early On

 

  • Choose a well-tested and understood topology –
    • Often Remote Messaging and Remote Support
  • Consider how to split up modules –
    • Large number of mediation modules impacts memory consumption/deployment, failover (50 modules per cluster is a rule-of-thumb);
    • Small number of mediation modules impacts ease of development (don’t use more than one developer per module)
  • Use source control
    • Don’t merge module changes
    • Don’t keep too much checked out
  • Make development and test environments look like production (including security settings)
  • Use as the real database and other supporting systems as early as possible
  • Spend time on interfaces and business objects
    • Changing designs arbitrarily is difficult so do it right the first time
    • Adopt a naming convention and add constraints
    • Define an enterprise policy
    • Configure a default namespace policy
  • Don’t use empty/null namespaces or use the same namespace in more than one library or project.

 

Consider the Logging Strategy

 

  • Include an unique identifier for each interaction
  • Consider granularity (the extent to how small the system is broken down into parts) and how logging on entry to services and calls will be accomplished

 

Handle Faults Appropriately

 

  • Make provisions to handle both types of faults:
    • Modeled – Appear on the interface, aka business, checked faults
    • Unmodeled – Don’t appear on an interface, aka system, runtime, or unchecked

 

 

 

 

 

Best Practices – Impact on LFSB’s System Integration

 

No project is ever the same as another project as is neither a software development project is the same as a system integration project thus each project must be handled differently with same or disparate models for best practices. Despite each project’s purpose, IT projects have similar goals for which best practices are meant to deliver, including:

 

  • Eliminating wasteful investments of time and resources
  • Increased internal productivity and quality of communication
  • Reduced duplication of effort and improved risk management

 

Through the use of best practices, regardless of the model or methodology used, LFSB will benefit from their employment. The impact on LFSB’s system integration project will be felt at both high-level where the project lifecycle lives and at much lower, dirtier levels where systems are calibrated and configured to be fully functional and deliver on the project’s requirements.

 

At a high lever there is a renewed and amplified emphasis on the subsystems that will operate with the ESB, an illustrated view of the architecture for purposes including better communications with the customer, an emphasis on the roles, who fills those roles and each role's responsibility, a process of checking the hardware, and testing - regression, stress, and end user.

 

At a low level, there is a new focus on system topology where certain aspects of configuring the new system, mediation modules are employed, the means of logging of transactions and errors are established, and defining fault management.

 

 

 

 

 

Changes Due to Implementation of Best Practices

 

There's an impact on the system integration plan where ITIL's Service Transition book is employed. With respect to Change Management, no longer will LFSB merely ensure than changes are "...tested, implemented, ..." etc. Using best practices, testing is now more clearly defined to be regression, stress, and end user testing. Planning is augmented with a continuous integration model, the system integration team is chosen with defined roles, and each subsystem is tracked as its integrated and their dependencies are defined.

 

For the employment of ITIL’s Service Asset Configuration Management, no longer is this phase merely ensuring the integrity of service assets, now there's a better process for accomplishing this task. Here we now have a better understanding of the topology, the communications methods between systems and how those communications are each identified, source control is now controlled, existing applications and databases are now stressed to be part of testing and acceptance, and faults and errors are provisioned.

 

Revised System Integration Plan

 

  1. Create a systems integration team
  2. Create a System Architecture Skeleton (SAS)
  3. Adopt a continuous integration model
  4. Define a Configuration Management process

 

5.      Choose and utilize models, e.g. UML et. al.

 

  1. Develop component and subsystem specifications

 

  • Requirements – System and derived requirements

  • Design – High level and detailed designs (models)

  • Verification – Systems requirements verification and component checkout

 

7.      Define processes for checking out and modifying source control

 

  1. Perform component-level checkout
    • Software checkout is performed using written procedures.
    • Hardware / Fabrication checkout is performed using written procedures

 

9.      Set up test environment to mimic production environment

 

10.  Define interfaces and business objects

 

11.  Define the Logging Strategy

 

12.  Install and load initial content of the knowledge base

 

  1. Testing

 

  • Regression

  • Stress

  • Long mission thread

 

14.  Review and correct faults

 

15.  Produce training material

 

16.  Train IT and customer service.

 

)/End Example

 

Subject Computer
Due By (Pacific Time) 03/17/2014 12:00 am
Report DMCA
TutorRating
pallavi

Chat Now!

out of 1971 reviews
More..
amosmm

Chat Now!

out of 766 reviews
More..
PhyzKyd

Chat Now!

out of 1164 reviews
More..
rajdeep77

Chat Now!

out of 721 reviews
More..
sctys

Chat Now!

out of 1600 reviews
More..
sharadgreen

Chat Now!

out of 770 reviews
More..
topnotcher

Chat Now!

out of 766 reviews
More..
XXXIAO

Chat Now!

out of 680 reviews
More..
All Rights Reserved. Copyright by AceMyHW.com - Copyright Policy