ADPD and UML Adoption

In this book, the world of management and Agile development always suggested that we adopt the simplest technology and methodologies that can fit the project you are dealing with. These are the questions that can arise: How can UML fit these requirements? Can UML be employed with Agile methodologies and particularly with ADPD? How many types of diagrams should be used profitably with ADPD? This chapter will try to answer these and other questions that are asked considering UML as a tool for aiding development and management of Agile projects. Agile developers usually draw UML diagrams on a board in order to have a topic to discuss about formalized well-know common language. On the other hand, when these diagrams are transferred to a tool capable of managing UML notation, you obtain the advantage of having a documentation automatically generated that can be updated to your needs. As introduced in Chapter XI, UML and the automated documentation that some tools can generate, starting from a set of UML diagrams, can substitute the ADPD project document. This approach to documentation compels the project manager to make some choices and decide if some parts of the project have to be documented or not. In any case, it is better that this choice be performed by the project manager, who can select the most important features to be documented among the whole project instead of compelling the reader of the documentation to cut according to his judgment.

Training

Training activities are related strictly to presentations, since each time you have to train someone, you need to present a set of topics to a group of people. Of course, training is a very different type of presentation for several reasons: The people that are listening to you usually are not skilled in the argument and, therefore, are not inclined to destroy your presentation with negative comments; the number of persons that are listening to you usually are few in the worst case (apart from academic lessons that are out of the scope of this book); and the duration of the training session is at least half a day and also can be several days, so that you can have time to socialize with all the people. Social aspects are very important during training, since interaction with people is not limited to the presentation time but also extends to all the coffee breaks and, in the case of a long training, to lunch or dinner, especially when you are training a partner or a customer at his or her site. Several of the tricks reported for presentations also are valid for training, especially the suggestions related to the speech, and therefore, such suggestions will not be discussed again in this section. For presentation, the main value that must be considered and addressed is communication, but in the training activity, some other values must be taken into account, such as simplicity and feedback. During a training session, simplicity and feedback are important as the communication capability, since simplicity usually improves and meliorates communication, and feedback aids in the dynamic revision of the presentation contents, improving simplicity and then communication. In order to have a clearer view of their influence, a short overview of these values follows.

Time Management

Time management is one of the most problematic issues to be addressed and to be understood well and transferred to the people belonging to the team. In order to understand the meaning of time management, it is necessary to deal with the concept of time and then with the concept of the unit cost of your time for the company. During each year, you usually work (without considering extra work) between 1,600 and 1,800 hours, and then, if you divide your gross annual pay (say $50,000), you obtain an hourly cost of your time between $27 and $31. Each hour you lose during your work time costs that amount of money to your company. Usually, if you are a team manager, for each hour you lose, your team in the complex loses about five times as much, and then a larger amount of money is thrown away for your company. In order to manage your time and the time of your team in the best way, it is necessary to approach the problem basing your efforts on some values, as suggested in the following.

Software Measurement

The problem of measurement in software engineering has been addressed by many authors, and one of the most common questions is, “Can we learn from measurement in physics and can we transform this to software engineering measurement?” (Zuse, 1997, 1998). An engineering measure, from the physical point of view, is relevant if it can quantify the object under measurement, since qualitative measures usually are considered too coarse. The problem arises when we shift this concept in software engineering, where nearly all the possible measurements are qualitative ones. All of the characteristics defined by ISO9126 (1991) are qualitative and not directly related to precise physical or tangible phenomena. On the other hand, a wide skepticism of using numerical values is diffused, because it can be hard to give the requested semantic to the number. Metrics, that are the measures performed on code, can be split into two categories: metrics for software complexity/size measurement and effort estimation, and metrics for qualitative characteristics evaluation. In the first part of the chapter, the former type of metrics is discussed, while in the second part, a general overview of quality in use by metrics will be performed. Apart from this general distinction, a more accurate taxonomy of the software metrics is reported in order to classify them on the basis of the applicability field in which they can be adopted.

Delegation

In this chapter, delegation is introduced, and the difference between delegation and assignment is reported and evidenced. The chapter proceeds by defining exactly what delegation means, presenting the WH (what and how) of the delegation process, since it is impossible to delegate each task, and the way in which you delegate must be carefully considered.

ADPD and SW-CMM

