MBA management

System Engineering Concepts topics:

INTRODUCTION TO SYSTEM ENGINEERING


Almost 500 years ago, Machiavelli said, “There is nothing more difficult to take in hand, more perilous to conduct or more uncertain in its success, than to take the lead in the introduction of new order of things.” During the past 50 years, computer-based systems have introduced a new order. Although technology has made great strides since Machiavelli spoke, his words continue to ring true.

Software engineering occurs as a consequence of a process called system engineering. Instead of concentrating solely on software, system engineering focuses on a variety of elements, analyzing, designing, and organizing those elements into a system that can be product, a service, or a technology for the transformation of information or control.

The system engineering process takes on different forms depending on the application domain in which it is applied. Business process engineering is conducted when the context of the work focuses on a business enterprise. When a product (in this context, a product includes everything from a wireless telephone to an air traffic control system) is to be built, the process is called product engineering.

Both business process engineering and product engineering attempt to bring order to the development of computer-based systems, although each is applied in a different application domain, both strive to put software into context. That is, both business process engineering and product engineering work to allocate a role for computer software and, at the same time, to establish the links that tie software to other elements of a computer- based system. In reality, the term system engineering is often used in this context. However, for the purpose of this book, system engineering is generic and is used to encompass both business process engineering and product engineering.

Both business process engineering and product engineering t to bring order to thee development of computer-based systems, although each is applied in a different application domain, both strive to put software into context. That is, both business process engineering and product engineering work to allocate a role for computer software and, at the same time, to establish the links that tie software to other elements of a computer-based system. In reality, the term system engineering is often used in this context. However, for the purposes of this book, system engineering is generic and is used to encompass both business process engineering and product engineering.

In this chapter, we focus on the management issues and the process-specific activities that enable a software organization to ensure that it does the right things at the right time in the right way.

What is it?
Before software can be engineered, the “System” in which it resides must be understood. To accomplish this, the overall objective of the system must be determined; the role of hardware, software, people, database, procedures, and other system elements must be identified; and operational requirements must be elicited, analyzed, specified, modeled, validated and managed. These activities are the foundation of system engineering.

What does it?
A system engineer works to understand system requirements by working with the customer, future users and other stakeholders.

Why is important?
There is an old saying:” You can’t see the forest for the trees.” In this context, the “forest“ is the system, and the trees are the technology elements (including software) That are required to realize the system. If you rush to build technology elements before you understand the system, you’ll undoubtedly make mistakes that will disappoint your customer. Before you worry about the trees, understand the forest.

What are the steps?
Objectives and more detailed operational requirements are identified by eliciting information from thee customer: requirements are analysed to assess their clarity, completeness and consistency: a specification, often incorporating a system model, is created and then validated by both practitioners and customers. Finally, system requirements are managed to ensure that changes are properly controlled.

What is the work product?
An effective representation of the system must be produced as a consequence of system engineering. This can be a prototype, a specification or even a symbolic model, but it must communicate the operational, functional and behavioral characteristics of the system to be built and provide insight into the system architecture.

How do I ensure that I’ve done it right?
Review all system engineering work products for clarity, completeness and consistency. As important, except changes to the system requirements and manage them using solid change management.

COMPUTER-BASED SYSTEMS


The word system is possibly the most overused and abused term in the technical lexicon. We speak of political systems and educational systems, of avionics systems and manufacturing systems, of banking systems and subway systems. The word tells us little. We used the adjective describing system to understand the context in which the word is used. Webster’s Dictionary defines system in the following way:

1. A set or an arrangement of things so related as to form a unity or organic whole;

2. A set of facts, Principles, rules, etc., classified and arranged in an orderly from so as to show a logical plan linking the various parts;

3. A method or plan of classification or arrangement;

4. An established way of doing something; method procedure…

Five additional definitions are provided in the dictionary, yet no precise synonym is suggested. System is a special word. Borrowing from Webster’s definition, we define a computer- based system as:

