IT312 Systems

Integration and
Architecture
IT312 - SYSTEMS INTEGRATION AND
ARCHITECTURE

MODULE 1:
INTRODUCTION

Intended
Learning
Outcomes
1. To define different terminologies on software and systems
integration. 2. To describe the basic concepts of software and
systems integration methods.

1.1 SOFTWARE AND SYSTEMS

INTEGRATION METHODS

There must be a major discipline in the production, operation and

maintenance of software and systems integration capabilities within work
product facilities that supports the entire life cycle of the software (i.e., planning,
systems requirements, design, construction, installation, integration,
subcontractors, quality and delivery) which has to be thoroughly understood.
 Figure 1.1 Start
with the right
disciplines.

Methods. Provide effective methods for ensuring productivity-enhancing

processes and
resources, and plan for problems that affect integration environments.
Software. Software design, code and unit testing, plans, and testing
procedures combined with implemented systems, inform us that the created
software is being done correctly. It's key to "peer feedback". Systems. Ensure
that software design and development standards are allocated for systems to
be developed and documented as ready for the software combination and
system integration. Integration. This is the compass where applications,
programs, firmware and hardware can be
merged to work
together as one.

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

1.2 PROGRAM AND

PROJECT PLANNING

The aim of program and project planning is to provide the required

process steps within integration efforts to expand the planning for programs
and software design/development. This method of preparation would ensure
and define successful strategies and outcomes for carrying out software
design/development practices, processes, and implementing procedures that
support software and system integration activities.

1.3
SYSTEM
DESIGN

The system design method is to analyze customer requirements and

develop a software design/development migration plan to define the
architecture, components, modules, interfaces, and data needed for a
designed system to meet specified needs. The method of designing systems is
becoming increasingly relevant as it offers the disciplines required and applied
during life cycles of software design/development.

1.4 SOFTWARE
REQUIREMENTS

Defined and documented software requirements provide a systematic

approach to multiple-resource development. Functional software interfaces,
performance, testing, and manufacturing results with necessary plans,
documentation, and procedures become the basis for software design or
development. This effective method is used for initial software requirements
creation and modifications to design baselines.

1.5 SOFTWARE
DESIGN/DEVELOPMENT

The definition of software design/development is that of a structured

methodology for software design creation and production that incorporates the
design and software concepts that relate to the work product. The resulting
method defines details of the architecture, behaviour, components and
interfaces of the work product. The software specifications are settled between
the design/development components. The system and project plan described
provide traceability according to software-defined processes and procedures.

1.6 SOFTWARE
IMPLEMENTATION

The value of software implementation is a prerequisite for informal and

structured integration testing in a facility for development, installation or
incorporation of software systems (S/SIF). The testing method for software
implementation provides assurance that engineering builds function as
expected to allow the smooth execution for verification and testing activities.
An incremental software and test approach incrementally adds the functions to
series of engineering builds. Software development/design matures through a
series of engineering builds. Based on lessons learned from previous
development builds, troubleshooting, and checkout, design plans are updated
for subsequent builds as software is checked and demonstrated.

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE
1.7 SOFTWARE
INTEGRATION

All software distributed or implemented by software integration or

testing is processed through a software library system that is designed and
managed to maintain the official status accounting for through delivery. To
ensure integration is ready for team troubleshooting and checkout, the
integration tasks include program design/development and test processes.

1.8 SOFTWARE AND SYSTEMS

INTEGRATION

The method of integration of software and systems offers a systematic

approach to effective integration activities. The software units, modules, and
subsystems are assembled in accordance with specified and recorded
integration procedures to ensure proper assembly of the software and system
elements. The integration stages and the software development plan (DP)
decide whether the developed elements are ready and subject to testing or
validation activities.

1.9 SOFTWARE
SUBCONTRACTOR

The functions and responsibilities of software subcontractors explain

how a system and projects will profit and rely on the services of outside
companies to provide the software and hardware products necessary to be in
contract and successful. The presentation of the subcontractor to the customer
must be known from the start of the presentation to the end. The customer can
ask questions to ensure the answers meet the reliability and support needs.

1.10 SOFTWARE AND SYSTEMS

INTEGRATION DELIVERY

When it is time to deliver integration of software and systems, the

delivery requires integration testing to be performed to ensure that both
software and systems are integrated and working together. Integration
practices ensure that the units tested are complete and documented before the
customer receives official delivery.

1.11 PRODUCT
EVALUATION

An efficient method of product assessment includes the required

process steps to execute and perform continuous assessments of software
work items during the life cycle of design/development and integration
activities. Numerous product assessment tools and checklists are created to
conduct the necessary audits and assessments using associated scheduled
processes.

MODULE 1:
ASSESSMENT

1. Given the overview above, use your own words to interpret the importance
of each method
and how it would be effective in creating a successful software and
system integration.

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

MODULE 2: PROGRAM AND

PROJECT PLANNING

Intended
Learning
Outcomes
1. To recognize the importance of program and project planning. 2. To
identify effective methods for software and system integration dealing with
program
and
project
planning

2.1
INTROD
UCTION

Program and project planning is important since it describes the

necessary software and system effort planning during life cycles of software
design / development. The definitions of systems design, software
requirements and design, configuration control, systems and software
integration, subcontractor involvement, deliveries, and product quality
evaluations are important for effective planning efforts. Initiation of preparation
starts with the consumer at the proposal process. The outcome of specified
software design/development plans, processes, procedures, subcontractor
support, and effective software resources offers cost estimates and schedules
for teams that are influenced by the delivery of the work items to the customer
from the beginning of the proposal phase.

2.2
PR
OG
RA
M

Until a program may involve a plan, goals of the program are specified
and disciplines of technique and management are established. Such
knowledge sets out a rational estimation or explanation for:

• Cost
evaluati
ons
• Risk management
assessments
• Defined and
documented tasks
• Manageable
schedules
•
Progres
s
reports

People who work in a life cycle of software design / development are

expected to meet and accomplish system targets, and recognize their high
standards. These activities start at the level of engineering systems design and
flows down to other software disciplines.

The program priorities define program goals with respect to how such
targets are to be met. Good programs that deliver on established targets and
within the scope are effective because of the implementation of:

•
Requi
red
data
 • Tasks or
functions
• How the work product
performs
• Quantitative
mechanisms

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

When assessing program goals and scope, program managers should

choose the best solution that would remove the "roadblocks" created by
scheduled completion deadlines, budget challenges, and people issues.

2.2.1 FRAMEWORK
ESTABLISED

Software processes provide the framework and effective planning when

it is time for deliveries to facilities for integration of software and systems and
to the client. All programs include framework-related activities. There are
several activities, planned deadlines and quality aspects required for
successful preparation to ensure the process is set not just for management
but also for the people who work. The quality assurance team, which is at
times independent, monitor the framework processes and the configuration
management personnel.

2.2
PR
OJE
CT