ADPD has been discussed in the previous chapter and introduced as an Agile methodology, but focused on reaching the Level 3 of SW-CMM (Paulk, Curtis, Chrissis, & Weber, 1993; Paulk, Weber, Garcia, Chrissis, & Bush, 1993). In this chapter, all the relationships between ADPD and SW-CMM at Level 3 will be discussed in order to verify how it is possible to adopt an Agile methodology and at the same time be compliant with standard methods such as the SW-CMM. In the chapter not related to Agile methodologies, a short introduction to SW-CMM has been reported, but in order to have clear detail of the matching between SW-CMM Level 3 and ADPD, it is necessary to describe in more detail the CMM Key Process Areas (KPAs) related to Levels 2 and 3. In Table 1, the KPAs for the target maturity levels are reported. KPA 2.4 will not be addressed in this discussion, since the target environment discussed in Chapter VII does not include the case in which subcontracting exists and since subcontracting requires a development method that is more structured; therefore, it is difficult to achieve by the ADPD or Agile methodologies, in general. Subcontracting can be considered for the sake of simplicity as COTS (components off the shelf); all the other KPAs must be addressed and satisfied. Paulk (2001) examines the relationships between XP and SW-CMM, evidencing if the KPAs are addressed totally, partially, or not at all.

The Target Business Environment

During the last few years, whoever has been involved in software development and management has noticed that two different kind of projects have arisen: very large projects carried on by large companies over long periods of time (i.e., 1 to 3 years) and small to medium projects developed in a shorter period (generally less than 1 year) by small companies. The second type of project deals mainly with recent technologies; these projects are usually Internet-related and are subject to change often and deeply in the specification (Boehm, 2000; Cusumano, 1999; Kroeker, 1999; Miranda, 2002). Moreover, since the latest technologies are on the edge and change quickly in their specifications, the technologies adopted during the project lifetime are subject to modification, and therefore, the code usually has to deal with deep modifications. The second part of this book is focused mainly on this second type of project that is often described as rapidly changing. In the following chapters, I will offer suggestions on how to manage and develop such projects in an environment that continuously changes and how to adapt to user modified needs and deal with technologies drift.

Project Maintenance

Maintenance is a phase that is usually placed after project completion when problems start to arise. Agile development changes this approach in depth, since maintenance is always the current status of the project. In this section, after a short introduction about maintenance model, the application of these models in classical and Agile methodologies will be discussed in order to highlight differences and focus the reader on the different approaches to this activity that can cost a lot if not well realized. The last part of this section is dedicated to metrics for the estimation of maintenance effort and on metrics for the prediction of faults in order to guide the reader in this very complex environment. All of you can select the metrics that seem to be well suited for approaching the problem of effort measurement or fault proneness detection.

Agile and Defined Project Development

In this chapter, the ADPD methodology will be presented and discussed. The name and the consequent acronym are due to the fact that I would like to create a methodology that is agile and, therefore, compliant to the Agile Manifesto, but that at the same time can be widely accepted and then also deployed in organizations that are not inclined to accept Agile development. The ADPD’s main aim is to eliminate the criticisms that often bound Agile methodologies with hacking or unstructured development. To obtain such results, the methodology must be compliant at least with the Software Capability Maturity Model, commonly known as CMM-SW (Paulk, 1993, 1993a) Level 3: the defined level. It also explains the second term of the acronym. Third and fourth terms are quite obvious and do not necessitate any further investigation. The compliance with CMM-SW Level 3 allows me to successfully apply this methodology in an environment where a standardization in terms of software or product quality is a must, since the Defined Level of CMM-SW allows you to match the requirements of most of the companies that usually do not agree with Agile methodologies and management. These are the main reasons for which I started to define a new methodology, mainly based on the concept of the first Agile methodology I have applied in real projects; that is, XP (Beck, 1999, 2000). I have inserted in ADPD all the positive aspects and techniques that are part of XP and that I was able to apply successfully in daily project management. I modified all the improvable aspects, inserting some new hints to the project manager and guaranteeing at least the compliance with CMM-SW Level 3.

Classical Methodologies, Techniques and Tools for Project Management

In order to better understand Agile methodologies, it is necessary to have a clear background of what software engineering has suggested in the past regarding the methodologies for approaching software development and software management (Agresti, 1986; Buxton, 1976; Ghezzi, 1990; Naur, 1969). For these reasons, in this chapter, the so-called classical methodologies for project management are considered and commented on, together with the techniques, meta-models such as the spiral life cycle, and tools such as risk management and assessment. It is important to know the background of software engineering in order to understand if Agile methodologies will fit your needs. In this chapter, the waterfall life cycle and a couple of evolutionary life cycles (Gilb, 1988), such as prototyping and spiral life cycles (Boehm, 1988), will be analyzed.