A set or arrangement of elements that are organized to accomplish some predefined goal by processing information.

The goal may be to support some business function or to develop a product that can be sold to generate business revenue. To accomplish the goal, a computer-based system makes use of a variety of system elements:

Software:
Computer programs, data structures, and related work products that serve to effect the logical method, procedure, or control that is required.

Hardware:
Electronic devices that provide computing capability, the inter connectivity devices (e.g., network switches, telecommunications devices) that enable the flow of data, and electromechanical devices (e.g., sensors. Motors, pumps) that provide external world function.

People:
Users and operators of hardware and software.

Database:
A large, organized collection of information that is accessed via software and persists over time.

Documentation:
Descriptive information (e.g., models, specifications, hardcopy manuals, on-line help files, web sites) that portrays the use and/or operation of the system.

Procedure:
The steps that define the specific use of each system element or the procedural context in which the system resides.

These elements combine in a variety of ways to transform information. For example, a marketing department transforms raw sales data into a profile of the typical purchaser of a product; a robot transforms a command file containing specific instructions into a set of control signals that cause some specific physical action. Creating an information system to assist the marketing department and control software to support the robot both require system engineering.

Steve Wozniak: “Never trust a computer you can’t throw out of a window.”

One completing characteristic of computer-based system is that the elements constituting one system may also represent one macro element of a still larger system. The macro element is a computer based system that is one part of a larger computer-based system. As an example, we consider a factory automation system that is essentially a hierarchy of systems. At the lowest level of the hierarchy we have a numerical control machine, robots, and data entry devices. Each is a computer-based system in its own right. The elements of the numerical control machine include electronic and electromechanical hardware (e.g., processor and memory, motors, sensors), software (for communications and machine control), people (the machine operator), a database (the stored NC program), documentation, and procedures. A similar decomposition could be applied to the robot and data entry device. Each is a computer-based system.

At the next level in the hierarchy, a manufacturing cell is defined. The manufacturing cell is a computer- based system that may have elements of its own (e.g., computers, mechanical fixtures) and also integrates the macro elements that we have called numerical control machine, robot, and data entry device.

To summarize, the manufacturing cell and its macro elements each is compared of system elements with the generic labels: software, hardware, people, database, procedures, and documentation. In some cases, macro elements may share a generic element. For example, the robot and the NC machine both might be managed by a single operator (the people element). In other cases, generic elements are exclusive to one system.

The role of the system engineer is to define the elements for a specific computer- based system in the context of the overall hierarchy of systems (macro elements). In the sections that follow, we examine the tasks that constitute computer system engineering.

From the above discussion it can be safely concluded that a high-technology system encompasses a number of elements: software, hardware, people, database, documentation, and procedures. System engineering helps to translate a customer’s need into a model of a system that makes use of one or more of these elements .In fact the concept of system engineering can be fitted into any of the other engineering disciplines as is indicated below.

System engineering begins by taking a “world view”. A business domain or product is analyzed to establish all basic business requirements. Focus is then narrowed to a “domain view,” where each of the system elements is analysed individually. Each element is allocated to one or more engineering components, which are then addressed by the engineering discipline.

Business process engineering is a system engineering approach that is used to define architectures that enable a business to use information effectively. The intent of business process engineering is to derive comprehensive data architecture, application architecture and technology infrastructure that will meet the needs of thee business strategy and the objectives and gals of each business area.

Product engineering is a system engineering approach that begins with system analysis. The system engineering identifies the customer’s needs, determines economic and technical feasibility and allocates function and performance to software, hardware, people, and database- the key engineering components.

DESIGN


Design has been described as a multistep process in which representations of data and program structure, interface characteristics, and procedural detail are synthesized from information requirement. This description is extended by Freeman.

Design is an activity concerned with making major decisions, often of s structural nature. It shares with programming a concern for abstracting information representation and processing sequences, but the level of detail is quite different at the extremes. Design builds coherent and well- planned representations of programs that concentrate on the interrelationships of parts at the higher level and the logical operations involved at the lower levels…