The key justification for the preparation and management of software

projects is to remove any uncertainty that may arise. When tasks are not
scheduled, the teams that are required to deliver work products fail, and
control is not even an option. Studies have shown that the project is
unsuccessful if timeline, cost, and quality goals are not a top priority. While
project success rates are increasing, if a goal such as quality criteria is not
achieved, the failure rate may be high. In order to prevent failure, the project
manager and a team of systems and software engineers constructing work
products need to develop a project planning strategy, coordinate tasks and
ensure that configuration control is in place. Software projects get into trouble
when there is doubt and misunderstanding at stake. There are occasions when
systems and software designers don't interact, so specified specifications are
not addressed with regard to the work product produced. Guidelines must be
identified to eradicate this lack of contact, such as:

• Structure daily
meetings
•
Sha
re
ide
as
• Inform project managers of
problems occurring
• Listen and try to resolve
complaints

Project can meet for a “daily stand-up” to get to key points or problems
and fix them everyday. If questions occur, address things with a project
manager, so you don't waste time with other team members.

2.3
PLAN
NING

Principals in communications planning identify priorities and targets

during program and project planning. Aspects of planning require a group of
managers to consider not only their position but also the technological
processes that support systems and software engineering and identify the path
that lies ahead. Managers have many strategy ideas and decisions which are
not agreed by team members because of the difficulty of the transition. The
system and project would consider doing away with uncertainty under
preparation.

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

The strain on teams can be immense and it can provide valuable

feedback, such as:

• Providing the team with the opportunity to know

what is to come
 • Involving applications and technical departments to help with
distribution times
• Planning on adapting and
embracing changes
• Identifying risks that could impact program planning and
project planning
• Defining and
understanding quality
• Track progress daily and adjust
if necessary

2.4 SENIOR
MANAGEMENT

Program managers and project managers are required at the senior

management level to provide effective planning and focus so that teams can
be effective during software design/development activities. Failure in planning
is not a choice and jeopardizes the effectiveness of achieving successful plan
and project execution practices. The key to reducing risks and the ability to
embark on operational operations is contact early in the process. A senior
manager's required job is to provide the common framework for program and
project planning that will address engineering tasks.

Many software managers start their careers as designers or developers

of software products. These managers type serve:

• The company, military, and aerospace program

and projects
• Their
employe
es
•
The
ms
elve
s

If the team or company of a program manager delivers program in a

timely manner to a client, this is called execution. There are issues concerning
execution, such as:

• Do you have customer

requirements?
 • Do you have an
approved budget?
• Do you have an approved plan
and schedule?
• Are your program and project capable of dealing
with change?
• Do you keep
everyone focused?
• Do customers encounter quality issues with delivered
work products?
• Do you measure work status on a
regular basis?
• Do you find ways
to improve?

Communication matters. For example, a successful software manager

needs to know how to interact in various ways, including delivering structured
presentations for top-level management. Face-to-face communication to
explain agreements with other program managers and project managers
provide a road map and goal fulfilment plans.
Program and project schedules which are not understood from the
outset will affect the resistance. It will imply that organizations and team
members are not working hard to implement

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

and use unreasonable schedules. Customers are better served by creating job
items which can be used for a long time.

2.6 PROGRAM AND

PROJECT PLANNING

Throughout this phase field the term "project schedule" is used to refer
to the overall project manager schedule. The project plan can be a single
document, or it can be spread over several documents. A coherent picture of
who does what should be included, in either case. Similarly, monitoring and
control can be centralized or distributed as long as a coherent picture of project
status can be maintained at project level.
 The size of various software design/development activities is enormous
and can result in uncertainty and collaboration between teams affected.
Internal organizations develop schedules in programs and projects, and define
processes and tasks. At senior management level, managers assign
responsibility, authority, and accountability to program and project managers
or team leaders to define software design/development (i.e., system and
software design, configuration management, quality engineering, etc.) to
provide the support required.
Planning
activities
include:
• Software lessons learned from previous programs
and projects
• Cost and schedule estimates and
staffing plans
• Software and system requirement
definitions
• Defined safety and security
requirements
• Selection of appropriate software
subcontractors
• Engineering documentation and historical
data impacts
• Program and project
objectives
• Contract understanding of required or necessary
requirements

2.7 PLANNED
SCHEDULES

The planned schedule defines the tasks and processes to be carried out
to accomplish those tasks and processes. The schedules planned impact the
team's risk evaluation, configuration management and quality capabilities.
There are three combined critical factors in many software
design/development programs and projects that affect the quality of work
products.
 Figur
e 2.1
Plann
ed
Sche
dule

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

2.8
DEVELOPME
NT PLAN

The essential things pertaining to a recorded development plan consist

of scheduled schedules and include software generation engineering
knowledge and guidance. It is necessary to be mindful that the planning
process is compatible with planning at program level. All major software design
/ development activities include continuity in line with the steps outlined in the
application of development planning, including:

• Definition of entry and exit criteria for the software

design/development
• Review and assessment of the work product and task
requirements
• Definition or updates of the process for each
software activity
• Development or update of the
estimating process
• Development of initial cost and schedule
estimation and risks
• Preparation of detailed
implementation plans

2.9
TEA
MWO
RK

Teamwork, collaboration and cooperation within teams implemented to

meet work requirements are an essential factor of all software programs and
projects. Efficient methods for managing programs and software preparation
offer a program and projects importance that far exceeds high expectations.
The energy and quality design / development software appeals for attaining
high-performance targets and expectations. In the work environment, a
cohesiveness is maintained by having confidence and trust among teams, and
planning schedules becomes much easier to coordinate and implement within
the team. If the team produces a high quality work product on time to meet the
timeline and work within the budget, a strategy produced is correct or
successful. Recall that senior managers need to encourage program
managers and project managers to work with their teams to be effective,
respond to customer expectations and ensure quality.

Figur
e 2.2
Team
action
cycle

When teams are autonomous within programs and initiatives they run
the risk of moving in different directions. A team that sets targets to develop
their own processes may hinder other teams' efforts. When there is a face-to -
face meeting as one group, teams can agree on proposed planning and
project schedules and goals or expectations in terms of quality.

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

In meeting as one group, the team will

accomplish the following:

• Meet and achieve team

objectives
 • Resolve conflicts
and issues
• Satisfy customer
requirements

2.10 TEAM CODE

OF CONDUCT

It is okay for a team to struggle but at least 80 percent of the time will be
right. Teams with the privilege and able to communicate clearly and their own
opinions seem to be successful. Listen and treat the person with respect while
one person is talking. Once you help each other, you will:

Figure 2.3
Team
developmen
t cycle

When teams are expected to attend meetings, be prepared and ensure

that items received for action are understood in connection with expected
goals.

MODULE 2:
ASSESSMENT

Read the case study presented below and

answer the questions.

WESTINGHOUSE ELECTRIC TAKES ON THE RISKS OF

