To frame our discussion, consider:
What is a process view?
Why is the adoption of a process view considered to address the objectives featured in the first question?
How is the adoption of a process view considered to address the objectives featured in the first question?
What techniques are useful in describing software process?
How does the choice of process modeling language influence the ability of the resulting model to communicate the nature of the activity?
How does the granularity of a process model impact its ability to support the level of management and control functions?
| Basic Definitions | |
|---|---|
| Process | What people do, using procedures, methods, tools, and equipment, to transform raw material (input) into a product (output) that is of value to the customers. |
| Software Engineering | The disciplined application of engineering, scientific, and mathematical principles, methods, and tools to the economical production of quality software. |
| Software Engineering Process | The total set of software engineering activities needed to transform the user's requirements into software. |
| Software Process | The set of activities, methods, and practices that are used in the production and evolution of software. |
Watts Humphrey
| The Nature of Quality |
Sometimes defined as "the totality of features and characteristics of a product or service that bears on its ability to satisfy given needs."(IEEE Standard) |
| A Process Perspective |
The paradigm treats process explicitly. There is guidance for recognizing, defining, measuring, and improving processes. |
| Based on Data | "The quality paradigm is fundamentally an empirical approach to problem-solving and management."(p. 26) Data is collected and used for deciding about current activity. |
| Customer Focus | There are a variety of customers. One customer is the client for the particular product. Internally you can think of users of your particular artifact as the customer. Hence, having a customer focus becomes a way of thinking. |
| Defect Elimination |
The quality paradigm tries to leverage defect prevention. Defect detection and removal is a costly activity. By moving towards preventing defects, you free considerable resources for pursuit of new opportunities. |
| Managing for Quality |
There must be management commitment to quality. Adopting the paradigm implies a move towards continuous process improvement which requires commitment from both management and workers. |
Quality can be identified but not defined. " As an affirmative - "I know it when I see it!!", and a negative - "I know when its missing!!".
The user view quality is in the context of use. This view gauges quality with regard to fitness for use.
Manufacturing process takes precedence over product. Here quality is assessed based on performing the right tasks to construct the product assuming such acts result in better products.
The product view is conformance to specification. We build what we wanted to build as detailed in the specification.
Equates quality with what customers are willing to pay. This view provides the foundation for trade-offs. This view is typical later in product development cycles when change requests are handled.
Arrows entering the left side of the box are inputs. Inputs are transformed or consumed by the function to produce outputs.
Arrows entering the box on the top are controls. Controls specify the conditions required for the function to produce correct outputs. Think of those items that are needed to insure/help (standards, guidelines) that when used leverage the production of correct output from a process.
Arrows leaving a box on the right side are outputs. Outputs are the data or objects produced by the function.
Identify some of the means that support the execution of the function.
What people do, using procedures, methods, tools, and equipment, to transform raw material (input) into a product (output) that is of value to the customers.
The set of activities, methods, and practices that are used in the production and evolution of software.
| Model Type | Characteristics |
|---|---|
| Universal | Describes the basic process steps and provides general guidance on their role and order (e.g., Waterfall and Spiral Model). Permit global understanding and provide a framework for establishing policies. |
| Atomic | Precise data definitions, algorithmic specifications, information flows and user procedures. Atomic process definitions are often embodied in process standards and conventions. Provide atomic detail for training and task mechanization. |
| Worldly | Guides the sequence of tasks,
defines task prerequisites and results, specify who does what when, models anticipate results,
measure and key checkpoints. Guide daily work. |
The three levels of process models (universal, atomic, worldly) must be present in the process framework. Thus, the framework would give policies, procedures and standards (corresponding to the level). The architectural framework provides a definition for the basic elements, how they relate and how they are decomposed into increasing detail.
The basic element of the process model is the Unit Cell. A unit cell is defined to accomplish a specific task and is uniquely identified. Each cell has required entry conditions with inputs, task standards, procedures, methods, responsibilities, and measures. Exit conditions define the results produced, their level of validation, and any post-task conditions. Feedback is allowed to and from other unit cells.
Table 1: Basic Unit Cell Specification | |
|---|---|
 | |
| Specification | |
| Entry | Conditions to be met before task initiation |
| Exit | Results produced |
| Feedback | IN: Feedback from other cells OUT: Feedback to other cells |
| Task | What is to be done (who, what, when)? Standards, procedures, and responsibilities. |
| Measurements | Task, output, and feedback measures |
The Table 2 provides an example that should highlight the modeling activity. In particular, Table 2 offers a model for what we normally refer to as the development cycle for small projects.
Table 2: Unit Cell Definitions for Process Model | |||
|---|---|---|---|
 | |||