The Design is information driven. Software design methods are derived from consideration of each of the three domains of the analysis model. The informational, functional, and behavioural domains serve as a guide for the creation of the software design.

Methods required to create “coherent, well planned representations” of the data and architectural layers of the design model are presented in this chapter. The objective is to provide a systematic approach for the derivation of the architectural design- the preliminary blueprint from which software is constructed.

What is it?
Architectural design represents the structure of data program components that are required to build a computer- based system. It considers the architectural style that the system will take, the structure and properties of the components that constitute the system, and the interrelationships that occur among all architectural components of a system.

What does it?
Although a software engineer can design both data and architecture, the job is often allocated to specialists when large and complex systems are to be built. A database or data warehouse designer creates the data architecture for a system. The “system architect” selects an appropriate architectural style for the requirements derived during system engineering and software requirements analysis.

Why is it important?
You would not attempt to build a house without a blueprint, would you? You also would not begin drawing blueprints by plumbing layout for the house. You would need to look at the big picture- the house itself-before you worry about details. That is what architectural design- it provides you with the big picture and ensures that you have got it right.

What are the steps?
Architectural design begins with data design and then proceeds to the derivation of one or more representations of the architectural structure of the system. Alternative architectural styles or patterns are analysed to derive the structure that is best suited to customer requirements and quality attributes. Once an alternative has been selected, the architecture is elaborated using an architectural design method.

What is the work product?
An architecture model encompassing data architecture and program structure is created during architectural design. In addition, component properties and relationship (interactions) are described.

How do I ensure that I’ve done it right?
At each stage, software design work products are reviewed for clarity, correctness, completeness, and consistency with requirements and with one another.

SOFTWARE ARCHITECTURE


In this landmark book on the subject, Show and Garden discuss software architecture in the following manner.

Ever since the first program was divided into modules, software system have had architectures. Ad programmers have even responsibility for the interactions among the modules and thee global properties of the assemblage. Historically, architectures have been implicit- accidents of implementation, or legacy systems of the past. Good software developers have been implicit- accidents of implementation, or legacy systems of the past. Good software developers have often adopted one or several architectural patterns as strategies for system organization, but they us these patterns informally and have no mans to make them explicit in the resulting system.

Today effective software architecture and its explicit representation and design have become dominant themes in software engineering.

Jerrold Grochow: “The architecture of a system is a comprehensive framework that describes its form and structure- its components and how they fit together.”

What is Architecture?


What we discuss the architecture of a building, many different attributes come to mind. At the most simplistic level, we consider the overall shape of the physical structure. But in reality, architecture is much more. It is the manner in which the various components of the building are integrated to form a cohesive whole. It is the way in which the building fits into its environment and meshes with other buildings in its vicinity. It is the degree to which the building meets its stated purpose and satisfies the needs of its owner. It is the aesthetic feel of the structure- the visual impact of the building and the way textures, colors, and materials are combined to create the external façade and the internal “Living environment.” It is small details- the design of lighting fixtures, the type of flooring, the placement of wall hangings, and the list is almost endless. And finally, it is art.

But what about software architecture? Bass, Clements, and Kazman define this elusive term in the following way:

The software architecture of a program or computing system is the structure of structures of the system, which comprise software components, the externally visible properties of those components, and the relationship among them.

The architecture is not the operational software. Rather, it is a representation that enables a software engineer to (1) analyze the effectiveness of the design in meeting its stated requirements, (2) Consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software.

Barry Boehm: “Marry your architecture in haste, report at your leisure.”

This definition emphasizes the role of “software components” in any architectural representation. In the context of architecture design, a software component can be something as simple as a program module or an object- oriented class, but it can also be extended to include databases and “middleware” that enable the configuration of a network of clients and servers.