A “BIG BANG” PROJECT
 Westinghouse Electric Company provides fuel, services, technology, plant
design, and equipment to utility and industrial customers in the worldwide
commercial nuclear electric power industry. A private company created in 1999
after its predecessor was sold and spun off, Westinghouse has 14,500
employees in 17 countries and is headquartered in Cranberry Township,
Pennsylvania. Shortly after Westinghouse’s creation, the company

9
implemented a full suite of SAP software across the enterprise.
For the past 15 years, the nuclear energy industry was in a holding pattern,
with steady business throughout but minimal growth. Westinghouse supplied
nuclear equipment and services to plants all around the world, and the
business was successful. The initial SAP installation served Westinghouse just
fine for nearly an entire decade. From 2010 onward, the nuclear energy
industry started to expand.
IT312 - SYSTEMS INTEGRATION AND
ARCHITECTURE

Westinghouse began to experience growth in sales, and its legacy SAP

installation was not equipped to handle the increased volume of business.
Westinghouse needed to update its older system to support new processes,
configurations, and functionalities that related to the larger amount of business
it was conducting. The company estimated that it would increase in size
fourfold over the next few years. Westinghouse opted to launch a sweeping
new program to update its IT. The program, called Synergy internally,
consisted of 40 different projects, and updating the SAP system was one of the
largest.
Rather than simply upgrade its existing systems, Westinghouse opted to “re-
implement” those systems with much more current SAP technology.
Westinghouse did this because its 10-year-old SAP ERP implementation was
too outdated. It was easier for the company to simply replace the old SAP ERP
systems with a completely new configuration. The division of the Synergy
project dedicated to the SAP re- implementation was known as Cornerstone,
aptly named because the new system would be the foundation for the
company’s future growth.
Westinghouse wanted to start with a cleancore SAP environment with a
completely new reconfiguration. The company’s goals were to convert all
existing data that the company wanted to save, as well as add new
functionalities that would help the company manage its imminent growth.
Westinghouse hoped to add a new general ledger, a new enterprise reporting
environment based on SAP NetWeaver Business Warehouse (BW) and SAP
BusinessObjects solutions, and new implementations of SAP Customer
Relationship Management (CRM).
 10
In order to ensure that the re implementation went smoothly, Westinghouse
took many precautions to manage the risks involved in such a significant
change. First, the company ensured that every element of the Cornerstone
project was motivated by a particular business driver or goal. For example, the
SAP CRM implementation was intended to address the company’s goal of
aligning three distinct operational regions to present a single face in every
customer location, and the SAP ERP Human Capital Management and SAP
NetWeaver Portal implementation were intended to support the company’s plan
to increase global hiring. By associating goals with each element of the project,
Westinghouse was able to more precisely control the implementation of the new
system.
Once the elements of the new SAP system came into place, Westinghouse had
to decide how to actually roll out the new system. It could have used a gradual,
phased approach, adding new systems over a three-year period, but the
company instead decided on what it called a “big-bang approach.” Management
decided that the company was growing too fast for a slow approach—it needed
the new systems as soon as possible, and hoped to recoup the return on
investment sooner rather than later. However, while the phased approach was
more expensive, it was also much less risky. To manage the increased risk of
the big-bang approach, the company brought in a change management
consultant. The consultant, John Flynn, helped Westinghouse with both the
Synergy and Cornerstone projects, but focused on the Cornerstone project.
Flynn performed a risk assessment study to identify business areas that were
most likely to undergo significant change. He found that the Westinghouse
IT312 - SYSTEMS INTEGRATION AND ARCHITECTURE
11 supply chain was one of the areas most likely
three weeks of the implementation. The
to endure significant change, since the
project team also set up a blog where users
company’s growth would add many new
could share tips and solutions.
elements to the chain. Therefore, the
The cutover to the new SAP system went
change management team spent extra time
smoothly, and the company plans to use
with Westinghouse’s supply chain staff
many of the techniques that it learned from
members to help them understand the new
the implementation in the future. It plans to
project and its impact on their day-to-day
use the blog as its primary communication
routines. The project team recruited power
method for support solutions and other
users from the supply chain organization
Synergy projects, and future additions to the
and discussed specific project details with
SAP suite will be much easier than the
business unit leaders. These meetings also
sweeping big-bang change.
helped gain support from supply chain executives who could better understand
the link between the information systems project and their business goals, and
then articulate this connection to other users.
QUESTIONS:
Next, after mapping the risk associated with each element of the SAP re-
1. Identify and discuss the risks in Westinghouse Electric’s Cornerstone
implementation, Westinghouse had to
project. finally switch, or cut over, to the new system. To handle that event,
Flynn worked with business leaders to recruit coordinators for every site in the
organization. Each site
2. Why was change management so important for this project and this
company?
coordinator had a list of responsibilities and
3. What management, organization and a checklist to complete prior to the
system
technology issues had to be addressed by going live to ensure each site was
ready
the Westinghouse project team? when the switch was flipped. Westinghouse
dedicated extra staff to answer employee questions in the problem areas
designated by Flynn. The company created an automatic call distribution
system and e- mail system that routed users across all time zones to the
employees most able to answer their questions. For example, Westinghouse
expected that there would be many questions about passwords, access issues,
time entry, and purchase requisition management after the new system went
live, so the company provided extra staff to answer those and other frequently
asked questions. This “temporary help desk” handled over 2,000 inquiries
during the first
IT312 - SYSTEMS INTEGRATION AND
ARCHITECTURE

MODULE 3:
SYSTEMS DESIGN

Intended
Learning
Outcomes
1. To identify people in-charge who take responsibilities in auditing and
reviewing
system/subsystem specifications. 2. To recognize different
concerning applications in system engineering plan.

3.1
INTROD
UCTION
 The system / subsystem specifications reviewed by program and
project managers maintain an accurate and thorough understanding of the
system architecture and applicable work products restrictions. Where program
or project plans provide interfaces with reusable software; specifications or
requirements are defined and evaluated for use. The word “reusable software”
is widely used in aeronautical and military programs or projects. External
software interfaces are specified as part of the software specifications which
are derived. Graphical representations are prepared to support systems
design and take the form of data flow, collaboration/communication, and
component diagrams.

3.2 DEFINITION OF
SYSTEM DESIGN

The requirements for a system design concept are checked with

relevant users to ensure an accurate and thorough understanding of the
limitations of a system or subsystem affecting the work products. At those level,
the external software interface is specified and checked for completeness.
Often the program and project plans provide reusable software, and design
specifications are defined for use. The external interfaces are often defined as
part of derived software specifications based on software design concepts.

3.3 SYSTEM
ENGINEERING
PLAN

The system engineering department for programs and projects is

responsible for software specifications development and analyzes the system
architecture and design, and assigns system requirements to them. A system
engineering plan (SEP) may be drafted to establish system-level technical
reviews for military and aerospace programs and projects that could be
conducted. Major audits and technical reports concerning applications and
systems include:

