Guideline: Process Discriminants var backPath = './../../../'; var imgPath = './../../../images/'; var nodeInfo=[{view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_jD8dUAIbEdqEutyfYo0quQ", "_2ClPcDIcEdqDs_9ORT1Rig", "2.746702783003723E-305"]}]; contentPage.preload(imgPath, backPath, nodeInfo, '', false, false, false); Guideline: Process Discriminants This guideline describes the factors that affect how a process is customized for a project. Relationships Related Elements Tailor the Development Process for the Project Main Description Overview The software-development process is influenced by the following factors: Domain factors such as application domain, business process to support, user community, and offerings available from competitors. Lifecycle factors such as time-to-market, expected life span of the software, and planned future releases. Technical factors such as programming language, development tools, database, components frameworks, and existing software systems. Organizational factors. These factors are not equally important. The following sections describe some of the main factors-those most likely to affect the overall shape of the development process, and how you implement the process and tools in the development organization. The Business Context The business context describes the context in which the software is developed.  There are different types of business contexts that affect how to best customize the process. Examples of business contexts are: Contract work where the developer produces software to a given customer specification and for this customer only. Speculative or commercial development where the developer produces and covers the cost of putting the software on the market. Internal projects where customer and developer are in the same organization. There are many intermediate situations; for example, those where only part of the software development is subcontracted, those where the geographical dispersion is an additional factor, and so on. The total number of distinct stakeholders is a good indicator of the business context. The business context affects the level of ceremony, the level of formality, and the rigidity of the process. The more stakeholders-buyers, customers, subcontractors, regulatory bodies, and so on-involved, the more likely the project will need to produce formal evidence, such as documents, reports, and prototypes, at major project milestones. The Size of the Software Development Effort The size of the software development effort as defined by certain metrics such as Source Lines of Code (SLOC), Delivered Source Instructions or Functions Points, number of person-months or merely the cost. The effort's size will affect the level of ceremony, the level of formality, and the rigidity of the process. The larger the project, the larger the development team and, regardless of the business context, the more formality and visibility the various teams and management need to have in requirements, interfaces, and progress indicators. Communication issues on large projects are further aggravated by geographically dispersed teams. The Degree of Novelty The degree of novelty is based on what has preceded this software effort relative to the development organization and, in particular, whether the development is in a second or subsequent cycle. This includes the maturity of the organization and its process, its assets, its current skill set, and issues such as assembling and training a team, acquiring tools, and other resources. A project's degree of novelty affects the process in a completely different way. A new project-the first of its kind-significantly affects the dynamic configuration: the inception and elaboration phases will be longer, and may span several iterations. Also more emphasis will be put on eliciting and capturing requirements, on use-case modeling, on architecture, and on mitigating risk. For a project that is an evolution cycle from a previous system, change management is more crucial and incorporating legacy code poses some technical challenges. Novelty is not only relative to the system being developed, it's also relative to the maturity of the performing organizations because introducing new techniques or tools affects the process. In particular, introducing the Rational Unified Process (RUP) itself to an organization must be phased in careful steps. An organization will present some inertia to the adoption of a new process and the adoption strategy must take into account a smooth transition from existing practices to new ones. Type of Application There are different types of applications, for example, embedded real-time systems, distributed information systems, telecom systems, Computer-Aided Software Engineering (CASE) tools, and so on. The type of application will affect the process, especially with respect to specific constraints the domain may impose on the development such as safety, performance, internationalization, memory constraints, and so forth. The type of application may affect the process if the application is mission-critical; for example, the flight-control system in an airplane. A mission-critical system requires a higher level of ceremony in general, both to trace requirements and to assure the quality of the product. A mission-critical application also requires that more resources are spent on testing. The type of development, or the target domain, bring in process issues such as: Techniques and tools to support specific tasks; for example, automatic code generation for finite-state machines. Certification procedures; for example, for medical instrumentation. Compliance to standards; for example, for accounting or fiscal issues, and for telecommunication equipment. Type of Development There are various types of development, such as: Contract work where you develop a product for a specific customer. You have more stakeholders to manage and negotiate with when you perform contract work. There is often a need for more formal-external work products because the customer, or representatives, want to monitor progress and be kept informed. Make sure that the work products the customer reviews are easy to understand. Sometimes, there's a need to have a milestone where the project can offer a fixed-price on the rest of the project. In that case, you may need to add a new milestone or adjust the existing milestones. In other cases, you may have to adjust to the lifecycle model the customer is using with other milestones and phases. Speculative development where you develop a product for a mass-market. In speculative development, a marketing (product) manager, within the organization itself, acts as the customer. Time-to-market is often more important than the functionality in speculative development and there is less need for formal reviews. Internal development where you develop a product that is delivered to another department within the company. You may have to adjust to another lifecycle model if you deliver to another project that does not use the RUP. It may be acceptable to be more technical when describing work products because most work products will be reviewed by peers. Pre-studies where you do not normally develop a product. The purpose of a pre-study project is to find out whether it's possible to build a product. A pre-study project doesn't have the same milestones as a regular one. The Current Development Process In most cases, you won't replace the software-development process currently in practice in the organization because, in most cases, you'll implement the new development process step-by-step, focusing on the more critical and important areas first. Some of the current software-development process may even continue to exist for some time, perhaps forever. Problems and Root Causes What problems are identified and prioritized for the project influence those areas of the process you will concentrate on in the beginning of the process implementation. It's important to note that, if there is no established way of working in the organization, it may be pointless to find problems. See Concept: Implementing a Process in a Project. Instead, you may need to identify the root causes of the problems. To eliminate the problems, you will tackle the root causes by improving their process, introducing tools to automate the process, and training people.  Examples of common problems The following are examples of some common problems: Inability to manage scope-the organization routinely tries to do more than they actually do in the end. Inability to capture requirements-they have difficulty specifying requirements. Inability to manage changing requirements. Inability to manage requirements-requirements do not make it to the final product. Inability to estimate-they are routinely too optimistic about their ability to deliver on schedule. Design deficiency-they are good at meeting requirements, yet poor at designing systems. What kinds of design problems do they have? Are the systems difficult to maintain and enhance? Do they have performance problems, usability problems, capacity problems, and so on? Inability to produce quality products-the product has too many defects which may be due to lack of testing, but usually is also related to an inability to capture and manage requirements, as well as design deficiency. Unacceptable software performance. Low usability. Colliding developers-there is a lack of control over ownership and configuration management, so that developers make conflicting changes and work is lost. Late discovery of problems.  Trouble going from use cases to design. Examples of root causes A problem is often a symptom that something is wrong. You need to identify the root causes of the problems. The following are examples of some common root causes:   Insufficient requirements management Ambiguous and imprecise communications Brittle architectures Overwhelming complexity Undetected inconsistencies among requirements, designs, and implementations Insufficient testing Subjective project status assessment Delayed risk reduction due to waterfall development Uncontrolled change propagation Insufficient automation No systematic way to build user interfaces No way to go from use cases to a design Organizational Factors To implement the process in an organization, it depends on organizational factors such as the organization's capacity for change, organizational structure, culture in the project's organization and management, competencies and skills available, previous experiences, and current attitudes, The organizational factors also affect how the process is configured. For example, if the people in the organization have previously been using a software-development process description, then it will be easier to start using the RUP. On the other hand, if the people have not used a software-development process description, then you may decide to limit the scope of the process description. You could also put extra effort into making the process description easy to understand and use, making sure that it includes (or references) the information that will provide the greatest value. If there are some areas that are new to many of the people, then developing the best guidelines possible will make the transition easier. For example, if the programming language is new to many people, then you'll want to have very good Programming Guidelines and Design Guidelines to assist their learning. Attitudes Negative attitudes among an organization's personnel toward changing to a new technology, a new process or new tools is probably the biggest threat toward the successful implementation of process and tools. Over-enthusiasm toward process can also be a problem, because it can cause people to focus too much on the process. To assess people's attitudes towards the new technology, process, and tools ask questions like: What benefits do you see with the new technology? Will the new technology solve any of today's problems? What problems do you see with the new technology? What benefits do you see with the new process? Will the new process solve any of today's problems? What problems do you see with the new process? What benefits do you see with the new tools? Will the new tools solve any of today's problems? What problems do you see with the new tools? To assess people's motivation, find answers to questions like: Does everybody in the organization see why change is needed? Is everybody aware of what their competition is doing and how that affects the business? Is everybody aware of technology changes in the industry and how they affect the business?   Signs of a negative attitude may include statements like these: "Process doesn't help, it hinders." "Process means producing a lot of documents." "The process is overwhelming." Some ways to handle negative attitudes are: Motivate people by pointing at today's problems. Explain that a process doesn't dictate what you should do. The process must primarily be looked upon as a "help system", where you look for guidance, definitions, and so on. Explain that you only use small sections of the process. Nobody can master the entire process, and that is not the purpose. Compare the process to a bookshelf of books you read as you need their information. Run a successful pilot project where you show that the new process and tools work. Include one or two skeptics in the pilot project.  Signs of over-enthusiasm include these: People rely completely on the process and think it will solve all of their problems. Process is the silver bullet or magic formula that, if followed, will guarantee success. The project team wants to spend a lot of time and effort tailoring the process without first assessing the process-related problems that need resolution.  Some ways to handle over-enthusiasm are: Set expectations. The process will help, but it will not solve the problems. People solve problems. Talk people out of spending a lot of time tailoring the process. Focus people on developing the software products. Technical and Managerial Complexity Different types of systems, and their projects, can be classified in terms of the technical complexity of the system and the managerial complexity. The following figure illustrates one concept of how different systems can be classified. For example, a typical small business spreadsheet application is often of low technical complexity and is easy to manage. The other extreme is a typical weapon system project, which is often both technically complex, and complex to manage. Usually increasing system size, project duration or business context also increases the managerial complexity. Increasing the novelty, in either the problem domain or the solution space, increases the technical complexity. There is an interaction between managerial and technical complexity as well-many large projects are also technically complex. This results in: Increased managerial complexity that leads to more ceremony, including more formal reviews and milestones, and more work products. Increased technical complexity that leads to the introduction of specific techniques, roles and tools, and, therefore, more tasks. Systems are classified in terms of technical complexity and managerial complexity ©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved. contentPage.onload();