In this book the design of software architecture considers two levels of the design pyramid – data design and architecture design. In the context of the preceding discussion, data design enables us to represent data component of the architecture in conventional systems and class definitions (encapsulating attributes and operations) in object- oriented systems. Architectural design focuses on the representations attributes and operations) in object- oriented systems. Architectural design focuses on thee representations of the structure of software components, their properties, and interactions.

Why is Architecture Important?


In a book dedicated to software architecture, Bass and his colleagues identify three key reasons why software architecture is important.

• Representation of software architecture are an enable for communication between all parties (stakeholders) interested in the development of a computer – based system.

• The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.

• Architecture “constitute a relatively small, intellectually graspable model of how the system is structured and how its components work together.”

The architecture design model and the architectural patterns contained within it are transferable. That is, architecture styles and patterns can be applied to the design of other systems and represent a set of abstractions that enable software engineers to describe architecture in predictable ways.

Type of Software Architecture

Type of architecture   Examples of elements   Examples of relationships
conceptual   components   connectors
module   Sub-systems, modules   Exports, imports
code   Files, directories, libraries   Includes, contains
Execution   Tasks, threads, objects interactions   Uses, calls


In terms of object-oriented development, the conceptual architecture is concerned with the structure of the static class model and the connection between the components of the model. The model architecture describes the way the system is divided in to the sub- systems or modules and how they communicate by exporting and importing data. The code architecture defines how the programme code is organized into files and directories and grouped into libraries. The execution architecture focuses on the dynamic aspects of the system and the communication between components as tasks and operations executed.

There are alternative ways of delineating different aspects of architecture. For example, a logical architecture might comprise the class model, while a physical architecture is concerned with mapping the software onto the hardware components. However, it all classes these different aspects combine to define a software architecture for the system. There are various architecture styles. Each of which has characteristics that make it more or less system. There are various architecture styles, each of which has characteristics that make it more or less suitable for various architecture styles, each of which has characteristics that make it more or less suitable for certain types of application. We will consider some of the major alternatives.