• Initial
requirements
(IR)
• Incremental design
review (IDR)
• Final design
meeting (FDM)
• Test
readiness
(TR)
 • First-article
inspection (FAI)
• Functional configuration
audit (FCA)
• Physical configuration
audit (PCA)

1
2

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

The SEP's main aim is to address improved processes from a system

engineering perspective.

This plan is organized into three

main sections:
• Systems
engineering

• Processes of the
technical program
• Integration of the
engineering

The system engineering team defines an organized and standardized

approach to overall system design, software design/development, systematic
evaluations needed and audits needed. It is critical that such a plan is recorded
and provided with the technical expertise to carry out activities during a life
cycle of software design/development. Using the plan also allows performance
to be more efficient and productive and allows technical planners to spend
more time planning, ensuring that the customer will be more assured and
satisfied in addressing the technical challenges ahead.

3.4 SOFTWARE
ARCHITECTURE EVALUATION

The purpose of software architecture assessments is to provide a

common approach for developing the architecture of the work product. This
evaluation applies to implementing enhancements to existing software
architectures for changes or corrections. This assessment offers the viability
and usefulness of concepts of software architecture for software work items to
be applied to.

Conflicts regarding requirements, architecture, or program and project

plans should be reported for resolution to the affected product teams. The
aims of the software architecture are operational scenarios and requirements
for the system or subsystem. Software architecture scope uses interface
specifications to evaluate operating structures, software threats, and strategies
to identify architecture objectives.

During development, the software architecture development is defined

and made available and understood before starting a life cycle of software
design / development. To assess the impacts on the production of architecture,
the system and project plans or schedules are analysed. Continual evaluations provide:

• The operational scenarios to

be reviewed
• The defined system and subsystem requirements
to be analyzed
• The defined system/subsystem interfaces for analysis Design
specifications assign resources to achieve complete understanding of the
software design specifications and capabilities. The requirements for system
or subsystem architecture define impacts which would include:

• The impacts to
quality factors
• The required functional requirements for the determination of
the software architecture

1
3

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

The trade-offs between quality performance and changes are prioritized

and external device or subsystem specifications are defined, and checked to
decide if specifications need to be modified. The software architecture
evaluation shows how well the architecture meets goals, constraints, and
attributes of quality.
The software design findings for improvements in the architecture are
analyzed to determine acceptable design methods to ensure that issues are
always addressed. One methodology that needs to be addressed is the
quantitative method for assessing the quality attributes for projects,
determined by research and criteria and using the brain.
MODULE 3:
ASSESSMENT

1. Explain how system engineering plan compliments software

architecture evaluation. 2. Describe the different “reusable software”
components.

1
4
IT312 - SYSTEMS INTEGRATION AND
ARCHITECTURE

MODULE 4: SOFTWARE
REQUIREMENTS

Intended
Learning
Outcomes
1. To define various software requirements in creation of programs
and projects. 2. To identify the factors that contributes to the failure
of some released software.

4.1
INTROD
UCTION

Defined software requirements include a structured approach to the

creation of software requirements generated by different ideas and
approaches to the programs and projects. The software specifications set the
guidelines for software design and integration testing practices for integration
of both software and systems. Software requirements are generated and
executed as a stand-alone item or as an item embedded in higher-level
assemblies (i.e., hardware units, workstations, monitor displays, integrated
platforms, etc.).

4.2 DEFINITION OF SOFTWARE

REQUIREMENTS

The identification and interpretation of software requirements starts with

the analysis of functional or performance specifications established to define
the software constraints. The program requirement assigned to the software
assessments specifies the quality, completeness, and applicability of work
product specifications.

To define derived software requirements, the system requirements

allocated to the software are refined in greater detail. Program and project
plans which include the ability to acquire reusable software; requirements for
software are always identified. The tools (i.e., dynamic object-oriented
requirements system [DOORS], matrix worksheets, etc.) can be used to
evaluate and model future design and related software specifications.

The creation of work product for software requirements is driven by

execution and awareness of what flows from the beginning of requirement
analysis to testing and validation, as seen in Figure 4.1.
 Figure 4.1 Software
Requirements
Development

1
5

Require
ments
Analysis

U
s
e

c
a
s
e

F
u
n
c
t
i
o
n
s

A
r
c
h
i
t
e
c
t
u
r
e

I
n
t
e
g
r
a
t
 i
o
n

Verification
and
Validation
IT312 - SYSTEMS INTEGRATION AND
ARCHITECTURE

4.2.1
ANA
LYSI
S

Analysis of the requirements includes a step-by-step process to develop

requirements for software work products to meet high-level user requirements,
allocated system requirements, and system operating concept ideas.
Requirements analysis involves a step-by - step method for designing
specifications for software work items that satisfy high-level user requirements,
allocated device requirements, and ideas for system operating definition.

4.2.2
USE
CAS
E

A use case is built to define a flow of operations for system output and
implementing applications. The case for software usage describes the
limitations or technological requirements based on target computers, a work
product execution plan and computer operating systems. Operational cases
include considerations of functionality, performance, maintenance and support,
as well as the operational environment of the work product, including limits and
constraints.

4.2.3
FUNC
TIONS

The concepts of function and architecture are evaluated to ensure

accurate and complete interpretation of what software is supposed to be doing.
If reusable software is included in program and project plans, the derived
requirements are identified and assessed for inclusion. Additional awareness
of cases of software organizational usage and software architecture includes
improvements in features and related specifications. It may be a continuing
practice throughout the process of identification of program specifications.
4.2.4
ARCHITE
CTURE

The concept of an architecture interface is described and specified as

part of the requirements of derived software. It prepares graphical
representations and takes the form of data flows and software component
diagrams. Pursuant to system specifications, usable software design /
development life cycle states and modes are set. For device architectures the
timing, series, conditions and probability of executing to define and redefine
functional interface specifications apply.

4.2.5
INTEGR
ATION

Design integration is transformation of a functional system into optimal

design solutions. Implementation of structured concepts of interface
management is important for resource planning and for executing systems
construct integration activities to meet software engineering requirements.

1
6

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

4.2.6 VERIFICATION AND

VALIDATION

To ensure verification and validation the program specifications are

reviewed. That requirement's priority is to help with system and project
resources to assess the scope of verification and validation for each specified
requirement. The verification and validation is defined for each condition, and a
list of techniques includes analyzes, checks, presentations and tests
performed in software integration facilities.

The most accomplished system verification and requirement validation

is to plan, review, and document compliance with specified specifications for
the software work product. Risk management will evaluate and ensure
software design / development activities meet user requirements and provide
efficient and cost-effective testing integration and requirement verification.
4.3 REQUIREMENTS
DOCUMENTATION

Documentation of requirements includes software requirements and

generated related information, including use cases and derived software
requirements which are the source of each requirement. Definition of the
software specifications is defined by implementation plans, software
processes, and product standards.

