| HOME | Project Management Data Warehousing / Mining Software Testing | Technical Writing |
|
3. TOOLS AND TECHNIQUES FOR PROCESS MODELING There are many choices for modeling tools and techniques, once you decide what you want to capture in your process model; we have seen several modeling approaches in our model depictions in the previous section. The appropriate technique for you depends on your goals and your preferred work style. In particular, your choice for notation depends on what you want to capture in your model. The notations range from textual ones that express processes as functions, to graphical ones that depict processes as hierarchies of boxes and arrows, to combinations of pictures and text that link the graphical depiction to tables and functions elaborating on the high-level illustration. Many of the modeling notations can also be used for representing requirements and designs; we examine some of them in later sections. In this section, the notation is secondary to the type of model, and we focus on two major categories, static and dynamic. A static model depicts the process, showing that the inputs are transformed to outputs. A dynamic model can enact the process, so the user can see how intermediate and final products are transformed over time. Static Modeling: Lai Notation There are many ways to model a process statically. In the early 1990s, Lai (1991) developed a comprehensive process notation that is intended to enable someone to model any process at any level of detail. It builds on a paradigm where people perform roles while resources perform activities, leading to the production of artifacts. The process model shows the relationships among the roles, activities, and artifacts, and state tables show information about the completeness of each artifact at a given time. In particular, the elements of a process are viewed in terms of seven types: 1. Activity: Something that will happen in a process. This element can be related to what happens before and after, what resources are needed, what triggers the activity’s start, what rules govern the activity, how to describe the algorithms and lessons learned, and how to relate the activity to the project team. 2. Sequence: The order of activities. The sequence can be described using triggers, programming constructs, transformations, ordering, or satisfaction of conditions. 3. Process model: A view of interest about the system. Thus, parts of the process may be represented as a separate model, either to predict process behavior or to ex amine certain characteristics. 4. Resource: A necessary item, tool, or person. Resources can include equipment, time, office space, people, techniques, and so on. The process model identifies how much of each resource is needed for each activity. 5. Control: An external influence over process enactment. The controls may be manual or automatic, human or mechanical. 6. Policy: A guiding principle. This high-level process constraint influences process enactment. It may include a prescribed development process, a tool that must be used, or a mandatory management style. 7. Organization: The hierarchical structure of process agents, with physical grouping corresponding to logical grouping and related roles The mapping from physical to logical grouping should be flexible enough to reflect changes in physical environment. The process description itself has several levels of abstraction, including the software development process that directs certain resources to be used in constructing specific modules, as well as generic models that may resemble the spiral or waterfall models. Lai’s notation includes several templates, such as an Artifact Definition Template, which records information about particular artifacts. Lai’s approach can be applied to modeling software development processes; later in this section, we use it to model the risk involved in development. However, to demonstrate its use and its ability to capture many facets of a complex activity, we apply it to a relatively simple but familiar process, driving an automobile. Table 1 contains a description of the key resource in this process, a car. Other templates define relations, process states, operations, analysis, actions, and roles. Graphical diagrams represent the relationships between elements, capturing the main relationships and secondary ones. For example, FIG. 11 illustrates the process of starting a car. The “initiate” box represents the entrance conditions, and the “park” box represents an exit condition. The left-hand column of a condition box lists artifacts, and the right-hand column is the artifact state. Transition diagrams supplement the process model by showing how the states are related to one another. For example, FIG. 12 illustrates the transitions for a car. Lai’s notation is a good example of how multiple structures and strategies can be used to capture a great deal of information about the software development process. But it is also useful in organizing and depicting process information about user requirements, too, as the car example demonstrates. TABLE 1 Artifact Definition Form for Artifact “CAR” (Lai 1991)
Dynamic Modeling: System Dynamics A desirable property of a process model is the ability to enact the process, so we can watch what happens to resources and artifacts as activities occur. In other words, we want to describe a model of the process and then watch as software shows us how re sources flow through activities to become outputs. This dynamic process view enables us to simulate the process and make changes before the resources are actually expend ed. For example, we can use a dynamic process model to help us decide how many testers we need or when we must initiate testing in order to finish on schedule. Similarly, we can include or exclude activities to see their effects on effort and schedule. For instance, we can add a code-review activity, making assumptions about how many faults we will find during the review, and determine whether reviewing shortens test time significantly. There are several ways to build dynamic process models. The systems dynamics approach, introduced by Forrester in the 1950s, has been useful for simulating diverse processes, including ecological, economic, and political systems (Forrester 1991). Abdel Hamid and Madnick have applied system dynamics to software development, enabling project managers to “test out” their process choices before imposing them on developers (Abdel-Hamid 1989; Abdel-Hamid and Madnick 1991). To see how system dynamics works, consider how the software development process affects productivity. We can build a descriptive model of the various activities that involve developers’ time and then look at how changes in the model increase or de crease the time it takes to design, write, and test the code. First, we must determine which factors affect overall productivity. FIG. 13 depicts Abdel-Hamid’s understanding of these factors. The arrows indicate how changes in one factor affect changes in another. For example, if the fraction of experienced staff increases from one-quarter to one-half of the people assigned to the project, then we would expect the average potential productivity to increase, too. Similarly, the larger the staff (reflected in staff size), the more time is devoted to communication among project members (communication overhead). The figure shows us that average nominal potential productivity is affected by three things: the productivity of the experienced staff, the fraction of experienced staff, and the productivity of the new staff. At the same time, new staff must learn about the project; as more of the project is completed, the more the new staff must learn before they can become productive members of the team. -- -- --
Experienced staff nominal potential productivity Actual fraction of person-day on project Over/under work tolerances Fraction of staff experienced New staff nominal potential productivity Potential productivity Software development productivity Motivation and communication losses Schedule pressure Percent of project completed Learning multiplier Communication overhead Staff size -- -- -- -- Other issues affect the overall development productivity. First, we must consider the fraction of each day that each developer can devote to the project. Schedule pressures affect this fraction, as do the developers’ tolerances for workload. Staff size affects productivity, too, but the more staff, the more likely it is that time will be needed just to communicate information among team members. Communication and motivation, combined with the potential productivity represented in the upper half of FIG. 13, suggest a general software development productivity relationship. Thus, the first step in using system dynamics is to identify these relationships, based on a combination of empirical evidence, research reports, and intuition. The next step is to quantify the relationships. The quantification can involve direct relationships, such as that between staff size and communication. We know that if n people are assigned to a project, then there are n(n — 1)/2 potential pairs of people who must communicate and coordinate with one another. For some relationships, especially those that involve resources that change over time, we must assign distributions that describe the building up and diminishing of the resource. For example, it is rare for everyone on a project to begin work on the first day. The systems analysts begin, and coders join the project once the significant requirements and de sign components are documented. Thus, the distribution describes the rise and fall (or even the fluctuation, such as availability around holidays or summer vacations) of the resources. A system dynamics model can be extensive and complex. For example, Abdel Hamid’s software development model contains more than 100 causal links; FIG. 14 shows an overview of the relationships he defined. He defined four major areas that affect productivity: software production, human resource management, planning, and control. Production includes issues of quality assurance, learning, and development rate. Human resources address hiring, turnover, and experience. Planning concerns schedules and the pressures they cause, and control addresses progress measurement and the effort required to finish the project. Because the number of links can be quite large, system dynamics models are sup ported by software that captures both the links and their quantitative descriptions and then simulates the overall process or some sub-process. The power of system dynamics is impressive, but this method should be used with caution. The simulated results depend on the quantified relationships, which are often heuristic or vague, not clearly based on empirical research. However, as we will see in later sections, a historical database of measurement information about the various aspects of development can help us gain confidence in our understanding of relationships, and thus in the results of dynamic models. === === SIDEBAR 3 PROCESS PROGRAMMING In the mid-1980s, Osterweil (1987) proposed that software engineering processes be specified using algorithmic descriptions. That is. if a process is well-understood, we should be able to write a program to describe the process, and then run the program to enact the process. The goal of process programming is to eliminate uncertainty, both by having enough understanding to write software to capture its essence, and by turning the process into a deterministic solution to the problem. Were process programming possible we could have management visibility into all process activities automate all activities, and coordinate and change all activities with ease. Thus process programs could form the basis of an automated environment to produce software. However, Curtis, Krasner, Shen, and Iscoe (1987) point out that Osterweil s analogy to computer programming does not capture the inherent variability of the underlying development process. When a computer program is written, the programmer assumes that the implementation environment works Properly the operating system database manager, and hardware are reliable and correct so there is little variability in the computer’s response to an instruction. But when a process program issues an instruction to a member of the project team, there is great variability in the way the task is executed and in the results produced. As we will see in Section 1 differences in skill experience, work habits understanding the customer s needs, and a host of other factors can increase variability dramatically. Curtis and his colleagues suggest that process programming be restricted only to those situations with minimal variability. Moreover, they point out that Osterweil s examples provide information only about the sequencing of tasks the process program does not help to warn managers of impending problems. “The coordination of a web of creative intellectual tasks does not appear to be improved greatly by current implementations of process programming, because the most important source of coordination is to ensure that all of the interacting agents share the same mental model of how the system should operate. = == == 4. PRACTICAL PROCESS MODELING Process modeling has long been a focus of software engineering research. But how practical is it? Several researchers report that, used properly, process modeling offers great benefits for understanding processes and revealing inconsistencies. For example, Barghouti, Rosenblum, Belanger, and Alliegro (1995) conducted two case studies to deter mine the feasibility, utility, and limitations of using process models in large organizations. In this section, we examine what they did and what they found. Marvel Case Studies In both studies, the researchers used MSL, the Marvel Specification Language, to define the process, and then generated a Marvel process enactment environment for it (Kaiser, Feiler, and Popovich 1988; Barghouti and Kaiser 1991). MSL uses three main constructs—classes, rules, and tool envelopes—to produce a three-part process description: 1. a rule-based specification of process behavior 2. an object-oriented definition of the model’s information process 3. a set of envelopes to interface between Marvel and external software tools used to execute the process. The first case study involved an AT&T call-processing network that carried phone calls, and a separate signaling network responsible for routing the calls and balancing the network’s load. Marvel was used to describe the Signaling Fault Resolution process that is responsible for detecting, servicing, and resolving problems with the signaling net work. Workcenter 1 monitored the network, detected faults, and referred the fault to one of the two other workcenters. Workcenter 2 handled software or human faults that required detailed analysis, and Workcenter 3 dealt with hardware failures. FIG. 15 depicts this process. Double dashed lines indicate which activity uses the tool or database represented by an oval. A rectangle is a task or activity, and a diamond is a decision, Arrows indicate the flow of control. As you can see, the figure provides an overview but is not detailed enough to capture essential process elements. Consequently, each of the entities and work centers is modeled using MSL. FIG. 16 illustrates how that is done. The upper half of the figure defines the class TICKET, where a ticket represents the trouble ticket (or problem report) written whenever a failure occurs. As we will see in the sections on testing, trouble tickets are used to track a problem from its occurrence to its resolution. The entire network was represented with 22 such MSL classes; all information created or required by a process was included. Next, the model addressed behavioral aspects of the Signaling Fault Resolution process. The lower half of FIG. 16 is an MSL rule that corresponds loosely to the box of FIG. 15 labeled “Diagnose.” Thus, the MSL describes the rule for diagnosing open problems; it is fired for each open ticket. When the process model was done, there were 21 MSL rules needed to describe the system. The second case study addressed part of the software maintenance process for AT&T’s 5ESS switching software. Unlike the first case study, where the goal was process improvement, the second study aimed only to document the process steps and interactions by capturing them in MSL. The model contained 25 classes and 26 rules. For each model, the MSL process descriptions were used to generate “process enactment environments,” resulting in a database populated with instances of the information model’s classes. Then, researchers simulated several scenarios to verify that the models performed as expected. During the simulation, they collected timing and resource utilization data, providing the basis for analyzing likely process performance. By changing the rules and executing a scenario repeatedly, the timings were compared and contrasted, leading to significant process improvement without major investment in resources. The modeling and simulation exercises were useful for early problem identification and resolution. For example, the software maintenance process definition uncovered three types of problems with the existing process documentation: missing task inputs and outputs, ambiguous input and output criteria, and inefficiency in the process definition. The signaling fault model simulation discovered inefficiencies in the separate descriptions of the workcenters. Barghouti and his colleagues note the importance of dividing the process modeling problem into two pieces: modeling the information and modeling the behavior. By separating these concerns, the resulting model is clear and concise. They also point out that computer-intensive activities are more easily modeled than human-intensive ones, a lesson noted by Curtis and his colleagues, too. Desirable Properties of Process Modeling--Tools and Techniques There are many process modeling tools and techniques, and researchers continue to work to determine which ones are most appropriate for a given situation. But there are some characteristics that are helpful, regardless of technique. Curtis, Kellner, and Over (1992) have identified five categories of desirable properties: 1. Facilitates human understanding and communication. The technique should be able to represent the process in a form that most customers and developers can understand, encouraging communication about the process and agreement on its form and improvements. The technique should include sufficient information to allow one or more people to actually perform the process. And the model or tool should form a basis for training. 2. Supports process improvement. The technique should identify the essential components of a development or maintenance process. It should allow reuse of processes or subprocesses on subsequent projects, compare alternatives, and estimate the impact of changes before the process is actually put into practice. Similarly, the technique should assist in selecting tools and techniques for the process, in encouraging organizational learning, and in supporting continuing evolution of the process. 3. Supports process management. The technique should allow the process to be project-specific. Then, developers and customers should be able to reason about at tributes of software creation or evolution. The technique should also support planning and forecasting, monitoring and managing the process, and measuring key process characteristics. 4. Provides automated guidance in performing the process. The technique should de fine all or part of the software development environment, provide guidance and suggestions, and retain reusable process representations for later use. 5. Supports automated process execution. The technique should automate all or part of the process, support cooperative work, capture relevant measurement data, and enforce rules to ensure process integrity. These characteristics can act as useful guidelines for selecting a process modeling technique for your development project. Item 4 is especially important if your organization is attempting to standardize its process; tools can help prompt developers about what to do next and provide gateways and checkpoints to assure that an artifact meets certain standards before the next steps are taken. For example, a tool can check a set of code components, evaluating their size and structure. If size or structure exceeds pre defined limits, the developers can be notified before testing begins, and some components may be reviewed and perhaps redesigned. 5. INFORMATION SYSTEM EXAMPLE Let us consider which development process to use for supporting our information System example, the Piccadilly television advertising program. Recall that there are many constraints on what kinds of advertising can be sold when, and that the regulations may change with rulings by the Advertising Standards Authority and other regulatory bodies. Thus, we want to build a software system that is easily maintained and changed. There is even a possibility that the constraints may change as we are building the system. The waterfall model may be too rigid for our system, since it permits little flexibility after the requirements analysis stage is complete. Prototyping may be useful for building the user interface, so we may want to include some kind of prototyping in our model. But most of the uncertainty lies in the advertising regulations and business constraints. We want to use a process model that can be used and reused as the system evolves. A variation of the spiral model may be a good candidate for building the Piccadilly system, because it encourages us to revisit our assumptions, analyze our risks, and prototype various system characteristics. The repeated evaluation of alternatives, shown in the upper-left-hand quadrant of the spiral, helps us build flexibility into our requirements and design. Boehm’s representation of the spiral is high-level, without enough detail to direct the actions of analysts, designers, coders, and testers. However, there are many techniques and tools for representing the process model at finer levels of detail. The choice of technique or tool depends in part on personal preference and experience, and in part on suitability for the type of process being represented. Let us see how Lai’s notation might be used to represent part of the Piccadilly system’s development process. Because we want to use the spiral model to help us manage risk, we must include a characterization of “risk” in our process model. That is, risk is an artifact that we must describe, so we can measure and track risk in each iteration of our spiral. Each potential problem has an associated risk, and we can think of the risk in terms of two facets: probability and severity. Probability is the likelihood that a particular problem will occur, and severity is the impact it will have on the system. For example, suppose we are considering the problem of insufficient training in the development method being used to build the Piccadilly system. We may decide to use an object-oriented approach, but we may find that the developers assigned to the project have little or no experience in object orientation. This problem may have a low probability of occurring, since all new employees are sent to an intensive, four-week course on object-oriented development. On the other hand, should the problem actually occur, it would have a severe impact on the ability of the development team to finish the software within the assigned schedule. Thus, the probability of occurrence is low, but the severity is large. We can represent these risk situations in a Lai artifact table, shown in Table 2. Here, risk is the artifact, with sub-artifacts probability and severity. For simplicity, we have chosen only two states for each sub-artifact: low and high for probability, and small and large for severity. In fact, each of the sub-artifacts can have a large range of states (such as, extremely small, very small, somewhat small, medium, somewhat high, very high, extremely high), leading to many different states for the artifact itself. In the same way, we can define the other aspects of our development process and use diagrams to illustrate the activities and their interconnections. Modeling the process in this way has many advantages, not the least of which is building a common under standing of what development will entail. If users, customers, and developers participate in defining and depicting Piccadilly’s development process, each will have expectations about what activities are involved, what they produce, and when each product can be expected. In particular, the combination of spiral model and risk table can be used to evaluate the risks periodically. With each revolution around the spiral, the probability and severity of each risk can be revisited and restated; when risks are unacceptably high, the process model can be revised to include risk mitigation and reduction techniques, as we will see in Section 3. TABLE 2 Artifact Definition Form for Artifact “Risk” 6. REAL-TIME EXAMPLE The Ariane-5 software involved the reuse of software from Ariane-4. Reuse was in tended to reduce risk, increase productivity, and increase quality. Thus, any process model for developing new Ariane software should include reuse activities. In particular, the process model must include activities to check the quality of reusable components, with safeguards to make sure that the reused software works properly within the context of the design of the new system. Such a process model might look like the simplified model of FIG. 17. The boxes in the model represent activities. The arrows entering the box from the left are resources, and those leaving on the right are outputs. Those entering from the top are controls or constraints, such as schedules, budgets, or standards. And those entering from below are mechanisms that assist in performing the activity, such as tools, databases, or techniques. The Ariane-4 reuse process begins with the software’s mission, namely, controlling a new rocket, as well as software from previous airframes, unmet needs, and other soft ware components available from other sources (such as purchased software or reuse repositories from other projects). Based on the business strategy of the aerospace builder, the developers can identify reusable subprocesses, describe them (perhaps with annotations related to past experience), and place them in a library for consideration by the requirements analysts. The reusable processes will often involve reusable components (i.e., reusable requirements, design or code components, or even test cases, process descriptions, and other documents and artifacts).
Next, the requirements analysts examine the requirements for the new airframe and the reusable components that are available in the library. They produce a revised set of requirements, consisting of a mix of new and reused requirements. Then, the designers use those requirements to design the software. Once their design is complete, they evaluate all reused design components to certify that they are correct and consistent with the new parts of the design and the overall intention of the system as described in the requirements. Finally, the certified components are used to build or change the soft ware and produce the final system. As we will see in later sections, such a process might have prevented the destruction of Ariane-5. 7. WHAT THIS SECTION MEANS FOR YOU In this section, we have seen that the software development process involves activities, resources, and products. A process model is useful for guiding your behavior when you are working with a group. Detailed process models tell you how to coordinate and collaborate with your colleagues as you design and build a system. We have also seen that process models include organizational, functional, behavioral, and other perspectives, so you can focus on particular aspects of the development process to enhance your understanding or guide your actions. 8. WHAT THIS SECTION MEANS FOR YOUR DEVELOPMENT TEAM A process model has clear advantages for your development team, too. A good model shows each team member which activities occur when, and by whom, so that the division of duties is clear. In addition, the project manager can use process tools to enact the process, simulating activities and tracking resources to determine the best mix of people and activities in order to meet the project’s budget and schedule. This simulation is done before resources are actually committed, so time and money are saved by not having to backtrack or correct mistakes. Indeed, iteration and incremental development can be included in the process model, so the team can learn from prototyping or react to evolving requirements and still meet the appropriate deadlines. 9. WHAT THIS SECTION MEANS FOR RESEARCHERS Process modeling is a rich field of research interest in software engineering. Many software developers feel that, by using a good process, the quality of the products of development can be guaranteed. Thus, there are several areas into which researchers are looking: • Process notations: How to write down the process in a way that is understandable by those who must carry it out • Process models: How to depict the process, using an appropriate set of activities. resources, products, and tools • Process modeling support tools: How to enact or simulate a process model, so re source availability, usage, and performance can be assessed • Process measurement and assessment: How to determine which activities, resources, subprocesses, and model types are best for producing high-quality products in a specified time or environment Many of these efforts are coordinated with process improvement research, an area we will investigate in Section 13. 10. TERM PROJECT It is early in the development process of the Loan Arranger system for FCO. You do not yet have a comprehensive set of requirements for the system. All you have is an overview of system functionality, and a sense of how the system will be used to support FCO’s business. Many of the terms used in the overview are unfamiliar to you, so you have asked the customer representatives to prepare a glossary. They give you the description in Table 3. === === TABLE 3 Glossary of Terms for the Loan Arranger Borrower: A borrower is the recipient of money from a lender. Borrowers may receive loans jointly; that is, each loan may have multiple borrowers. Each borrower has an associated name and a unique borrower identification number. Borrower’s risk: The risk factor associated with any borrower is based on the borrower’s payment history. A borrower with no loans outstanding is assigned a nominal borrower’s risk factor of 50. The risk factor de creases when the borrower makes payments on time but increases when a borrower makes a payment late or defaults on a loan. The borrower’s risk is calculated using the following formula: Risk = 50 — [ x (number of years of loans in good standing)] + [ x (number of years of loans in late standing)] + [ x (number of years of loans in default standing)] For example, a borrower may have three loans. The first loan was taken out two years ago, and all payments have been made on time. That loan is in good standing and has been so for two years. The second and third loans are four and five years old, respectively, and each one was in good standing until recently. Thus, each of the two late-standing loans has been in late standing only for one year. Thus, the risk is: 50 — [ x 2 + [ X (1 + 1)] + [ 01 = 70. The maximum risk value is 100, and the minimum risk value is 1. Bundle: A bundle is a collection of loans that has been associated for sale as a single Unit to an investor. Associated with each bundle is the total value of loans in the bundle, the period of time over which the loans in the bundle are active (that is, for which borrowers are still making payments on the loans), an estimate of the risk involved in purchasing the bundle, and the profit to be made when all loans are paid back by the borrowers. Bundle risk: The risk of a loan bundle is the weighted average of the risks of the loans in the bundle, with each loan’s risk (see loan risk, below) weighted according to that loan’s value. To calculate the weighted average over n loans, assume that each loan Li has remaining principal Pi and loan risk Ri. The weighted average is then: 
Discount: The discount is the price at which FCO is willing to sell a loan to an investor. It is calculated ac cording to the formula Discount = (principal remaining) X [ rate) x (0.2 + (.005 x (101 — (loan risk))))] Interest rate type: An interest rate on a loan is either fixed or adjustable. A fixed rate loan (called an FM) has the same interest rate for the term of the mortgage. An adjustable rate loan (called an ARM) has a rate that changes each year, based on a government index supplied by the U.S. Department of the Treasury. Investor: An investor is a person or organization that is interested in purchasing a bundle of loans from FCO. Investment request: An investor makes an investment request, specifying a maximum degree of risk at which the investment will be made, the minimum amount of profit required in a bundle, and the maximum period of time over which the loans in the bundle must be paid. Lender: A lender is an institution that makes loans to borrowers A lender can have zero, one, or many loans Lender information: Lender information is descriptive data that are imported from outside the application. Lender information cannot be changed or deleted. The following information is associated with each lender: lender name (institution), lender contact (person at that institution), phone number for contact, a unique lender identification number. Once added to the system, a lender entry can be edited but not removed. Lending institution: A synonym for lender. See lender. Loan: A loan is a set of information that describes a home loan and the borrower identifying information associated with the loan. The following information is associated with each loan: loan amount, interest rate, interest rate type (adjustable or fixed), settlement date (the date the borrower originally borrowed the money from the lender), term (expressed as number of years), borrower, lender, loan type (jumbo or regular), and property (identified by the address of the property). A loan must have exactly one associated lender and exactly one associated borrower. In addition, each loan is identified with a loan risk and a loan status. Loan analyst: The loan analyst is a professional employee of FCO who is trained in using the Loan Arranger system to manage and bundle loans. Loan analysts are familiar with the terminology of loans and lending, but they may not have all relevant information at hand with which to evaluate a single loan or collection of loans. Loan risk: Each loan is associated with a level of risk, indicated by an integer from 1 to 100. 1 represents the lowest-risk loan; that is, it is unlikely that the borrower will be late or default on this loan. 100 represents the highest risk; that is, it is almost certain that the borrower will default on this loan. Loan status: A loan can have one of three status designations: good, late, or default. A loan is in good status if the borrower has made all payments up to the current time. A loan is in late status if the borrower’s last payment was made but not by the payment due date. A loan is in default status if the borrower’s last payment was not received within 10 days of the due date. Loan type: A loan is either a jumbo mortgage, where the property is valued in excess of $275,000, or a regular mortgage, where the property value is $275,000 or less. Portfolio: The collection of loans purchased by FCO and available for inclusion in a bundle. The repository maintained by the Loan Arranger contains information about all of the loans in the portfolio. This information clarifies some concepts for you, but you are still far from having a good set of requirements. Nevertheless, you can make some preliminary decisions about how the development should proceed. Review the processes presented in this section and determine which ones might be appropriate for developing the Loan Arranger. For each process, make a list of its advantages and disadvantages with respect to the Loan Arranger. 11. KEY REFERENCES As a result of the Fifth International Software Process Workshop, a working group chaired by Keliner formulated a standard problem, to be used to evaluate and compare some of the more popular process modeling techniques. The problem was designed to be complex enough so that it would test a technique’s ability to include each of the following: • multiple levels of abstraction • control flow, sequencing, and constraints on sequencing • decision points • iteration and feedback to earlier steps • user creativity • object and information management, as well as flow through the process • object structure, attributes, and interrelationships • organizational responsibility for specific tasks • physical communication mechanisms for information transfer • process measurements • temporal aspects (both absolute and relative) • tasks executed by humans • professional judgment or discretion • connection to narrative explanations • tasks invoked or executed by a tool • resource constraints and allocation, schedule determination • process modification and improvement • multiple levels of aggregation and parallelism Eighteen different process modeling techniques were applied to the common problem, and varying degrees of satisfaction were found with each one. The results are reported in Kellner and Rombach (1990). Curtis, Kellner, and Over (1992) present a comprehensive survey of process modeling techniques and tools. The paper also summarizes basic language types and constructs and gives examples of process modeling approaches that use those language types. Krasner et al. (1992) describe lessons learned when implementing a software process modeling system in a commercial environment. Several Web sites contain information about process modeling. • The U.S. Software Engineering Institute (SEI) continues to investigate process modeling as part of its process improvement efforts. A list of its technical reports and activities can be found at http://www.sei.cmu.edu. • The European Software Process Improvement Foundation’s newsletter, ESPI Exchange, reports on process activities worldwide. The ESPI Foundation Web site is http://www.espi.co.uk. • The European Community has long sponsored research in process modeling and a process model language. Synopses about current research projects are available here. • The IEEE Technical Council on Software Engineering maintains a software process newsletter at http://www.se.cs.mcgill.ca. You can find out more information about Lai notation and supporting tools from the International Software Process Constellation, Inc., in Reston, Virginia. The University of Southern California’s Center for Software Engineering has developed a tool to assist you in selecting a process model suitable for your project’s requirements and constraints. It can be ftp-ed , and more information can be found on the Center’s Web site: http://sunset.usc.edu. Journals such as Software Process—Improvement and Practice have articles ad dressing the role of process modeling in software development and maintenance. They also report the highlights of relevant conferences, such as the International Software Process Workshop and the International Conference on Software Engineering. The July/August 2000 issue of IEEE Software focuses on process diversity and has several articles about the success of a process maturity approach to software development. 12. EXERCISES 1. How does the description of a system relate to the notion of process models? For example, how do you decide what the boundary should be for the system described by a process model? 2. For each of the process models described in this section, what are the benefits and draw backs of using the model? 3. For each of the process models described in this section, how does the model handle a significant change in requirements late in development? 4. Draw a diagram to capture the process of buying an airplane ticket for a business trip. 5. Draw a Lai artifact table to define a module. Make sure that you include artifact states that show the module when it is untested, partially tested, and completely tested. 6. Using the notation of your choice, draw a process diagram of a software development process that prototypes three different designs and choose the best from among them. 7. Examine the characteristics of good process models described in Section 4. Which characteristics are essential for processes to be used on projects where the problem and solution are not well-understood? 8. In this section, we suggested that software development is a creation process, not a manufacturing process. Discuss the characteristics of manufacturing that apply to software development and explain which characteristics of software development are more like a creative endeavor. 9. Should a development organization adopt a single process model for all of its software development? Discuss the pros and cons. 10. Suppose your contract with a customer specifies that you use a particular software development process. How can the work be monitored to enforce the use of this process? 11. Consider the processes introduced in this section. Which ones give you the most flexibility to change in reaction to changing requirements? 12. Suppose Amalgamated, Inc., requires you to use a given process model when it contracts with you to build a system. You comply, building software using the prescribed activities, resources, and constraints. After the software is delivered and installed, your system experiences a catastrophic failure. When Amalgamated investigates the source of the failure. you are accused of not having done code reviews that would have found the source of the problem before delivery. You respond that code reviews were not in the required process. What are the legal and ethical issues involved in this dispute? |
