Con Relación A Los Procesos De Lectura: de acuerdo con Dubois (1991): Existen tres concepciones sobre el proceso de lectura La primera

Proponents of the use of agile methods for software development nearly always claim that it reduces costs and speeds the development schedule by simplifying the management of agile projects. We will examine these claims by considering one particular case study with which I am highly familiar. Of course the results of a single case study, or even a group of them, cannot prove the claims of reduced costs and development times for all agile proj- ects, but these results can provide some guidance. The lessons learned from this case study are believed to be typical of projects that are well suited to the use of agile methods because

of the experience of the agile development team and the support of senior management for using agile development.

The particular case study of agile development discussed in this book took place in the application domain area that can generally be described as space satellite operations.

As is typical in case studies involving a series of actual software projects in industry and government, names of participants, their companies, and specific project details will not be provided. This limitation is almost always due to issues of confidentiality. A search for the name of the project leader provided over 565,000 hits on Google in February 2014, which is a large number for anyone not named Kardashian.

The project team had seven members: two government employees and five contractors representing several different companies. The most important attributes of the team were that it had a wealth of experience in this application domain and understood that the bud- get pressures required radical process improvement.

As is true in almost any organization that has existed for many years, team members had somewhat of a blind spot for not using existing software components that they could they could have used readily in their projects. This blind spot is often referred to as the “Not Invented Here Syndrome” (Webb et al., 2010).

In the first use of this agile process, many people complained about the inability to identify “who was in charge.” This was troubling to senior management at the time. Fortunately, due to senior management’s confidence in the ability and experience of the team, the experiment in this agile process was allowed to continue, even though initial results were not promising.

With the advantage of hindsight, this difficulty was a good thing, because it indicated that a transition was occurring from a rigid, closed, hierarchical control mechanism, which tends to be less efficient at learning new things, to a more open, distributed team- based control mechanism, which allows for much more learning.

Learning was important. The seven-member team was part of a larger effort in which multiple teams and internal organizations competed to get their ideas implemented. The working premise was that maximum learning capacity would have no management or coordination, just progress toward the product.

We can measure the degree of self-organization by a ratio of the activities devoted to management, coordination, and control over the remaining activity. The closer the ratio is to zero, the more self-organized and less hierarchical is the team. This ratio, described as the “self-organizing factor,” or SOF, is

SOF = (Management + External test)/(Management + Systems engineering + Requirements gathering + Implementation + Internal test + External test + Software maintenance + System administration + Documentation)

A factor based on size was derived for each project to further normalize the numbers based on percentage of reuse and size of the code produced.

In this study, the projects with an SOF closer to zero tended to make larger improve- ment in costs and reduction of testing effort, as is illustrated in Figure 2.6. It is believed that innovation was enabled because obstacles had been removed and the teams could manage their “team model” more synergistically and with less effort expended on administrative control.

The process used two tools to aid in the development process: a Concurrent Version System for configuration management and a Comprehensive Discrepancy System for keep- ing track of errors and how they were removed during development. Although software tools for configuration management and error tracking have been available either as inex- pensive applications as stand-alone systems for more than thirty-five years or as part of integrated development environments (IDEs) for nearly as long, there were some aspects of their use that merits discussion.

The Concurrent Version System for configuration management allowed team members to configure both software and documents online. This is typical in any type of modern collaborative distributed software development, such as Eclipse, but the extension to docu- ments, which were often created in a word processor, was unusual at the time. Each word processing document had a tag in the form of a few lines of text indicating if the document had been modified.

The Comprehensive Discrepancy System was an online database that helps to man- age discrepancies identified in testing and helps to track resolutions. As a special feature, the Comprehensive Discrepancy System could provide assorted metrics that would allow tracking of progress and assessing lessons learned (e.g., where and what kind of errors occurs in development). This also is typical in any type of modern collaborative distributed software development but was not typical of projects at that time.

There may be another confounding factor that supported the agile team’s performance. NASA had used the Myers-Briggs Type Indicator Test to help determine personnel alloca- tions for many years. This test rated people as introvert or extrovert, sensing or intuiting, thinking or feeling, and judging or perceptive, after which they were placed in one of four quadrants. A highly creative team member I knew extremely well scored high on being an intuitive extrovert. The team was highly balanced across the Myers-Briggs spectrum.

0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 1 2 3 4 5 6 7 8 SO F

The well-known computer science professor Lisa Kaczmarczyk wrote a fascinating arti- cle on the experiences of introverts in computing, especially as pertains to agile processes (Kaczmarczyk, 2013). Here are some quotes from the article.

A relatively senior developer said, describing the use of agile processes in a large multinational company:

“… where there are language barriers between team members, agile still means daily communications between many members of the team, but typically across a chat interface. This suits introverts in many cases, although (in my opinion) doesn’t really work well in this scenario …”

A different, more junior, software developer at a different company said: “I don’t mind working with someone when I’m working through a difficult prob- lem or out of ideas on something, but if I’m just blasting my way through a task, I don’t see the point of having someone else there …”

SUMMARY

Software project management is the systematic application of general management tools and techniques to improve the efficiency of the software development process. Software team activities include

• Systems analysis team • Planning team • Requirements team • System design team • Implementation team • Testing and integration team • Training team

• Delivery and installation team • Maintenance team

• Quality assurance team • Metrics team

• Documentation team • System administration team • Reuse and reengineering team • Human–computer interface evaluator

• Tools support person • Software economist • Project librarian

All these activities have to be coordinated by a project manager. He or she will also be responsible for ensuring that the resources available to the project will be used appropriately.

Agile software development processes require management even though the partici- pants are likely to be highly experienced professionals already working in the project’s application domain. It may take considerable time for an agile process to become effective and, therefore, agile processes need the strong support of the organization at sufficiently high management levels. Agile processes often make use of self-organizing teams.