4.3.1 REQUIREMENTS
TRACEABILITY

Documentation of requirements includes software requirements and

generated related information, including use cases and derived software
requirements which are the source of each requirement. Definition of the
software specifications is defined by implementation plans, software
processes, and product standards. Software requirements can be traced from
device requirements or user requirements, which explicitly lead to an
architectural aspect of software.

4.3.2 FORMAL REVIEW

PREPARATION

It is important to have specified and complete software requirements in

place before formal review (i.e., functional configuration audit [FCA], physical
configuration audit [PCA]) acceptance. During these formal reviews, many
situations can be discovered when requirements are not complete and the
analysis of those requirements is still open or still in work. The FCA is more
interested in evaluating specifications that are more related to publishing
software documents and procedures that correspond to hardware drawings
and are installed in work items (i.e., processes, applications, paperwork,
facilities, etc.).

1
7
IT312 - SYSTEMS INTEGRATION AND
ARCHITECTURE

4.4 MANAGING A
REQUIREMENTS TOOL

Senior program and project managers will look for resources that fulfil
the technical specifications as follows:

• Ability to impose requirements in

multiple formats
• Support for traceability and
impact analysis
• Support for software baselines
and releases
• Alerts to modifications of the
requirements database

4.5 RELEASED SOFTWARE

REQUIREMENTS

Various published software requirement specification strategies,

organizational skills, and process guidance skills are designed to address the
software design / development areas which that influence the definitions of
requirements. Directly addressing these areas to align business goals and
objectives eliminates rework, increases productivity, and ensures that
standards lead directly to customers’ application and project success and
effective software delivery. Numerous factors contribute to the high rate of
failure for released software but the most important factor is the collection,
analysis and management of poor and undefined requirements. In Table 4.1
the high rate of failure for released software is described.
 Table 4.1 High Failure
Rate for Released
Software

1
8

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

MODULE 4:
ASSESSMENT

1. Explain how important the flow of software requirements

development. 2. What other factors could contribute to the
failure of released softwares?
 1
9

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

MODULE 5:
SOFTWARE DESIGN

Intended
Learning
Outcomes
1. To describe the nature of software
design/development. 2. To explain key
suggestions in software design/development.

5.1
INTROD
UCTION

Software design is a systematic methodology and method for software

requirement creation in specified work product designs. The concept of
software architecture provides a structure for product design development, and
may also provide constraints. The definition of software design implements
details regarding the architecture, components, and interfaces of a software
product. Software designers utilize element traceability of the design and
software requirements. The concepts of traceability data and software design
are recorded according to system and project schedules, proposals, methods,
and procedures, and the internal job guidelines relevant.

5.2
DEVELOPME
NT PLAN

The development plan (DP) for software is a well-defined and recorded

framework which is useful for implementation and relevant standards. The
design model can use the standard, tools, and methods of a program and
project. It is the responsibility of the software design teams to support the
development of software requirements and perform design tasks. The tasks for
developing top-level architecture for software design include identifying major
software functions (components), functional hierarchy diagrams, and hardware
/ software interfaces.
5.3 SOFTWARE
DESIGN DECISIONS

Establishing the idea of software architecture offers design principles

and decisions for a product of work. The definition of software requirements
and the software operational concepts identify the capabilities and
characteristics required for the inputs being analyzed and integrated in order to
make key design decisions. As seen in Table 5.1, many software design tools
support the software designer in terms of specifications, application creation,
configuration management (CM), and software documentation.

5.3.1 SOFTWARE REQUIREMENTS

EVALUATION

Software requirement reviews and evaluations define that operational

software scenarios ensure that problems affecting software design are
identified, evaluated, and resolved. The product design/development
department performs a risk analysis using prototype tools to help support
assessments of early specifications and the viability of design. If the
requirement is proven to be unusable and not to be implemented for use, the
information from these evaluations is fed back into the output of the
development phase of software requirements.

2
0

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE
 Table 5.1
Software
Design
Tools

5.3.2
SOFTWARE
REUSE

The reuse of software components identifies evaluations by definitions

of software architecture on how to decide to incorporate components into the
software design. Technology reuse incentives support various development of
software products in state and foreign markets. In defined software plans, the
reuse criteria are identified to determine whether the program and project
reuse library or existing software work products can be used for software
design activities that are near term.

5.4
PEER
REVIE
WS

Software processes require design engineers to carry out peer reviews

to find and correct as many errors as possible before the integration of test
teams or customers will find problems during delivery. To the software
designer, peer review starts with specifications, concept templates, and
continuous application and unit tests. During the software design /
development life cycle, these evaluations are implemented at different levels to
produce safe work products for software to provide assurance that bugs or
defects are found to corrected.

If errors are found early in the life cycle of production, time is saved and
the cost is not a concern. Minor software errors that aren't corrected or
addressed later in a system and project are significant errors. Software design
engineers always make mistakes in the development of their code, therefore
early peer reviews reduce the amount of rework and are not required in the
program and project late.

2
1

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

As stated in CMMI ® for Development (version 1.3) (CMMI stands for

incorporation of the Capability Maturity Model), peer reviews are an essential
part of verification and a validated method for successful removal of defect. A
significant corollary is to have a better understanding of the work products and
the processes which created them in order to prevent defects and to recognize
opportunities for process improvement. Peer reviews include a methodical
inspection of work products by peers of manufacturers to recognize necessary
defects and other improvements. Examples of peer review methods include
the following:

•
Ins
pec
tion
s
• Structured
walk-throughs
• Deliberate
refactoring
• Pair
program
ming

The peer review verification methods identify bugs, errors, and removal
defects in software with recommendations for improving code development as
shown in Figure 5.1.

Figure
5.1 Peer
review
method

The peer review method is applied to software work products developed

through programs and projects, but it can also be applied to other work
products, such as documentation and training, which other software teams
typically develop. Preparation for peer reviews includes the identification of
affected teams or groups to participate in peer review of affected software
product work. The criteria for conducting peer reviews are as follows: Schedule
the peer review at a convenient time
 • Assign reviewers
(i.e., teams)
• Prepare or
update materials
• Provide peer review
checklists
• Introduce training
materials
• Select software
work products
• Provide entry and exit criteria (i.e., minutes,
action items, etc.)

Make sure you have selected the right reviewers to be involved and
guidelines are understood from the start to ensure you have a successful peer
review. If peer reviews are conducted correctly, the peer review was
conducted and done correctly.

2
2

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

5.5 SOFTWARE DESIGN/DEVELOPMENT

SUGGESTIONS

One approach is the simultaneous design / development of software,

which is a strategy for reducing the time needed to increase efficiency through
the simultaneous execution of activities and information processing. The
simultaneous software design / development method refers to tasks that are
carried out simultaneously by different teams or groups that support the
development approach of a team. The second approach is
designing/developing Lean applications. Getting small working teams around
the borders of informative handoffs, reducing paperwork burdens and
optimizing good contact is much more efficient according to this approach.

