Project Management

Size Complexity

Software project management addresses the size complexity of software development. A software project needs to apply techniques and use tools to deal with three facets of size complexity: team, software, and functionality.

Team

The members of a software team have to communicate. The quality of this communication depends on the use of a shared common language that reduces the risk of noise, both during verbal communication and while sharing representations. An example of the latter is the sharing of a code base, which is the representation most frequently shared by the entire team, and so, coding conventions are set to enhance the communication.

The number of communication channels increase with the number of elements is a team, whenever a new member is added to the team she needs to establish communication channels to each one of the other members. This is a problem described by Fred Brooks as “adding manpower to a late software project makes it later” in his book The Mythical Man-Month. Although being an inherent problem of software engineering, and actually of knowledge-based disciplines in general, strategies have been proposed to alleviate the problem.

Software

A large base code is difficult to manage. On the one hand, developers simultaneously read and edit the code to implement and test functionalities. On the other hand, the code needs to be compiled and deployed into the execution machines.

Functionality

When the number of functionalities to be implemented is large, it is necessary to plan whether the project will be developed in a single step or if there will be several releases. Although not always possible, it is advantageous to have several releases due to the intertwine between problem understanding and solution construction in software development. Several releases allow frequent feedback cycles and the construction of software artefacts that will be closer to their purpose, fulfil the business goals of the customer.

An Incremental and Iterative Development is one the main strategies associated with planning in software engineering.

Risk Management

Risk management is a required discipline in any management activity. It identifies the possible risks that can occur in a project, analyzes them in terms of their probability and impact to prioritize them, and defines how to deal with these situations by reducing their probability or/and impact.

Risk management is particularly relevant in software engineering because there are several variables that are not easily controlled and which can change from project to project. In a software project undesirable events can occur is association with team, artefact, and functionalities. Whenever one of these variables changes in a project it is necessary to consider them as a source of risk.

For instance, a change in the programming language a team is using is a source of risk. To analyze the probability of the risk it is necessary to assess how the new language differs from the language the team is used to. To reduce the impact of change it may be advisable to use the new language in a project where all the other variables do not change: a project for a known client in a business area where the team already has the required expertize.

There are several lists about the main risks of software projects. The most cited list is Barry Bohem’s top ten risks. These sources constitute good checklists to identify the specific risks in a particular project. In Top Ten Lists of Software Project Risks : Evidence from the Literature Survey is done a synthesis of the existing lists to conclude that the main risks in a software project are associated with planning and control followed by requirements. However, these lists should be contextualized because depending on the perspective events can be differently interpreted. For instance, change in requirements was considered the top six risk by Barry Bohem but in the agile approaches the change of the requirements is seen as part of the game and it is an intrinsic part of their methods.

Software Metrics

“You can’t control what you can’t measure“[3] said Tom DeMarco, but Metrics in Software Engineering is not a consensual topic due to the tension between art and engineering in software. Even DeMarco, a few years later, An Idea Whose Time Has Come and Gone?, questioned the importance of control when the value of the product is much bigger than its cost, when there is creativity in the product, I would say.

Annotated Reading

(1) Patterns of Productive Software Organizations, by Neil B. Harrisson and James O. Coplien

  • The development of software is a social activity. In Software as a Social System we stressed the social aspects of the software artefacts. Here, we can take this vision further to the development organization itself. Therefore, if we consider P- and E-systems (Software as Art and Engineering), we cannot ignore the interplay of the social interactions around the use of artefact with the interactions around its construction. It is well-known that often organizations mimic their products and vice-versa.
  • The identification of the software development organization communication channels, at the level of the roles their members play, provides a level of abstraction over their member communication channels.
  • The role-based analysis of the communication channels of a development organization allows a self-awareness of the organization about its own structure.
  • Because, as the number roles increases, the number of communication channels only increases linearly, its an evidence that roles are a mean to reduce communication channels: The roles make up the organization.
  • “Highly productive organizations have high communication saturation” shows that software development is about creating and sharing knowledge.
  • There is another trade-off between the organizational structure and the concentration of communication in a single role. It seems that in more complex organizations the communication is more concentrated in the busiest roles: a hierarchical organization.
  • Productive organizations have fewer roles. The central roles are the productive roles. The productive roles are mainly consumers of information from the communication channels.
  • Having the developer at the center of the communication shows organizations that are not process-centric (Software as Art and Engineering).
  • “The activities of software design and coding were inseparably intertwined.” The intertwine of problem understanding and solution construction (Software as Art and Engineering).

(2) Technical Staff Organization, Functional Staff Organization, and Prefer Functional Staff Organization by Martin Fowler

  • Functional Staff Organization has a shared common understanding of the problem. Has a focus on the business, on the creation of value in the software artefact. Due to the lack of communication channels between technical people, it can occur duplication of solutions.
  • Technical Staff Organization has shared common understanding on the technology. They can generate more efficient technology solutions. Due to poor communication between the different types of description it does not take advantage of the intertwine between problem understanding and solution construction.

(3) The myth of the ultimate development organizational structure by Claude Remillard

  • It considers three dimensions: technical, functional and business. The business dimension corresponds to Martin Fowler’s Functional Staff.
  • The decision for an organizational structure implies mechanisms to deal with other dimensions. There is a dominant organizational structure, like there is a dominant decomposition in software. There is no silver bullet!

(4) Software Configuration Patterns by Steve Berczuk with Brad Appleton

  • The forces of isolation and collaboration drive the system build process. The Repository pattern defines an isolation context where developers implement their tasks. Afterwards, they commit the changes to the Mainline according to the Task Level Commit pattern.
  • Private System Builds and Integration Builds deal with the need to have a short implementation testing cycle during local development (Private System Build pattern) and suggest a more deep testing before integrating the code in the Mainline (Integration Build pattern). Smoke and Unit tests are mainly associated with the former whereas the latter also run Regression tests. Nightly build is a particular case of Integration build where the level of stability of the system is accessed.
  • Third Party Codelines contain the version of the libraries being used in the project. With build tools like Maven, these codelines are in the cloud, in the Central Repository.

(5) Feature Branch by Martin Fowler

(6) Outcome Oriented, Activity Oriented, and Business Capability Centric by Sriram Narayan

  • Team organization, pros and cons of centring on activity or centring on business

References

  1. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Steve Berczuk with Brad Appleton. Addison-Wesley. 2003.
  2. Controlling Software Projects: Management, Measurement, and Estimation. Prentice Hall/Yourdon Press. 1982.

TODO