| Cell | 001 | 002 | 003 |
| Entry | Approved requirements, changes and development plan | Inspected and approved design and changes | Inspected and approved code and changes |
| Exit | Inspected and approved design and changes | Inspected and approved code and changes | Inspected, tested and approved software |
| Feedback In | Design Issues | Implementation Issues | |
| Feedback Out | Requirements Issues | Requirements and Design Issues | Requirements, Design Issues, and implementation issues |
| Task | Design | Implementation, Inspection and unit test | Testing: Integration, Function, System, and Acceptance |
| Measures | Resources, Product: Changes, Errors, Design, Document Pages | Resources, Product: Changes, Errors, Code, Document Pages | Resources, Product: Changes, Errors, Code, Document Pages, Test Suite |
a. A Software Project Manager is designated to be responsible for developing software size, cost, schedule, and resource estimates; preparing project planning documents; and negotiating commitments.
b. Those responsible for preparing the project planning documents are skilled or have received training in software project planning and software estimating.
c. The Statement of Work (SOW) or tasking statement has been documented. The SOW or task statement should include the scope of the work, technical goals and objectives, identification of customers and end users, imposed standards, assigned responsibilities, cost and schedule constraints and goals, dependencies between the software project and other organizations, resource constraints and goals, and other constraints and goals for development and/or maintenance.
d. Initial allocated requirements have been documented.
e. Adequate resources and budget for software project planning have been identified and allocated. Adequate budget generally means 1-2% of the software project budget.
f. Customer/sponsor required documentation (e.g. Computer Resources Life Cycle Management Plan, Software Support Requirements Analysis, Transition Plan, Acquisition Plan, etc.) is available and complete.
g. SSC San Diego Software Project Planning Policy has been reviewed.
Planning budget and trained personnel. SSC San Diego Software Project Planning Policy. Project's documented software requirements. Documented SOW or tasking statement.
There are two major activities to initiating software project planning: develop estimates, and plan software activities.
(2) Review the statement of work and the initial allocated requirements to scope the effort.
(3) Make initial estimates of software size, cost and schedule using the " SSC San Diego Software Size, Cost, and Schedule Estimation Process" document.
(4) Estimate the project's critical computer resources. Critical computer resources may be in the host environment, in the integration and testing environment, in the target environment, or in any combination of these.
(5) Estimate the space requirements for the project's software engineering facilities and make a preliminary identification of the hardware, support tools and associated costs (e.g., license fees, maintenance cost) required for the target environment, the host environment and the integration and test environment.
(1) Perform an initial assessment of the following:
(a) Software objectives, allocated requirements and interface requirements. The "Requirements Management Guidebook" available for downloading from the SEPO Home page will assist in this step.
(b) Customer delivery schedule requirements.
(c) Customer budget limitations.
(d) System technical constraints.
(e) Staffing constraints (in-house and contractors).
(f) Contracting needs.
(g) Resource constraints.
(h) Software development environment.
(i) Software processes to be used.
(j) Design, programming, software engineering and test requirements and standards.
(k) Configuration management requirements.
(l) Quality assurance requirements.
(m) Non-deliverable software and hardware requirements.
(n) Risks and risk reduction strategies for the project.
(o) Documentation requirements.
Initial planning data including a Project budget and/or WBS that includes a line item for the SPP task and the project organization chart identifies the project's Software Project Manager (SPM).
A Project Software Manager for the project has been identified. Adequate resources, funding have been allocated to perform the planning task, and an initial understanding of the scope of the effort has been accomplished.
Effort expended in planning work efforts.
Go To Lecture [Outline] [Overview]
Go To [311 Course Outline] [CIS Department Page]
Fox, C. & Frakes, W. (1997) The Quality Approach: Is It Delivering? CACM, 40, p. 25-29.
Humphrey, W. (1989) Managing the Software Process. Reading, MA: Addison-Wesley. p. 247-286.
Ibrahim & Hirmanpour (1995) The Subject Matter of Process Improvement. CMU/SEI--95-TR-003
Pressman, R. S. (1997) Software Engineering: A Practitioner's Approach. New York: McGraw-Hill.
White, P. R. (1993) Report on a Process Analysis and Design Method. Technical Report Department of Computer Science, University of Manchester, UK