5.5.1 CONCURRENT SOFTWARE/DESIGN

DEVELOPMENT
 Concurrent software design/development activities require designers of
software with sufficient expertise to anticipate where the defined design is
going. Only partial requirements are known and developed in short iterations
when starting software design/development to provide feedback for the
emerging systems. Use the simultaneous software design/development
process allows dedication to be postponed until the last moment when failure
to make a decision excludes a major alternative or decision.

5.5.2 LEAN SOFTWARE

DESIGN/DEVELOPMENT

The Lean software design/development target is to shift as many

adjustments from the top curve to the bottom curve as possible, as seen in
Figure 5.2.

F
i
g
u
r
e

5
.
2

C
o
s
t
C
u
r
v
e
s
 Lean design / development software prevents the freezing of all design
decisions as long as possible as it is easier to alter a decision not made. This
type of software design / development emphasizes the design and
management of change over the entire life cycle. Better understanding of
software engineering and prompt delivery to customers benefits the concepts
for process improvement and improves quality according to the following
principles:

• Early software product

development
• Elimination of
wasted time
• Understanding and working to software
requirements

2
3

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

• Meeting customer expectations and

deliveries on time
• Achieving and implementing
team goals
• Shortened design and test
software life cycles

5.5.3 LEAN SOFTWARE CONFIGURATION

MANAGEMENT

The standard approach of software configuration management (SCM)

includes defining systems and design/development software, and maintaining
control of configuration. Selected work items and the details for keeping such
configurations traceable are key points in the life cycle of the program. The
Lean model is the method where specific knowledge can be associated with
Agile software development.

5.6 AGILE
SOFTWARE
PROCESS
 Implementing Agile software processes, principles, practices, and
software design/development deliveries to customers of work products does
provide fewer flaws. Agile implementation of methodologies promotes various
projects and offers a system and project with the mind-set of a manager to
accentuate short-term schedule and project preparation. Adaptability to
evolving demands and close cooperation with clients and impacted teams
reflect transparency. The Agile management model shows processes reliably,
as seen in Figure 5.3.

Figure 5.3
Agile
Management
Model

The Agile model adopts values which consistently make decisions

which may cause a software design to be rejected. Compared to excellence
and good-natured principles for software design techniques, agile models are
more successful than conventional (i.e. waterfall, spiral, etc) perfectional
models versus appropriate principles for software design practices. Until diving
into software design / development practices, the software design engineer
using Agile principles has the capacity to grasp knowledge first.
Each day shifts to the present state of the economy. To conform to Lean
systems and fulfil the needs of programs and initiatives we need to address the
software development approach. For Agile Software Development the four
main elements are:

• The team has control of work

assignments
• Communication with team members and
customers is needed
• Change is good: “Think
outside the box”
• Customer satisfaction and expectations
are achieved

2
4
IT312 - SYSTEMS INTEGRATION AND
ARCHITECTURE

The Agile process method for team effort reflects how a team of people
working together on the software. The Agile method continuously eliminates
processes that don't work or create major delays in the software design /
development environment. Internal program and project managers are striving
to hold the team together by allowing for decisions, goals and a desire to
achieve results. When the Agile team sometimes discovers problems working
on their own processes, the team will stay the course to solve problems that
might have an impact on those processes.
Often, the Agile approach is about continuous gradual distribution of
items such as applications and systems to other members of the program and
project team and to the client. The Agile team is researching and assessing the
needs and expectations of the job items. Planning and evaluating what to
develop and describe acceptance is a benefit of reviewing applications and
managing activities that feed into each other from one team member.
Whatever Agile or Lean frame, process, or methodology is used, they employ
things like:

•
Data
mod
els
• Rules of
engagement

•
Guides
or
maps
• Agile
team
rules

These items can be helpful as teams are exploring the designs and builds
that are being prepared to conduct and perform software and systems
integration tests.
Agile offers experiences with teams that deal with systems and tools.
Success by team leaders increases outcome transparency and mutual team
productivity obligations. Strategies, procedures, and practices boost efficiency
and effectiveness. A good Agile team is alert to change, and can adapt
matching approaches and procedures.
5.6 CONFIGURATION
MANAGEMENT

When we look at the Agile process, CM methods for no specific routines

are not referenced. These methods are a discipline which supports and are not
directly involved in the development of executable code. If Agile processes
lack configuration control, then Lean concepts are a bust or a great waste of
time and cause chaotic behavior. You see no improvement in
design/development of the program.
It is not necessary for the members that make up the Agile team to
concentrate on processes and resources that would suggest configuration
control, but the CM disciplines seek to trim the process and include more
consistency in the resources, taking back attention to the goals of configuration
control. Common to other team members software tools are customized to the
processes.
CM is an assisting methodology for the Agile team, but there are
occasions in software design/development that work items are detailed for
preparation and documentation processing. Controlling change is the basis for
maintaining effective software design/development activities when change is in
the picture.

2
5

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

Teams can have a leaner concept in programs and projects by adapting

the Agile practices in the CM process by:
• Ensuring change is common with configuration
control objectives
• Having a clear distinction for changes to
requirements
• Embracing that change is possible with appropriate routines for
configuration activities
• Providing the development and enhancement
of Agile ideas

5.9 CAPABILITY MATURITY MODEL

INTEGRATION
 CMMI offers the best opportunity for consumers to address software
design or production with continuing help after delivery. The
design/development process may be a dynamic operation that supports the
accomplishment over the life cycle of the appropriate software tasks. When it
comes to software development, software development and processes involve
an interaction with each other. CMMI provides a systematic, disciplined
approach to all software engineering tasks within the program and projects
affected. Developing software work items using CMMI should improve the
software designers knowledge base.

To incorporate CMMI processes, they provide the performance material

for transition, development, deployment, integration, and maintenance during
the software life cycle. Complete software design practices provide basic
concepts (i.e., form, fit, function, interface, process of integration, etc.) and
other concepts of sound. Some CMMI-defined software engineering tasks are:

• The identification of internal and

external interfaces
• Software design to establish infrastructure abilities during software
design/development
• Development of plans, processes,
and procedures
• Reuse of capabilities for software
identified for use

With the software and programs implementing and using CMMI, this model
describes processes in two separate scenarios: Continuous and Staged. Every
organization should work towards a third level: established achievement. The
criteria for the processes refer to:

• Requirements
development
• Technical solution (see following
discussion)
• Product
integration
•
Veri
fica
tion

•
Va
lid
ati
 on

• Organizational
process focus
• Organizational
process definition
•
Organizationa
l training
• Integrated project
management
• Integrated supplier
management
• Risk
manage
ment
• Decision analysis
and resolution

2
6

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

• Organizational environment for

integration
•
Integrated
teaming

Software engineering techniques, along with mentioned strategies, have

