Background and Definitions

• Our focus is targeted at the engineering of complex business capabilities or processes like software development across their life cycle.
• A capability represents the processes, organization staffing, and information infrastructure, as well as their interrelationships, for a recurring business activity that produces products or services.
• The web of relationships among the objects and attributes of products, processes, organization, infrastructure, or total capability defines its architecture.
  • Software Production Architecture: A composite model that interrelates
    • software system architecture
    • software process architecture
    • development organization architecture
    • network infrastructure
    • development tools/environment configuration
    • documentation architecture
    • customer-support knowledge base architecture
    • Example (graphic)
  • P. Mi and W. Scacchi, A Meta-Model for Formulating Knowledge-Based Models of Software Development, Decision Support Systems, 17(4):313-330, 1996.

Sources of Experiences Encountered

• Andersen Consulting (now Accenture)
• AT&T/Lucent Bell Laboratories
• CoGenTex
• Computer Technology Associates
• EDS
• Hewlett-Packard
• HoloSoFx (formerly Active Management Inc.)
• McKesson Water Products Co.
• Naval Air Warfare Center (China Lake, CA)
• Northrop(-Grumann) B-2 Division
• Office of Naval Research
• Perceptronics
• SUN Microsystems Computer Corp.
• USAF Rome Laboratories
• USC Entertainment Technology Center
• Advanced Biotechnology and Bioinformatics Center at USC Health Sciences Campus
• USC Advanced Technology Research for Investigating and Understanding Managed processes (ATRIUM) Laboratory
• Intelligent Systems Technology Incorporated

Meta-modeling

• A domain model for the domain of software production or organizational process
• An ontology -- a vocabulary of concepts and logic of relationships that interlinks the concepts
• A knowledge representation scheme that codifies an ontology for software production or organizational process
  • Object-relational schema plus rule-based methods
    • Attributed directed graph of object types (labeled nodes) interconnected by explicit relational links (labeled edges).
    • Both objects and relations are typed, have characterizing properties/attributes, and attached methods.
    • Rules invoke methods when antecedent expression of object-attribute-value pattern is satisfied/matched.
      • IF <?X> THEN <Method1> ELSE <Method2>; where <?X> is the placeholder for "antecedent expression"
    • Enables logical inferencing (e.g., using first-order propositional logic), deduction, induction, etc.
    • Supported by object-relational database management systems
  • Petri-nets (including rule-augmented, colored Petri nets)
  • Hierarchical rule bases and asserted facts (e.g., Prolog)
  • Procedural programs and abstract data types
  • Semi-structured hypermedia (MIME-type objects associated with client-side applications, invoke via hyperlink navigation)
  • Narrative text
• Example (graphic)

• Enable development, use, and evolution of reusable process modeling assets (e.g., process models, associated product models, team models).
• Provide architectural framework for developing process-centered software development environments or integrated development environments
  • IDEs with explicit process guidance
  • Process-directed intranets (PDIs) or extranets (PDEs) that enable process sharing and coordination within/across multiple networked sites or across virtual private networks (VPNs).
• Provides compeling process integration framework that can unify multiple process models written in different notations
• Provides scheme for generating process models or process model instances in different process modeling notations.
• Provides a reflexive (self-referential), extensible (open) representation scheme

• Resources -- a resource-centered view of the universe of software production
  • Documents/Artifacts
  • Tools
  • Network infrastructure
  • Budget
  • Schedule
  • Beliefs
  • Skills
  • Agents
  • Tasks/Processes
  • etc.
  • "Everything is a resource"
    • All resources have attributes (i.e., their object classes/types)
    • All resources have a "status"
  • All resources are hierarchically decomposable (i.e., have sub-classes, sub-sub-classes, etc.)
• Agents -- have "skills" (tasks they know how to perform, or have experience in performing)
  • Individual
    • Intelligent
    • Non-intelligent
  • Collective
    • Workgroup (emphemeral)
    • Team (persistent)
    • Organization
    • Institution
• Tasks/Processes -- performed by individual or collective agents
  • Meta-tasks -- tasks which produce other tasks
    • Project management
    • Process Management
    • Articulation (negotiated, situated)
  • Primary tasks (assignable, task-specific)
    • Actions -- units of work in a task (require some change from preceding action)
      • Primitive actions (e.g., tool/script invocation command)
    • Control flow (precedence relations)
      • Sequence of steps
        • Preconditions or entry guardians
        • Postconditions or exit sentinels
      • Iteration (and decision)
      • Conditional (decision)
      • Concurrrency
    • Executable scripts
      • Resource bindings
      • Tools -- client-side, server-side
      • Artifacts -- Documents, MIME types, Forms, etc.
      • Agents
    • Protocols
      • Communicating state machines and event handlers that coordinate the status of their resources and actions
• Relations -- always paired with its inverse (bi-directional relationships that support reflecivity)
  • Composition/Decomposition
  • Predecessor/Successor
  • Generic/Concrete
  • Performance/Enablement
  • Possession/Delegation
  • Production/Consumption
  • etc.

• Software production entails agents performing tasks that consume or produce resources using tools to create or update products (resources).

Experience: process met-models are key to achieving process-level interoperability, as shown with

• Entity-Relation-Attribute Product-centered DB (PBI-Softman)
• Attributed Petri Nets (CACE-PM/DMS*)
• Rule-Based Databases (AP5, Matisse)
• Process Programming Language (SynerVision*, PML)
• Workflow (WORKFLOW/BPR*)
• Hybrid Composite (SMART)
• Others (PIF -- Process Interchange Format)