Architectural patterns: If a house builder to construct a center- hall colonial, there is a single architectural style that can be applied. The details of the style (e.g., number of fireplaces, façade of the house, placement of doors and windows0 can vary considerably, but once the decision on the overall architecture of the house is made, thee style is imposed on the design. This implies that there will be a central foyer and hallway, that rooms will be placed to the left and right of the foyer, that the house will have two( or more) stories, that the bedrooms of the house will be upstairs, and so on. These “rules” are imposed once the decision is mad to use the center hall colonial style.

Architectural patterns are a bit different. It is important to note that there is no universal agreement on this terminology. Some people, (for example, use thee terms style and patterns synonymously, while others make the subtle distinction suggested in this section. For example, every house (and every architectural style for houses employs a kitchen pattern. The Kitchen pattern defines the need for placement of basic kitchen appliances, the need for a sink, the need for cabinets, and possibly, rules for placement of these things relative to workflow in the room. In addition, the pattern might specify the need for counter tops, lighting, wall switches, a central island, flooring, and so on. Obviously, there is more than a single design for a kitchen, but every design can be conceived within the context of the “solution” suggested by the kitchen pattern.

As we have already noted, architectural patterns for software define a specific approach for handling some behavioural characteristic of the system. Bosch defines a number of architectural pattern domains. Representative examples are provided in the paragraphs that follow.

Concurrency: Many applications must handle multiple tasks in a manner that simulates parallelism (i.e., this occurs whenever multiple ‘parallel” tasks or components are managed by a single processor). There are a number of different ways in which an application can handle concurrency, and each can be presented by a different architectural pattern. For example, one approach is to use an operations system process management pattern that provides built-in OS functionality that allow components to execute concurrently. The pattern also incorporates OS functionality that manages communication between processes, scheduling, and other capabilities required to achieve concurrency. Another approach might be to define a task scheduling, and other capabilities required to achieve concurrency. Another approach might be to define a task scheduling, and other capabilities required to achieve concurrency. Another approach might be to define a task scheduler at the application level. A task scheduler pattern contains a set of active objects that each contains a tick operation. The scheduler periodically invokes tick for each object, which then performs the functions it must perform before returning control back to the scheduler, which then invokes the tick operation for the next concurrent object.

Persistence: Data persists if it survives past the execution of the process that created it. Persistent data are stored in a database or file and may be read or modified by other processes at a later time. In objective- oriented environments, the idea of a persistent object extends the persistence concept a bit further. The values of all of the object’s attributes, the general state of the object, and other supplementary information are stored for future retrieval and use. In general, two architectural patterns are used to achieve persistence- a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture or an application level persistence pattern that builds persistence features into the applications architecture (e.g., word processing software that manages its own document structure).

Distribution: The distribution problem addresses the manner in which systems or components within system communicate with one another in a distributed environment. There are two elements to this problem: (1) the way in which entities connect to one another, and (2) the nature of the communication that occurs. The most common architectural pattern established to address the distribution problem is the broker pattern. A broker acts a “middle-man” between the client components. The client sends a message to the broker (containing all appropriate information for the communication to be effected), and the broker completes the connection.

Before any one of the architectural patterns noted in the preceding paragraphs can be chosen, it must be assessed for its appropriateness for the application and the overall architectural style, as well as its maintainability, reliability, security, and performance.

Organization and refinement


Because the design process often leaves a software engineer with a number of architectural alternatives, it is important to establish a set of design criteria that can be used to assess an architectural design. The following questions provide an insight into the architectural style that has been derived.

Control: How is control managed within the architecture? Dos a distinct control hierarchy exist, and if so, what is the role of components within this control hierarchy? How do components transfer control within the system? How is control shared among components? What is the control topology (i.e., the geometric from that the control takes)? Is control synchronized or do components operate asynchronously?

Data: How are data communicated between components? Is the flow of data continuous, or are data objects passed to the system sporadically? What is the mode of data transfer (i.e., are data passed from one component to another or are data available globally to be shared among system components)? Do data components (e.g., a blackboard or repository) exist, and if so, what is their role? How do functional components interact with data component? Are data components passive or active (i.e., do the data components activity interact with other components in the system)? How do data and control interact within the system?

These questions provide the designer with an early assessment of design quality and lay the foundation for more detailed analysis of the architecture.

DATA DESIGN


The data design action translates data objects defined as part of the analysis model into data structures at the software component level and when necessary, a database architecture at the application level. In some situations, a database must be designed and built specifically for a new system. In others, however, one or more existing database are used.

Data design (sometimes referred to as data architecting) creates a model of data and/or information that is represented at a high level of abstraction ( the customer/user’s view of data). This data model is then refined into progressively more implementation - specific representations that can be processed by the computer – based system. In many software applications, the architecture of the data will have a profound influence on the architecture of the software that must process it.

The structure of data has always been an important part of software design. At the program component level, the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications. At the application level, the translation of a data model (derived as part of requirements engineering) into a database is pivotal to achieving the business objectives of a system. At the business level, the collection of information stored in disparate databases and reorganized into a “data warehouse” enables data mining or knowledge discovery that can have an impact on the success of the business itself. In every case, data design plays an important role.

Data Design at the Architectural Level


Today, businesses large and small are wash in data. It is not unusual for even a moderately sized business to have dozens of databases serving many applications encompassing hundreds of gigabytes of data. The challenge is to extract useful information from this data environment, particularly when the information desired is cross-functional (e.g., information that can be obtained only if specific marketing data are cross- correlated with product engineering data).

Architectural Design and Styles


The architectural design for software is the equivalent to the floor plan of a house. The floor plan depicts the overall layout of the rooms, their size, shape, and relationship to one another, and the doors and windows that allow movement into and out of the rooms. The floor plan gives us an overall view of the house. Architectural design elements give us an overall view of the software.

The architectural model is derived from three sources; (1) information about the application domain for the software to be built; (2) specific analysis elements such as data flow diagrams or analysis classes, their relationship and collaborations for the problem at hand and (3) the availability of architectural patterns.

Although millions of computer- based systems have been created over the past 50 years, the vast majority can be categorized into one of a relatively small number of architectural styles.

Data-centered architecture: A data- centered architecture promotes integrability. That is, existing components can be changed and new client components added to the architecture without concern about other clients (because the client components operate independently). In addition, data can be passed among clients using the blackboard mechanism (i.e., the blackboard component serves to coordinate the transfer of information between clients). Clients’ components independently execute processes.

Object-oriented architecture: The components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components is accomplished via message passing.

MODELING


We create models to gain a better understanding of the actual entity to be built. When the entry is a physical thing (e.g., a building, a plane, a machine), we can build a model that is identical inform and shape but smaller in scale. However, when the entity is software, our model must take a different form. It must be capable of representing the information that software transforms, the architecture and functions that enable the transformation to occur, the features that the users desire, and the behavior of the system as the transformation is taking place. Models must accomplish these objectives at different levels of abstractions- first depicting the software from the customer’s viewpoint and later representing the software at a more technical level.

In software engineering work, two classes of models are created: analysis models and design models. Analysis models represent the customer requirements by depicting the software in three different domains; the information domain, the functional domain, and the behavioural domain. Design models represent characteristics of the software that help practitioners to construct it effectively.

Component-level design


The component level design for software is equivalent to a set of detailed drawings (and specifications) for each room in a house. These drawings depict wiring and plumbing within each room, the location of electrical receptacles and switches, faucets, sinks, showers, tubs, drains, cabinets, and closets. They also describe the flooring to be used, the moldings to be applied, and every other detail associated with a room. The component level design for software fully describes the internal detail of each software component. To accomplish this, the component level design defines data structures for all local data objects and algorithmic details for all processing that occurs within a component and an interface that allows accesses to all component operations (behaviours).

The Conventional View

In the context of conventional software engineering, a component is a functional element of program that incorporates processing logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it. A conventional component, also called a module, resides within the software architecture and serves one of three important roles as: (1) a control component that coordinates the invocation of all other problem domain components (2) a problem domain component that implements a complete or partial function that is required by the customer, or (3) an infrastructure component that is responsible for functions that support the processing required in the problem domain.

Like object- oriented components, conventional software components are derived from the model. In this case, however, thee data flow-oriented element of thee analysis model serves as the basis for the derivation. Control components tend to reside toward the bottom of the hierarchy. To achieve effective modularity, design concept like functional independence are applied as components are elaborated.

John gall: “a G Complex system that works is invariably found to have evolved from a simple system that worked.”

Designing Class-Based Components


As we have already noted, component- level design draws on information developed as part of the analysis model and represented as part of the architectural model. when an object- oriented software engineering approach is chosen , component- level design focuses on the elaboration of analysis classes ( problem domain specific classes), and the definition and refinement of infrastructure classes. The detailed description of the attributes, operations, and interfaces used by these classes is the design detail required as a precursor to the construction activity.
Copyright © 2015 Mbaexamnotes.com         Home | Contact | Projects | Jobs

Review Questions
  • 1. What is system engineering? Discuss the various types of software architecture.
  • 2. What is data design? Discuss it in relation to software architecture.
  • 3. Explain the various modeling options under the software engineering practices.
  • 4. What is component level design? Discuss the various data structures with respect to component design.
  • 5. What is architecture? Why is it important in software engineering studies?
  • 6. Explain and describe the various architectural patterns. What is organization and refinement in the study of these patterns?
Copyright © 2015 Mbaexamnotes.com         Home | Contact | Projects | Jobs

Related Topics
System Engineering Concepts Keywords
  • System Engineering Concepts Notes

  • System Engineering Concepts Programs

  • System Engineering Concepts Syllabus

  • System Engineering Concepts Sample Questions

  • System Engineering Concepts Subjects

  • EMBA System Engineering Concepts Subjects

  • System Engineering Concepts Study Material

  • BBA System Engineering Concepts Study Material