the potential to incorporate several tasks and activities. When How much help
is required, the method is successful. Technical solution's development
process area can be the basis for software engineering to design, build and
implement solutions to software and system integration supporting
requirements. Processes that are related to this concept of process area
receive managed process requirements.
Technical solution processes help each other, and device life cycle-related
service items. A technical data kit offers full understanding for successful
design and implementation for the next step of integration activities for the
product design/development team.
5.9.1 CMMI
VERSION 1.3

In 2009 version 1.3 of CMMI was released. The release was to give
tech companies and military and aerospace programs and initiatives a new
approach to enhancing results in appraisals and training. Concentrating on:

• High
matur
ity
• More effective
processes
• Conducting and performing
effective appraisals
• Commonality in all
product suites

Implemented major elements allow assessment teams to be more effective

in reflecting high organizational maturity using a staged approach. The
behavior of high maturity were not understood and were vague, leading to
conflicting opinions by companies about how priorities are linked and
contributing to high rates. Modernized activities require changes to:

• Agile
environme
nts
• Functional requirements during software
design/development
• Subcontractor agreements pertaining to COTS (commercial off-the-shelf)
and NDI (non- development item) software
•
Organizationa
l training

CMMI version 1.3 coverage will add updated information currently

supported by Lean and Six Sigma as well as customer satisfaction for life-cycle
tasks in software design and development.

5.9.2 LEAN
SIX SIGMA

Lean and Six Sigma methods and philosophies have significantly

enhanced procedures, customer loyalty, timely production and other tangible
outcomes for thousands of tech companies and military and aerospace
programs and projects.

2
7

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

But do these same set of tools apply to the software design /

development processes? The answer is "yes" if the correct tools are used in
the correct manner and to the correct process.

The Six Sigma approach aims to reduce the variability of operations,

resulting in less mistakes and flaws. Consumer expectations describe a
software error, whether formally reported or an unmet expectation. In the
design/development process of the program, a flaw can be found by team
members or later when the consumer uses the delivered product. The Six
Sigma cycle in a software work product will display less defects per opportunity
or zero defects.

There is an array of possibilities for defects, including but not limited to

macro functional specifications that enable the end user to enter incorrect
data.

To achieve the zero-defect goal, team members must have highly

organized and reliable software life cycle processes for each stage. The steps
in Six Sigma are to: (1) Define, (2) Measure, (3) Analyze, and (4) Improve.

The control software teams mostly use one type of these requirements:
gathering, designing, implementing, testing, and maintaining. The
implementation of structured processes and the scope of programs are
customer criteria for providing effective methods for integration of software and
systems. Examination of the data flow and breakdown structures of apps
ensure less error chances. The Six Sigma philosophy is applied to building
quality through mistake- proofing methods during the software design /
development process. The development of successful maps of where and
where errors were found and code had to be revised, modified or reused will
help the team determine which measures in the process have the most
variance and are candidates for Six Sigma process improvement. The Lean
development of work products for software and system integration focuses on
removing waste from established processes. For the acronym DOWNTIME the
eight wastes are quickly remembered:

D
e
f
e
c
t
s

•
Overpr
oductio
n
•

W
a
i
t
i
n
g

•
Non-utiliz
ed talent
•
Transp
ortatio
n
•
In
v
e
nt
or
y
•

M
o
t
i
o
n
 • Excess
processin
g

Software design / development is a dynamic, waste-integrated process

that involves errors as addressed and leads to rework or reuse, which is
another waste for excess production. Waiting for waste happens when
programmers, project leaders and team members require information such as
customer requirements and code and unit test parameters that could delay
their development of software work products.
Also, excess waste processing occurs with numerous review cycles
rather than having a robust process for quality design and first time being
correct. An example of overproduction and inventory waste could be the
development of features which have not been requested or need not.

2
8

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

The Lean problem-solving methodology uses easy and straightforward

methods to produce fast and efficient results. Using the software
design/development process creates a process flow or a map of the value
stream showing each step. Look for any one of the eight waste as you walk the
process. Identify the "hidden plant" or activities that are performed routinely but
are not recorded or have no added value. When an operation does not affect
the application design or programming behavior of the software, then it is
waste. If the activity needs waste, such as reviews of any step consistency
gate code, reduce wasteful activity by creating a sound mechanism to
accomplish the task and eliminate rework or reuse. Once you've found waste
in your process flow, use a quick technique to drill down to the root cause.
Create a potential plan for the state to reduce or mitigate waste. Eventually,
process improvements are enforced, structured work items and system and
project leaders are put in place to track and ensure new processes are working
the way planned. Allow progress such that program success and mission
achievements are clear to ensure team leaders see progress and are
accountable for achieving their goals. Should not forget to track waste when
going forward, so that systems can be constantly enhanced. An example of
how simple it is to define, track and remove waste is a schedule showing the
amount of times a portion of code needs to be revised or reused.

The combination of Six Sigma's data-driven approach and Lean's waste

management tools streamlines the design / development cycle and delivers
better software in less time. The aim is to please the customers with excellent
goods and services for the job. During the life cycle of the software, creating a
defect- and waste-free process makes excellent programs and projects, and
the customer happy.

5.10 SOFTWARE
COMPANIES

Previously and currently, many software firms and military and

aerospace programs and projects build the concept of specializing in software
design / development to boost competitiveness in the software industry.
Through strong software and hardware many multinational businesses have
also gained ground to dominate the market. Countries have been competing in
software development for years, initially nurturing technicians with software
expertise.

5.10.1 SOFTWARE
DESGIN/DEVELOPMENT

Safe repositories related to information technology operated by

businesses, government testing centres, and even universities to provide
consumers with technology principles are the information design /
development opportunities. The specialist in information development offers
tailored consulting and services for corporations, government, and individual
and small businesses.

The lower limits of the program integration restrict the involvement of

the contractor. Technology companies have been rising the dollars to attract
business and profits. In the software design / development market, efficient
methods for software and systems integration activities inject benefit. Profits
will increase once consultation actions for software companies around the
world come into play.

2
9

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

MODULE 5:
ASSESSMENT

1. Compare and contrast Lean Method and Agile Method. Explain their
similarities, differences,
advantages and disadvantages. 2. If you are going to have your own
software company, what method would you use in
designing the software and why? You can use other method aside
from lean and agile.
 3
0

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

MODULE 6: SOFTWARE
IMPLEMENTATION

Intended Learning Outcomes 1. To identify the suitable test methods,

techniques, and metrics to provide a consistent
approach to effective
implementation activities.

6.1
INTROD
UCTION

The software implementation approach ensures that software

engineering projects work in target applications and systems environments as
planned and allows for smooth execution for testing and validation activities.
Disciplined principles of software implementation, planning, and system
building resources provide effective testing for software / system integration
environment to be conducted in a development facility. In a defined
documented Configuration Management Plan (CMP), software released under
Configuration Management Control is described to provide the necessary
requirements for software implementation inside integration facilities.