* denotes commercial product.

Modeling

• Alternative process modeling notations may be employed, as long as they are consistent with the process meta-model.
• Modeling software development processes is fundamentally no different than modeling any other organizational process.
• Modeling software production entails identifying and modeling:
  • agents performing tasks that consume (input) or produce (output) resources using tools to create or update products (resources).
• Models may specify "as-is" (legacy), "to-be" (future alternative), or "here-to-there" (transformation) processes.

Experience: Most process modeling or redesign efforts want to primarily focus on "to-be" alternatives, without baselining as-is processes, and without defining the here-to-there process that is suppose to change the world from as-is to to-be.

Experience: Capturing as-is processes is labor-intensive and thus represents an area for further R&D innovations.

Examples:
Image files that show user interface displays of (a) a process task model class hierarchy definition conforming to MIL-STD-2167A, and (b) a process model definition for a programming task in a table format can be viewed when selected .

Analysis

• Logical: Evaluating static and dynamic properties of a process/capability model, including its consistency, completeness, internal correctness, traceability, as well as other semantic checks.
• Feasibility: Determining whether a proposed process or capability architecture can satisfy existing requirements, given available resources.
• Statistical: Calculating descriptive and inferential statistics the characterize the frequency, distribution, and associations among process step events, transactions, etc.
• Reasoning: Pattern-matching queries and inferencing to reason about properties of processes, such as spatial and temporal distribution, organization (who, what, where, when, why, how, what-if, how much, etc.), classification (taxonomic, genericity), configuration (composition, scheduling, replanning, generalization, specialization), and diagnosis.
• Resource Flow:Determining how to transform process flow to reduce resource utilization (e.g., reduce cycle time and cost).

Experience: Easy to produce management reports or presentation materials.

Examples:
Image files that show user interface displays of (a) a sample of process model analysis checks, (b) process model analysis statistics, (c) process model analysis view, and (d) a Web-based process model analysis report can be viewed when selected.

Simulation

Knowledge-Based Simulation

• Symbolically enacting process models in order to determine the path and flow of intermediate state transitions in ways that can be made persistent, replayed, queried, dynamically analyzed, and reconfigured into multiple alternative scenarios.

Experience: Can produce narrative summaries of simulation runs.

Examples:
Image files that show user interface displays of (a) a process model simulation interaction, and a subsequent (b) a process model simulation narrative trace can be viewed when selected.

A paper describing the initial design and implementation of this simulation mechanism can be found in, P. Mi and W. Scacchi, A Knowledge-Based Environment for Modeling and Simulating Software Engineering Processes, IEEE Trans. Knowledge and Data Engineering, 2(3), 283-294, 1990. Reprinted in Nikkei Artificial Intelligence, Vol. 20(1), 176-191, 1991 (in Japanese).

Discrete-Event Simulation

• Computationally enacting a sample of process models as network flows with heuristic or statistical arrival rates and service times so as to determine the overall process performance envelope, throughput, systematic behavior, and resource bottlenecks.

Experience: Visual interactions and presentations always impress.

Image files that show user interface displays of (a) a discrete-event process model workflow simulation interaction, and a subsequent (b) simulation results display highlighting distribution of costs and activity-based costs can be viewed when selected.

• Multi-agent discrete-event simulation for modeling, simulating, and monitoring decentralized software process architectures
• Decentralized process architectures appear to scale to multiple site processes and process interactions
• Decentralized software process architectures appear well suited for very large, multi-site software processes, such as those for acquisition of software-intensive systems, or perhaps for open source software development projects.

A paper describing the initial design and implementation of this simulation mechanism can be found in, J.S.C. Choi and W. Scacchi, Modeling and Simulating Software Acquisition Process Architectures, Journal of Systems and Software, 59(3), 343-354, 15 December 2001.

Redesign

• Transforming the structure and dynamic flow of data, control, or work products so as to reduce process cycle time, number of steps, number of inter-department or inter-organizational hand-offs, number of repetitive manual processing steps, etc.
• Benefits from systematic measurement of properties of formal process definition/model to determine which redesign transformations or optimizations may apply.
• Diagnostic analyses and transformation heuristics applied to software production models lead to optimization opportunities
• Transformation heuristics classified taxonomically
• Taxonomy classifies domain-independent and domain-specific heuristics
• DI transformations applied in any software production setting (sample transformation classes)
  • Job scope
  • Worker empowerment
  • Organization design
  • Workflow streamlining
  • Information technology (sample)
    • Extend IT-based support to manual process steps
    • Extend IT-based communication facilities to encourage information sharing activities
    • Extend IT-based automation to incorporate new kinds of application packages
    • Extend IT-based integration to interconnect and interrelate existing "islands of automation"
• DS transformations applied to specific component architectures
• Benefits from the development and application of a taxonomy of previously successful process redesign transformation patterns, rules, and consequences.

Experience: Return on Investment in process redesign effort is often greater than 10-1.

Experience: Many, but not all, process redesigns fail during organizational implementation and routinization!

Image files that show displays of (a) before and (b) after process redesign, and (c) example measurements on a process model that reveal possible redesign optimization opportunities.

A paper describing this approach to process redesign can be found in W. Scacchi, Redesigning Contracted Service Procurement for Internet-based Electronic Commerce: A Case Study, J. Information Technology and Management, 2(3), 313-334, 2001.