KEYWORDS AND PHRASES

software project management, software teams, project plan, project staffing, deliverables, software cost estimation, CASE, CASE tools, COCOMO, groupware, wiki

FURTHER READING

There are many excellent books on software project management. One of the best is Watts Humphrey’s classic book Managing the Software Process (Humphrey, 1989), which is still a big seller even though it is more than twenty-five years old. Tom DeMarco’s book on this topic (DeMarco, 1982) is also very useful, and is surprisingly up to date for a book written in 1982.

Another book by Humphrey (1995) describes the “personal software process” that can help a programmer determine the software engineering activities (requirements, design, implementation, testing, etc.) that consume most of his or her time. A major feature of this book is a set of graded exercises that are intended to provide a database of quantita- tive measurements of project experiences for individuals to improve their capabilities as software engineers.

A somewhat different view of software project management is presented in Jim McCarthy’s book (McCarthy, 1995) titled Dynamics of Software Development. It describes experiences with software projects at Microsoft.

The 2014 Research Edition of the Software Almanac from Software Quality Management contains a discussion of some metrics for managing projects, along with some case studies. It is available for download at qsm.com.

The 1981 book by Barry Boehm (1981) is still one of the best references on software project resource estimation. It presents the COCOMO model in detail. The COCOMO 2 model, also created by Boehm, extends the COCOMO model. Other commonly used cost models are SEER (Galorath and Evans, 2006) and Win-Win (Boehm, 1998). The SEER and SLIM software cost estimation tools are part of larger suites used for software project estimation. They can be found at galorath.com and qsm.com, respectively. See my encyclo- pedia article on cost estimation (Leach, 1999) for an overview of this subject. Also see the article by Terry Bollinger and Shari Lawrence Pfleeger (1990) for information on the use

of return on investment (ROI), which is often used to determine the costs and benefits if a particular software project is to be started.

Read the recent articles by Lisa Kaczmarczyk (2013) and Phillip Armour (2013) in their entirety for some perspectives on the use of agile and other fast software development processes.

The short, inexpensive book by Chris Sims and Hillary Louise Johnson provides a fast but comprehensive introduction to agile project management (Sims and Johnson, 2014).

For more about disruptive business practices, of which cloud computing is just one example, see the book by Nicholas Webb and Chris Thoen (2010).

EXERCISES

1. Examine an IDE that you have used before and determine if it is possible for two or three people to work on the same project concurrently. If no capability exists within the IDE, describe how you would organize communication between the team members.

2. What are the “test driver attributes” for the COCOMO model?

3. What activities should be present in a project plan? Does your answer depend upon the software development life cycle used?

4. What milestone events should be indicated in a project management plan?

5. Examine the Internet web pages of some government organizations that develop soft- ware. Choose one project and determine which software requirements or designs are available to you. Then estimate the amount of effort and resources needed to com- plete the software projects you have found.

6. Examine the Internet web pages of some companies that develop software project management tools. Determine if these tools allow a user to estimate the amount of effort and resources needed to complete the software projects you typically develop. 7. Examine several of the projects you did in your previous computer science courses.

Use these projects to determine your productivity by comparing the number of lines of code of each of the projects with the amount of time used for each project, which is the difference between the date the project was assigned and the date you turned it in, multiplied by a factor that represents the average number of hours you spent on the project each day. Did the average amount of time represent an accurate view of how you spent your time or was most of your work done very close to the project deadline?

8. Draw a diagram showing the major software engineering tasks for the rapid proto- typing software development model. Use Figure 2.2 as a model.

9. Draw a diagram showing the major software engineering tasks for the spiral software development model. Use Figure 2.2 as a model.

10. This question concerns the COCOMO model of software cost estimation. Examine a software system for which there have been multiple releases and for which source code is available to you. (The GNU software tools from the Free Software Foundation are an excellent source for this question.) Describe the system as organic, embed- ded, or intermediate. Examine the amount of new and reused code in the latest two releases. Does the time estimate predicted by the COCOMO model agree with the time between these releases? Explain.

11. Obtain a copy of an organization’s software project management manual. Find out how staffing and resource allocation is determined. Are any CASE tools mentioned in the manual?

12. Examine a project you recently completed. Determine which activities were on the critical path of development and which ones could have been done concurrently. Would having this knowledge before the project started have made the software development process more efficient?

13. Develop a project plan for treating the “Year 2038 Problem” where the date fields used in UNIX systems will overflow sometime in the year 2038. The overflow is due to the maximum size of an integer. Many functions that use time in UNIX systems use the time as measured in seconds from 1970 and this number will eventually be too large to be stored in a 32-bit integer.

14. Develop a plan for the Social Security number overflow problem that will occur when the increased population of the United States together with the number of Social Security numbers already issued exceeds the capacity of the nine digits currently used for storage of the Social Security number. In your project plan, consider if Social Security numbers should be reused if they were issued to a person who is now deceased. Be sure to consider all possible classes of Social Security benefits.

15. This is a thought question, since little actual data to validate your answer will be available to you. In Section 2.4, we considered the relationship of the size of a hypo- thetical software project and the number of software engineers that would be needed to complete the project. We made the assumption that the projects would consist solely of new lines of code. (The data was presented in Tables 2.1 and 2.2.) Now you are to consider the same project but under the assumption that one half of the code would be existing reusable code by this hypothetical project. What would you expect to be the effect of this reuse in terms of the number of software engineers needed? Does your answer depend on the nature of the software development team, on when in the development life cycle a decision is made to reuse the source code, or what can be expected in the quality of the code? Give reasons to justify your answers. (You might consult a book on software reuse.)

89

C h a p t e r

3