6.2 CONFIGURATION
MANAGEMENT

The department or company of configuration management software

maintains consistent implementation of configuration management activities
across the life cycle of software for work items which are created and managed
by programs and projects. The focus of the team is to identify and manage
changes, and maintain visibility of software configuration and documentation.
The idea of configuration management is a multifunctional mechanism applied
during the software development product life cycle and offers insight and
control over functional and physical attributes. The methods used during all
software design / development phases include the required disciplines for
defining relevant products, setting and monitoring baselines, and recording
and tracking changes to those basics. Configuration management processes
also control the storage, access, modifications, archiving, and release of work
products for the software. This team develops operating procedures which
define the processes needed to fulfil the requirements and guidance given
under associated and recorded plans.

6.2.1
BUILD
REQUEST

When software engineering builds are requested, electronic files or hard

copy paperwork is written to assemble, compile, link source code, build copies
of archives, and provide customers with listings for use in software design /
development, testing, and product delivery work.

Automatic build deployments are created to ensure customer trust in the

releases. Processes used by build engineers provide the ability to bundle
structures and documents together to make the software and projects effective.
Creating an approach to build and install processes requires coordination
between internal and external teams to become efficient and accessible when
supporting scheduled tests or configuration checkouts.

3
1

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

The construction engineer with the direction or authorization for a

requested engineering build has a specified role in performing software
building and configuration control tasks, including:

• Creates build folders to store documentation of

software building
• Provides source code changes and control of
the source code
• Maintains and controls records during program and project
development

6.3 CONFIGURATION
MANAGEMENT TOOLS

Active configuration management software systems are managed and

used to include version control and change management principles. The tools
(i.e., ClearCase and ClearQuest) may be used to provide the capabilities to
add new files to a software design/development environment and to monitor
versions of the existing folders and data.
 Table 6.1
Configuration
Management Tools

6.3.1 IBM RATIONAL

CLEARCASE

This software tool is an object-oriented database utility provided for the

archiving, automation, identification, version / change control, engineering
construction, product releases, status accounting, and auditing activities of
software products. The ClearCase software platform offers an open framework
for applying management and control systems for the application. Web site
material includes several different production environments for computer
software firms, the military and aerospace industries.

The Unified Change Management (UCM) framework blends tasks and

artifacts as seen in Figure 6.1.

3
2

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

Figure 6.1 Unified

change management
definition

Most systems and projects have different names for ClearCase

positions and assignments but the management of configurations should use
as an example:
 • Architect: Understands and sets up the system
architecture
• Configuration manager: Familiar with change and
control processes
• Lead: Responsible for schedules and
assignments
• Software design engineer: Makes changes to files under
configuration control
• Build engineer: Utilizes software build
concepts and tools

Table 6.2 defines the ClearCase—UCM roles, responsibilities, and main

objectives. When the folder becomes too large the files and folders can be
relocated or transferred to other VOBs. Also they can be divided and work
together. The architecture of ClearCase and the VOB database ensure file
checkout and support data recovery where necessary.

Table 6.2 ClearCase – UCM

Roles and Responsibilities

3
3

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE
 The ClearCase VOB structure example is
shown in Figure 6.2.

Figure 6.2
ClearCase
VOB
architecture

6.3.2 IBM RATIONAL

CLEARQUEST

The process of handling change requests is important when reporting

any requests from team members needed to alter or upgrade work items for
software and system integration. IBM Rational ClearCase comes into play with
IBM Rational ClearQuest, another Configuration Management (SCM) tool.

This program framework facilitates the processes of handling changes

in requests and is a complementary method for ClearCase. The database
utility is used for recording, tracking, and reporting and provides internal
access control mechanisms to allow work product updates to be restricted at
different stages of software design / development, integration and testing, and
production processes.
 Figure 6.3
Change
request
process

The proposal for change is a request made by team members to alter

an artifact or procedure. Documented in this type of request is the information
regarding any issues that may arise during software design/development and
impacts. Figure 6.3 provides an example of how the change request process
flows from initiation to closure.

3
4

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

The administrator of the modification request maintains a monitoring

system for managing improvement in the status of software code and software
documentation. The administrator maintains the database, schedules, and
provides software inputs for system and project changes to create traceability
to a higher-level software-impacted change authority. Computer plans and
process processes provide the details needed to manage the review boards
necessary to maintain documents, including the status of requests for changes,
reports and recorded releases.
This review board is set up to review and disposition changes for the
software teams that affect controlled software and related documentation. All
changes to the software are documented, approved and implemented on
request for modification. The review board meetings are scheduled and
organized by the chairperson of the review board who acts as the program or
project manager, member or appointed delegate.
The members of the review board comprise at least those from the
following areas:

• The affected
software teams
• Configuration
management
•

T
e
s
t
 • System
engineerin
g
•

Q
u
a
l
i
t
y

• Security (if change has an impact on classified or

trusted software)
•
Change
sponsor

The key tasks undertaken by the review board are reviews and
arrangements of proposals for change, assigning of goals, analysis of action
items, amend requirements from previous meetings, and identification of
inconsistencies that have occurred.

6.4
FUTURE
TRENDS

The information infrastructure and future developments for the

successful use of computing resources are significantly enhanced. There will
be time with the technology to discuss and fix the problems and changes
needed to:

• Software
design/development
• Software process definition and
enhancements
• Reuse of software program and
project artifacts
• Ongoing support of past
tool artifacts
• Training for software
design engineers
 • Software tool
disciplines

The software design/development utilizes SEE (software engineering

environment) technology to allow clear descriptions of the user's necessary
roles and responsibilities, and when the system and project organizations are
ready. The procurement of software tools should not be a solution for
displaying resources that are out of reach for software design / development
but that ensure processes are established for software development activities
management.

3
5

IT312 - SYSTEMS INTEGRATION AND

ARCHITECTURE

Effective software tools can enhance the design / development of software

and the quality produced, and increase the productivity of software and test
engineers. When implementation plans are well defined, the insertion of SEE
technology into the program and projects is successful.
The key argument for software tools and how to adapt them to
specifications should be focused around how such tools will handle design /
development implementation. Most software design / development tools will in
future help the life-cycle work items and the user-defined processes. The
biggest challenge would be maintaining and managing a consistent
development plan for applications, and adjusting to changes that occur.

6.4.1
TOOL
SUPPORT

When a program or project is ready for software tools that will be

effective during design/development, the key is to choose the right vendor
products to suit the engineering requirements. Questions are posed, and the
key steps are as follows for organizational needs:

• Become effective for designing and developing

work products
• Establish the resources for use of
software tools
• Conduct software implementation with
no problems
 •
Conduct
training

MODULE 6:
ASSESSMENT

1. What do you think are the keys or factors to have a successful software
implementation? 2. Why do you think future trends are important in dealing
with software implementation?

3
6