Practical applications approach to design,development and implemetation of an integrated management

数字示波器外文翻译文献(文档含中英文对照即英文原文和中文翻译)原文:Design and FPGA implementation of a wireless hyperchaotic communication system for secure real-time image transmission AbstractIn this paper, we propose and demonstrate experimentally a new wireless digital encryption hyperchaotic communication system based on radio frequency (RF) communication protocols for secure real-time data or image transmission. A reconfigurable hardware architecture is developed to ensure the interconnection between two field programmable gate array developmentplatforms through XBee RF modules. To ensure the synchronization and encryption of data between the transmitter and the receiver, a feedback masking hyperchaotic synchronization technique based on a dynamic feedback modulation has been implemented to digitally synchronize the encrypter hyperchaotic systems. The obtained experimental results show the relevance of the idea of combining XBee (Zigbee or Wireless Fidelity) protocol, known for its high noise immunity, to secure hyperchaotic communications. In fact, we have recovered the information data or image correctly after real-time encrypted data or image transmission tests at a maximum distance (indoor range) of more than 30 m and with maximum digital modulation rate of 625,000 baud allowing a wireless encrypted video transmission rate of 25 images per second with a spatial resolution of 128 ×128 pixels. The obtained performance of the communication system is suitable for secure data or image transmissions in wireless sensor networks.IntroductionOver the past decades, the confidentiality of multimedia communications such as audio, images, and video has become increasingly important since communications of digital products over the network (wired/wireless) occur more frequently. Therefore, the need for secure data and transmission is increasing dramatically and defined by the required levels of security depending on the purpose of communication. To meet these requirements, a wide variety of cryptographic algorithms have been proposed. In this context, the main challenge of stream cipher cryptography relates to the generation of long unpredictable key sequences. More precisely, the sequence has to be random, its period must be large, and the various patterns of a given length must be uniformly distributed over the sequence. Traditional ciphers like DES, 3DES, IDEA, RSA, or AES are less efficient for real-time secure multimedia data encryption systems and exhibit some drawbacks and weakness in the high streamdata encryption. Indeed, the increase and availability of a high-power computation machine allow a force brute attack against these ciphers. Moreover, for some applications which require a high-levelcomputation and where a large computational time and high computing power are needed (for example, encryption of large digital images), these cryptosystems suffer from low-level efficiency. Consequently, these encryption schemes are not suitable for many high-speed applications due to their slow speed in real-time processing and some other issues such as in the handling of various data formatting. Over the recent years, considerable researches have been taken to develop new chaotic or hyperchaotic systems and for their promising applications in real-time encryption and communication. In fact, it has been shown that chaotic systems are good candidates for designing cryptosystems with desired properties. The most prominent is sensitivity dependence on initial conditions and system parameters, and unpredictable trajectories.Furthermore, chaos-based and other dynamical systembased algorithms have many important properties such as the pseudorandom properties, ergodicity and nonperiodicity. These properties meet some requirements such as sensitivity to keys, diffusion, and mixing in the cryptographic context. Therefore, chaotic dynamics is expected to provide a fast and easy way for building superior performance cryptosystems, and the properties of chaotic maps such as sensitivity to initial conditions and random-like behavior have attracted the attention to develop data encryption algorithms suitable for secure multimedia communications. Until recently, chaotic communication has been a subject of major interest in the field of wireless communications. Many techniques based on chaos have been proposed such as additive chaos masking (ACM), where the analog message signal is added to the output of the chaos generator within the transmitter. In, chaos shift keying is used where the binary message signal selects the carrier signal from two or more different chaotic attractors. Authors use chaotic modulation where the message information modulates a parameter of the chaotic generator. Chaos control methods rely on the fact that small perturbations cause the symbolic dynamics of a chaotic system to track a prescribed symbol sequence. In, the receiver system is designed in an inverse manner to ensure the recovery of theencryption signal. An impulsive synchronization scheme is employed to synchronize chaotic transmitters and receivers. However, all of these techniques do not provide a real and practical solution to the challenging issue of chaotic communication which is based on extreme sensitivity of chaotic synchronization to both the additive channel noise and parameter mismatches. Precisely, since chaos is sensitive to small variations of its initial conditions and parameters, it is very difficult to synchronize two chaotic systems in a communication scheme. Some proposed synchronization techniques have improved the robustness to parameter mismatches as reported in, where impulsive chaotic synchronization and an open-loop-closed-loopbased coupling scheme are proposed, respectively. Other authors proposed to improve the robustness of chaotic synchronization to channel noise, where a coupled lattice instead of coupled single maps is used to decrease the master-slave synchronization error. In, symbolic dynamics-based noise reduction and coding are proposed. Some research into equalization algorithms for chaotic communication systems are also proposed. For other related results in the literature, see. However, none of them were tested through a real channel under real transmission conditions. Digital synchronization can overcome the failed attempts to realize experimentally a performed chaotic communication system. In particular, when techniques exhibit any difference between the master/transmitter and slave/receiver systems, it is due to additive information or noise channel (disturbed chaotic dynamics) which breaks the symmetry between the two systems, leading to an accurate non-recovery of the transmitted information signal at the receiver. In, an original solution to the hard problem of chaotic synchronization high sensibility to channel noise has been proposed. This solution, based on a controlled digital regenerated chaotic signal at the receiver, has been tested and validated experimentally in a real channel noise environment through a realized wireless digital chaotic communication system based on zonal intercommunication global-standard, where battery life was long, which was economical to deploy and which exhibited efficient use of resources, knownas the ZigBee protocol. However, this synchronization technique becomes sensible to high channel noise from a higher transmission rate of 115 kbps, limiting the use of the ZigBee and Wireless Fidelity (Wi-Fi) protocols which permit wireless transmissions up to 250 kbps and 65 Mbps, respectively.Consequently, no reliable commercial chaos-based communication system is used to date to the best of our knowledge. Therefore, there are still plentiful issues to be resolved before chaos-based systems can be put into practical use. To overcome these drawbacks, we propose in this paper a digital feedback hyperchaotic synchronization and suggest the use of advanced wireless communication technologies, characterized by high noise immunity, to exploit digital hyperchaotic modulation advantages for robust secure data transmissions. In this context, as results of the rapid growth of communication technologies, in terms of reliability and resistance to channel noise, an interesting communication protocol for wireless personal area networks (WPANs, i.e., ZigBee or ZigBee Pro Low-Rate-WPAN protocols) and wireless local area network (WLAN, i.e., Wi-Fi protocol WLAN) is developed. These protocols are identified by the IEEE 802.15.4 and IEEE 802.11 standards and known under the name ZigBee and Wi-Fi communication protocols, respectively. These protocols are designed to communicate data through hostile Radio Frequency (RF) environments and to provide an easy-to-use wireless data solution characterized by secure, low-power, and reliable wireless network architectures. These properties are very attractive for resolving the problems of chaotic communications especially the high noise immunity property. Hence, our idea is to associate chaotic communication with theWLAN or WPAN communication protocols. However, this association needs a numerical generation of the chaotic behavior since the XBee protocol is based on digital communications.In the hardware area, advanced modern digital signal processing devices, such as field programmable gate array (FPGA), have been widely used to generate numerically the chaotic dynamics or the encryption keys. The advantage of these techniques is that the parameter mismatch problem does not existcontrary to the analog techniques. In addition, they offer a large possible integration of chaotic systems in the most recent digital communication technologies such as the ZigBee communication protocol. In this paper, a wireless hyperchaotic communication system based on dynamic feedback modulation and RF XBee protocols is investigated and realized experimentally. The transmitter and the receiver are implemented separately on two Xilinx Virtex-II Pro circuits and connected with the XBee RF module based on the Wi-Fi or ZigBee protocols. To ensure and maintain this connection, we have developed a VHSIC (very high speed integrated circuit) hardware description language (VHDL)-based hardware architecture to adapt the implemented hyperchaotic generators, at the transmitter and receiver, to the XBee communication protocol. Note that the XBee modules interface to a host device through a logic-level asynchronous serial port. Through its serial port, the module can communicate with any logic and voltage-compatible Universal Asynchronous Receiver/Transmitter (UART). The used hyperchaotic generator is the well-known and the most investigated hyperchaotic Lorenz system. This hyperchaotic key generator is implemented on FPGA technology using an extension of the technique developed in for three-dimensional (3D) chaotic systems. This technique is optimal since it uses directly VHDL description of a numerical resolution method of continuous chaotic system models. A number of transmission tests are carried out for different distances between the transmitter and receiver. The real-time results obtained validate the proposed hardware architecture. Furthermore, it demonstrates the efficiency of the proposed solution consisting on the association of wireless protocols to hyperchaotic modulation in order to build a reliable digital encrypted data or image hyperchaotic communication system.Hyperchaotic synchronization and encryption techniqueContrary to a trigger-based slave/receiver chaotic synchronization by the transmitted chaotic masking signal, which limits the performance of the rate synchronization transmission, we propose a digital feedback hyperchaoticsynchronization (FHS). More precisely, we investigate a new scheme for the secured transmission of information based on master-slave synchronization of hyperchaotic systems, using unknown input observers. The proposed digital communication system is based on the FHS through a dynamic feedback modulation (DFM) technique between two Lorenz hyperchaotic generators. This technique is an extension and improvement of the one developed in for synchronizing two 3D continuous chaotic systems in the case of a wired connection.The proposed digital feedback communication scheme synchronizes the master/transmitter and the slave/receiver by the injection of the transmitted masking signal in the hyperchaotic dynamics of the slave/receiver. The basic idea of the FHS is to transmit a hyperchaotic drive signal S(t) after additive masking with a hyperchaotic signal x(t) of the master (transmitter) system (x , y , z ,w ). Hyperchaotic drive signal is then injected both in the three subsystems (y , z ,w ) and (r r r w z y ,,). The subscript r represents the slave or receiver system (r r r r w z y x ,,,). At the receiver, the slave system regenerates the chaotic signal )(t x r and a synchronization is obtained between two trajectories x(t) and )(t x r if()()0||lim =-∞→t X t X r t (1) This technique can be applied to chaotic modulation. In our case, it is used for generating hyperchaotic keys for stream cipher communications, where the synchronization between the encrypter and the decrypter is very important. Therefore, at the transmitter, the transmitted signal after the additive hyperchaos masking (digital modulation) isS(t) = x(t) + d(t). (2)where d(t) is the information signal and x(t) is the hyperchaotic carrier. At the receiver, after synchronization of the regenerated hyperchaotic signal )(t x rwith the received signal )(t S r and the demodulation operation, we can recover the information signal d(t) correctly as follows:)()()(t x t S t d r r -=. (3)Therefore, the slave/receiver will generate a hyperchaotic behavior identical to that of the master/transmitter allowing to recover correctly the information signal after the demodulation operation. The advantageof this technique is that the information signal d(t) doesnot perturb the hyperchaotic generator dynamics, contraryto the ACM-based techniques of and, because d(t) is injected at both the master/transmitter and slave/receiver after the additive hyperchaotic masking. Thus, for small values of information magnitude, the information will be recovered correctly. It should be noted that we have already confirmed this advantage by testing experimentally the HS-DFM technique performances for synchronizing hyperchaotic systems (four-dimensional (4D) continuous chaotic systems) in the case of wired connection between two Virtex-II Pro development platforms. After many experimental tests and from the obtained real-time results, we concluded that the HS-DFM is very suitable for wired digital chaotic communication systems. However, in the present work, one of the objectives is to test and study the performances of the HS-DFM technique in the presence of channel noise through real-time wireless communication tests. To performthe proposed approach, a digital implementation of the master and slave hyperchaotic systems is required. Therefore, we investigate the hardware implementation of the proposed FHS-DFM technique between two Lorenz hyperchaotic generators using FPGA. To achieve this objective, we propose the following details of the proposed architecture.译文:无线超混沌通信系统安全的实时图像传输的设计和FPGA实现摘要在本文中，我们提出并论证了一种基于无线电频率通信协议对数据或图像安全实时传输的新的无线数字超混沌加密通信系统。

Dissolution (Acids Chemistry) (Acid Classification In Digestion Reactions)
General Rules For Usage Of Perchloric Acid Do not use it Use only very diluted perchloric acid Mix it with other acids (but never with sulfuric acid) Never exceed 200° C Use it only to perform a two-step digestion Perchloric acid is normally not required for the closed vessel microwave digestion of organic samples

Cleaning Containers
A cleaning procedure is easily evaluated by grinding and analyzing a known sample, or even by checking the impurities appearing in successive batches of ground quartz sand. grinding containers become more difficult to clean with age because of progressive pitting and scratching of the grinding surfaces.

Cleaning Containers
For more thorough cleaning one may grind one or more batches of pure quartz sand, and then wash the container thoroughly. In extreme cases, such as the plating of container wall with a malleable metal, chemical cleaning or multiple grinds with quartz may be necessary.

Presenter(s):Carol Diane KlinglerTitle: A Practical Approach to Process DefinitionTrack:Process Improvement Track-SP1Day:TuesdayKeywords:process definition, process modeling, IDEF0A P RACTICAL A PPROACH TO P ROCESS D EFINITION1.I NTRODUCTIONWell-defined processes are critical for producing high-quality software on schedule and within budget. Well-defined processes also facilitate communication within software develop-ment teams, training of new personnel, management, and process improvement. Process defini-tion is a Key Process Area at level three of the Software Engineering Institute’s Capability Maturity Model [Hum89] and is a critical activity at all levels of capability maturity. There is little practical guidance available on ways to create well-defined processes. Traditional text-based pro-cedure manuals are rarely sufficient, because they are difficult to maintain and analyze, and tend to not be read by the software engineers for whom they are written. The Unisys STARS team has defined many processes and has evolved a general approach to process definition, called the Pro-cess Description Approach in this paper.The Process Description Approach includes techniques for information gathering, auto-mated process modeling, process analysis, and process presentation. A variety of information gathering techniques are used including: brainstorming, creating IDEF0 diagrams, and interview-ing process performers to determine how they perform their jobs.Process modeling techniques include IDEF0 and Process Breakdown Structures. The Pro-cess Breakdown Structure formalism allows the representation of a process in terms of textual descriptions of its critical attributes including activities, work products, roles, work product avail-ability constraints, and control constraints. Process Breakdown Structures and the Process Map-per tool used to capture them were developed by Innovative Software Engineering Practices Inc. (INSTEP) and Software Design & Analysis Inc. (SDA) [INS94a, INS94b, NR94]. The Process Mapper tool also provides capabilities to analyze the process model for completeness and consis-tency.Processes are presented in both printed and electronic form using graphical and textual representations. Printed presentation forms include IDEF0Diagrams, Process Trees, Process Tables, and Process Packets. Electronic presentation is accomplished using Mosaic with hyper-text-links between process model data. Mosaic also enables easy transmission of the process across geographically-distributed sites. The Process Description Approach results in a well-defined process that can be easily understood, taught, and communicated.The Process Description Approach is based on the techniques used to define project pro-cesses on the Army/Unisys STARS Demonstration Project. The approach is currently being usedto define a domain modeling process and the Process Description Approach itself. This approach is being evolved further based on lessons learned during its application. Unisys STARS is also investigating how to make the scope more general and include lessons learned from other process definition efforts.Section 1 of this paper contains the introduction. In Section 2, key terminology that will be used in the rest of the paper is defined. Section 3 shows how process definition fits into a project’s process management life cycle. Sections 4, 5, and 6 describe the Process Description Approach. Recommendations based on lessons learned from using the Process Description Approach are dis-cussed in each of these sections. Section 7 discusses current and proposed uses of the Process Description Approach. Section 8 contains the conclusions.2.T ERMINOLOGYA process is a set of partially ordered steps intended to reach a goal [Fei93].An activity is a component of a process. Activities can range from individual process steps to large parts of processes.Process description encompasses the design, analysis, and implementation of a new pro-cess (often called process definition) or an existing process. A process description is the resultant product of the design or implementation. Processes are described to provide understanding to enable consistent process performance, to support automated performance, etc. The approach described in this paper is called a Process Description Approach because it can be used to design and implement existing or new processes.A process performer is a tool or human that follows a process in the performance of a task. For example, a large portion of a software development process is performed by the program-mers. Other performers may include software testers, configuration managers, and project manag-ers. Tools that perform software development activities include software modeling tools, compilers, linkers, and debuggers.A process engineer describes processes, selects process performers, monitors process per-formance, evaluates performance metrics, initiates process improvement activities, etc.3.T HE P ROCESS M ANAGEMENT L IFE C YCLEThe Process Concept Model shown in Figure1 shows how process description fits into the process management life cycle. The process management life cycle begins with the description of a process based on project goals, possibly using previously described process assets. Process assets are process descriptions that have been stored in a library for reuse. The process is sched-uled by assigning resources. The process can be installed on a machine or procedures given to humans to follow. The process is monitored and measured during its use. Measurement data is evaluated and used to further evolve the process. Description of an existing process can beginwith monitoring and documenting the current informal process. Process description can then be based on the evaluation of the documented process.The Process Management Life Cycle shown in Figure 2 shows the components of process description and the main work products produced. Process description is broken into Process Analysis, Process Design, and Process Implementation. Process Analysis involves identifying,analyzing, and capturing process requirements. Process Design involves modeling the architec-ture and functional decomposition of the process. Process Implementation involves implementing the process design to create scripts that are installed and providing training to humans who will execute the tasks. Process Implementation also involves preparing the process for performance by instantiating the process based on project-specific details and scheduling resources. Process Per-formance involves running process scripts and following manual procedures to perform the activ-ities described in the process. Metrics are gathered as the process is performed. These metrics are evaluated in Performance Evaluation, which leads to evolution of the process into a better quality process in Process Evolution. Although Figure 2 suggests that Process Analysis, Process Design,and Process Implementation occur in sequence, in practice the process engineer iterates and cycles back to previous activities as necessary.Similar activities occur in Process Analysis, Process Design, and Process Implementation as in the traditional software development life cycle activities of Analysis, Design, and Imple-mentation. These similarities, first described in [Ost87], allow process engineers to make use of the results of research of the software development community. For example, good software mod-eling principles also apply when creating process models.This paper focuses on the activities in the Process Description Approach, including Pro-cess Analysis, Process Design, and Process Implementation, as shown in the first three boxes in Figure 2. Process Implementation is currently only addressed as it relates to manually performed processes. Process Performance, Evaluation, and Evolution are part of the process managementSchedule and InstallEvaluateDescribe/EvolveProcessExecutionPlanning UseMonitor and Measure Project Context Process AssetsFigure 1.Process Concept Model.Figure 2.Process Management Life Cycle.P r o c e s s P r o c e s s P r o c e s sP r o c e s s P e r f o r m a n c e P e r f o r m a n c e E v a l u a t i o nS o u r c e R e q u i r e m e n t s A n a l y z e d M e t r i c sP r o c e s s P e r f o r m a n c e M e t r i c sP r o c e s s D e s i g n M o d e l P r o c e s s R e q u i r e m e n t slife cycle but are not addressed in the Process Description Approach since they are not part of Process Description.The approach and examples in this paper focus on the description of one process in a soft-ware development project, although the approach can also be tailored to apply to the description of multiple processes and organization processes. The approach should be tailored based on the goals of the process description effort. For example, the Process Description Approach includes modeling with IDEF0 and Process Breakdown Structures; other modeling notations could be sub-stituted. The approach does assume a hierarchical activity decomposition in the modeling nota-tion.The Process Description Approach described below is accompanied by IDEF0 diagrams to show how the activities interact. IDEF0 is based on the Structured Analysis and Design Technique (SADT) — a graphical approach to system description [MM88, Sof81]. An IDEF0 Activity Dia-gram contains one level of decomposition of a process. Boxes within the diagram depict the sub-activities of the parent activity named by the diagram. Arrows between the boxes depict availability of work products to activities. Arrows entering the left side of a box are inputs to an activity. Arrows exiting the right side of a box are outputs from an activity. Arrows entering the top of a box are controls that regulate the activity. Arrows entering the bottom of a box are mech-anisms that support the activity. A sequential ordering of boxes in the diagram does not imply a sequential flow of control between the activities. Figure3 shows the IDEF0 Diagram for Process Analysis.4.P ROCESS A NALYSIS4.1A PPROACH FOR P ROCESS A NALYSISAs shown in Figure3, Process Analysis involves gathering requirements levied on the process, modeling these requirements, setting process description objectives, and evaluating the requirements. Process requirements are gathered by investigating requirement sources. Model-ing these requirements and their interconnections allows the process engineer to gain a better understanding of them. Objectives are set based on process requirements and project constraints. Evaluation of process requirements is very important since all process description activities are based on them.Process requirements can be gathered from many sources, including the project contract, the organization’s policies and procedures, and interviews with project customers and manage-ment. An example of gathering a requirement from the organization’s policies is determining that a requirement exists for peer reviews to be included in the process when the organization has a policy that peer reviews should occur in all phases of software development. Interviews with the project customer and management are used to obtain requirements not stated in the contract. Interviews are also used to clarify vague requirements. All process requirements generated are listed with their sources, to allow traceability back to the sources if necessary.Process requirements are modeled, using standard software engineering techniques, to assist in their understanding. Modeling is particularly important for complex requirements.Process description objectives are based on the requirements, resources, and other project constraints. Objectives address how process description will be carried out, including tools used in process design and implementation. Guidelines are developed as to the level of detail sufficient in process design and implementation. These guidelines constrain process description decomposi-tion. Setting objectives also includes defining the viewpoint to be used for process description.For example, a software development process can be described from the viewpoint of the project manager or the programmers. If more than one viewpoint is needed, multiple process descriptions must be created.The process requirements model and process description objectives are evaluated through review by project management, the organization’s SEPG, and the customer. Project management and the customer verify that the requirements of the process and the process description objec-tives meet their expectations. The organization’s SEPG verifies that the process requirements and process description objectives conform to the organization’s policies and procedures.Figure 3.Process Analysis IDEF 0 Diagram.I3Existing ProcessRequirements I2Organizational ConstraintsI1Domain KnowledgeModel Process RequirementsA12Evaluate Process RequirementsA14O1ProcessRequirementsC1External Process RequirementsEvaluated ProcessRequirementsRequirements Modeling ToolSet Process Description ObjectivesA13M1Process Description MechanismsGather Process RequirementsA11ProjectConstraintsCollected ProcessRequirementsProcess Description ObjectivesProcessRequirements ModelPolicies &ProceduresRejected ProcessRequirements4.2R ECOMMENDATIONS FOR P ROCESS A NALYSIS•Process description should be based on process requirements.Process requirements gathering and analysis are very important because the pro-cess description is based on these requirements. Requirements for process descrip-tion are often overlooked because there is no single concise source of theserequirements.•Set process description objectives with realistic expectations of the time required.Detailed process analysis, process design, and process implementation areextremely time-consuming. The time required varies with the complexity of theprocess and the level of detail in the process description — similar to that requiredfor software development.•Prioritize process description based on risk.Risk management should be used to prioritize process description. Areas of great-est risk should be identified and process activities to be described prioritized basedon addressing those areas first. Process-related software engineering issues areraised and addressed during process description, reducing some of the risks.•Skills of process performers are one factor in determining the level of detail necessary in the process description.A process must be described in greater detail when performers have less skill inthe process. For example, skilled software designers will need less instruction thanthose less familiar with software design techniques.5.P ROCESS D ESIGN5.1A PPROACH FOR P ROCESS D ESIGNAs shown in Figure4, Process Design involves modeling the process, selecting process performers, and evaluating the process model. The process is modeled using IDEF0 and Process Breakdown Structures. Process performers are selected based on those available and recom-mended. The model is evaluated by process engineers, process performers, and other stakehold-ers. Each of the activities in Process Design is described in a separate section below. Process modeling, process performer selection, and evaluation of the process model are carried out incre-mentally on portions of the process, as prioritized when setting process description objectives.5.1.1 Process design modelingProcess design modeling involves determining process details, determining metrics to col-lect, and creating the design model. Detailed process design decisions are not addressed in pro-cess requirements and are often left to the process engineers and process performers to determine.For example, there may be requirements for peer reviews in the process but no requirement for when in the process these peer reviews are to occur. Determining process details is an investiga-tion and analysis activity that can include group brainstorming sessions, interviews of humans with experience in the process, research into possible performance methods, and analysis of how the process has been performed in the past. Group brainstorming sessions can be used to deter-mine subactivities of a particular activity, develop a hand-drawn IDEF 0 diagram, and interview process performers to determine how they perform their jobs. Human process performers should be included in determining process details for the activities that they will perform.One important area in process detail determination is selection of process metrics to be collected and analyzed. Metrics are selected based on the project’s process requirements. Process requirements are analyzed to determine useful and practical metrics that can serve as indicators for measuring the process based on the Goal/Question/Metric (GQM) paradigm [Bas84, Bas88].The GQM paradigm enforces the principle that measurement is performed for a purpose. GQM is based on a top-down approach in which project goals representative of the purpose for the mea-Figure 4.Process Design IDEF 0 DiagramI2Existing Process Design Models I3Available Process Performers O1Process Design ModelO2Selected Process PerformersProcess Design Model andfailed requirementsModel ProcessA21Process Design ModelM1Process Description MechanismsSelect Process PerformersA22C1ProcessRequirementsI1Domain Knowledge Evaluate Process ModelA23Selected Process PerformersEvaluated Process Design ModelC2Recommended Process Performers1.RequirementThe software process should allow the development of a reliable product.2.GoalEvaluate the current project’s process to assess the progress in achieving a defined level of code reliability. 3.Questions and MetricsQuestion A: Can the propagation of errors from the software specification and design phases be min-imized by applying inspection methods X and Y to the specification and design?Metric A1: Keep counts of the life cycle location where defects are identified and analyze the defects todetermine their origin (e.g., defect was identified during a code inspections and origin was design). Thiswill provide a count across the life cycle of defect origins and how far they propagate before beingdetected.Metric A2: Use counts in A1 as a high-level assessment of the inspection methodologies being used in the specification and design phase.Metric A3: Determine the cost of correcting defects at each stage. Based on recommendations to invest in additional inspection technologies, assess potential cost savings and reliability improvements in a compar-ison trade-off.Question B: Can the monitoring of changes across life cycle products (e.g., specification, design, code, etc.) be used to predict failures in the operational system?Metric B1: Collect changes to products under configuration management control. Develop a change cate-gory scheme based on an ordinal scale that is uniform across all life cycle phases (e.g., large, medium,small). Generate category counts for each life cycle phase.Metric B2: Correlate changes across life cycle phase, by selecting appropriate statistical method, and ana-lyze results for trends. For example, is there a strong correlation between a significant number of a certain class of changes (e.g., large) in an early life cycle phase and failure at a later life cycle phase?Figure 5.Example of the Application of GQM to a Process Requirement surement are first developed. A set of questions are developed based on the goals, the answers to which provide some level of assessment towards achieving the goals. Answers to the questions are specified as a set of metrics. Although the GQM paradigm is simple, the process of developing goals, questions, and metrics is complex and requires training and experience. Figure5 shows an example of how a process requirement can be analyzed using GQM and appropriate metrics selected. The figure is only intended to show a sample of the metrics that could be selected, not a complete set.A process design is modeled by hierarchically defining activities that are part of the pro-cess, and defining the work products and roles required to perform the activities. The Process Mapper tool [INS94b] is used to develop the process model using Process Breakdown Structures. The basic elements of Process Breakdown Structures in Process Mapper are shown in Figure6. The process is decomposed hierarchically into activities, called Process Steps in Process Mapper. Process objectives help in determining when to stop decomposing these activities. Each activity in the Process Step Decomposition contains many attributes defined in the activity’s Step Defini-tion including Name,Purpose,Step States, etc.Model Data, including Role Definitions,Work Product Definitions, and Condition Definitions,can be referenced by the process attributes. For each W ork Product Definition work product attributes are defined including the Name of the work product,Synopsis,Related Work products, etc. The figure also shows the attributes that are defined for Role Definitions and Condition Definitions.Figure 7 contains a screen dump of Process Mapper windows that contain an Application Engineering Process Breakdown Structure. The Application Engineering activity decomposition is shown in the window on the left. The bottom of this window shows buttons that can be clicked to enter attributes of each activity including Purpose ,Activities ,Entrance Criteria , etc. The two windows on the upper right show the Purpose and Entrance Criteria attributes for the Develop_system_model activity. The lower right window shows the Work Product Definition Edi-tor which contains attributes for Application Engineering work products. The System_model work product is selected and a description of the work product is shown in the Synopsis attribute.The Designer delivers the Design to the QA team for PURPOSE STEP STATESSUB-STEP GROUPING AND SEQUENCING ROLES REQUIREDCOMMUNICATIONS OBLIGATIONSENTRANCE CRITERIA WORK PRODUCTS USED ACTIVITIESWORK PRODUCTS PRODUCED EXIT CRITERIA OTHER CONSTRAINTSMODEL (PROCESS STEPDECOMPOSITION)PROPERTY DEFINITIONMODEL DATAASSERTIONSSTEP DEFINITIONInformation about the ways in which exit conditions satisfy entrance conditions as well as the ways in which exit conditions may be satisfied.referenceDESIGN TEST PLANNAME SYNOPSISRELATED WORK PRODUCTS TEMPLATEWORK PRODUCT STATESWORK PRODUCT DEFINITIONSDESIGNERPROJECT MANAGERNAME SYNOPSIS OCCUPANCY CONSTRAINTS RELATED ROLESSKILLS NEEDEDROLEDEFINITIONSAPPROVEDCHANGES NEEDEDNAME SYNOPSISEXPRESSIONCONDITION DEFINITIONSFigure 6.Basic Elements of Process MapperFigure 7.Process Mapper screen showing an Application Engineering process.Since many process attributes can be modeled, it is useful to group these attributes into categories, as shown in Figure8. Attribute categories allow prioritization so that modeling can occur in stages. For example, a project may decide to describe data availability for activities in one stage of process modeling and control flow in a later stage. These categories are not indepen-dent so prioritization should take dependencies into consideration. For example, work products used and produced should not be modeled without first describing each work product.5.1.2 Process performer selectionProcess performers are chosen incrementally as the process is designed. Selection of pro-cess performers allows the process engineer to refine the determination of level of detail needed in the process design model. For example, if a configuration management tool with file management capabilities will be one of the process performers, then the process model only needs to state that a file is stored or retrieved and does not have to decompose file storage or retrieval into subactivi-ties.5.1.3 Process model evaluationThe process model is evaluated incrementally as it is created by the process engineers, performers, and stakeholders, including project management, process performers, and others whoare knowledgable in the process. Evaluation by the process engineer includes analyzing the design model for correctness, completeness, and consistency. The described process is also evalu-ated for completeness. Stakeholders may not understand the modeling notation. Therefore, the model is translated into more understandable forms. These include: Process Trees, IDEF 0 Dia-grams, and Process Tables.Figure 9 shows a Process Tree for a Develop System Model activity. Process Trees were developed on the Army/Unisys STARS Demonstration Project to depict multiple levels of func-tional decomposition of a process in a hierarchical, graphical representation. This decomposition appears with activities connected by arrows. Arrows decompose an activity to its subactivities.Process Trees provide a convenient way of navigating complex process decompositions. Nodes within Process Trees can be used to index into IDEF 0 Diagrams and Process Breakdown Struc-tures. Process Tables are currently created manually, using the output of Process Mapper. Filters are used to format the Process Tables and sort activity attributes.Figure 10 shows a Process Table for the Develop_system_model activity. Process Tables are used to present the textual, descriptive information contained in the Process Breakdown Struc-tures. Each table shows the Process Breakdown Structure attributes of one activity, work product or role.Once presentation forms, such as Process Trees, IDEF 0 diagrams, and Process Tables have been created, they are distributed to stakeholders and review meetings are held. The results of these review meetings are used to improve the process model.Figure 8.Process Attribute Categories.Activity Attribute CategoriesWork Product Attribute Categories Activity Definition- Purpose- Description- Other ConstraintsControl Flow- Entry/Exit Criteria- Step States- Substep Grouping/SequenceRoles Required- Role Names- Communication ObligationsData Availability- Work Products Used- Work Products ProducedSubactivities- Substep Names- Methods Work Product Definition - Name - Synopsis Workproduct Relationships Workproduct States Workproduct Templates Role Definition - Name - Synopsis - Skills Needed Role RelationshipsRole Attribute Categories5.2R ECOMMENDATIONS FOR P ROCESS D ESIGN•Include process performers in description activities.Process performers should participate in process description meetings. Their par-ticipation allows them to contribute their understanding of the process, increasestheir sensitivity to following the process, gains their buy-in on process decisions,and allows them to be trained in the process as it is described.•Follow techniques for running well-organized meetings.Techniques for running well-organized meetings should be used to ensure thatbrainstorming and review meetings are productive. Holding many short meetingsis more conducive to development of a quality process description than fewer longmeetings. In group brainstorming meetings held to determine subactivities or cre-ate an IDEF 0 diagram, a reproducible, erasable medium (such as a reproduciblewhite board) facilitates capturing and changing the process description duringdevelopment . Since software development activities and the process for perform-ing these activities are integrated, meetings must be carefully facilitated to notallow engineering issues to divert the meetings. Issues should be captured anddeferred to keep the meetings focused.•Follow techniques for creating good models.Since process models are similar to software models, techniques learned in model-ing software can be applied to modeling processes. Techniques for creating goodmodels that are specific to process modeling can be found in the SADT methodol-ogy described in [MM88] and in Process Mapper training classes.Develop requirements view Develop system modelDeterminesystem modelscope Verify operational capabilities of application Develop system model from legacy codeDevelopcodeview Develop architectural view Develop traceabilityFigure 9.Develop System Model Process Tree.。

– Enables Ingest Control for preservation groups once OAI Harvesting is setup and or Plugin is Published
International ETD LOCKSS Storage Nodes
NDLTD and LOCKSS Call for Participation
Rosenthal et. al. Requirements for Digital Preservation Systems: A Bottum-Up Approach /abs/cs.DL/0509018
RLG-OCLC. (2002). Trusted Digital Repositories: Attributes and Responsibilities. Mountain View, CA. /legacy/longterm/repositories.pdf
– Dell PowerEdge Server 1850 Firewall - $2500
– Dell/EMC AX100 SAN (3TB) - $10,000
– RedHat Enterprise AS – 2@$50 = $100
– UPS - $700 – Server Rack - $1200
LOCKSS for ETDs
University of KentuckyBiblioteka Virginia Tech
University of Tennessee Vanderbilt
NC State Georgia Tech
Florida State
University of Miami
Technical Infrastructure