Chapter 2

Launching DigitalHome

Project Launch

On 9/15/202X, the DH Team held a meeting with Karen Mullen, the lead for the DH needs assessment effort to discuss questions the team had about the DH Customer Need Statement and the DH High-Level Requirements Definition (HLRD), prepared by the HomeOwner Marketing Division. After the meeting, the HLRD was finalized.

In mid-September 202X, a two-day workshop meeting was held at the conference room of the office of the DigitalHomeOwner Division of HomeOwner to launch the DigitalHome project. In attendance was the Director of the DigitalHomeOwner Division, Jose Ortiz, Mr. Ortiz’s Admin Assistant, Stella Washington, the DH development team leader, Disha Chandra, and the other team members: Michel Jackson, Yao Wang, Georgia Magee, and Massood Zewail. Jose and Disha had met earlier and decided on the agenda for the meeting and developed a Project Launch Process (see Table 2.1). Part of the launch had already been completed: team roles and responsibilities had been assigned; and the team had studied the Need Statement and the HLRD and had met with a HomeOwner marketing representative to better understand what needed to be accomplished (see Chapter 1)

Table 2.1   DigitalHome Launch Process Script – 9/16/202X

Purpose	Guide the DigitalHome project launch
Entry Criteria	DH Customer Need Statement DH HLRD
Activity	Description
Team Formation	Determine and assign team roles and responsibilities Decide on individual and team goals Establish communication and reporting methods and protocols Determine support infrastructure (staff, tools, and facilities) Establish the DH Development Process Determine initial project budget
Need Analysis	Study and analyze the Need Statement and HLRD Hold meeting with HomeOwner marketing representatives to assist in needs analysis Write Needs Analysis Report
Conceptual Design	Develop a DigitalHome Context Diagram Develop a DigitalHome Conceptual Design
Development Strategy	Determine criteria for a development strategy Create Development Strategy Determine the development process Determine the number of development cycles Allocate development modules in each cycle Estimate module size and development effort for each cycle
Postmortem	Perform postmortem analysis of project launch activities
Exit Criteria	Needs Analysis Report Development process has been chosen Team formation has been completed DH Context Diagram DH Conceptual Design DH Development Strategy

Team Building

After the two-day workshop, Jose Ortiz and Disha Chandra met and decided to deliver a mini-tutorial on team building.

MiniTutorial 2.1: Building an Effective Team

Building a successful project team is one of the most crucial elements influencing project success. When project teams fail to exhibit effective teamwork, the project is more likely to have problems with schedule, budget, and quality. There is extensive research and analysis on the characteristics of effective teams and how to build them [DeMarco 1999, Ganis 2007, Humphrey 2000, Oakley 2004].

The following positive qualities have been found to be characteristic of effective teams:

• ■   Team members function efficiently and productively.

• ■   The teams share leadership and accountability for their work products.

• ■   Emphasis is shifted from the individual to the team.

• ■   Individual performance is based on achieving team goals.

• ■   Team operates in an environment of open and honest communication.

• ■   Problems are discussed and resolved by the team.

• ■   The team as a whole is greater than the sum of its parts.

The following problems often characterize ineffective teams:

• ■   Poor communication within the team

• ■   Inability to compromise or cooperate

• ■   Weak participation by a team member

• ■   Some team members do the majority of the work

• ■   Lack of discipline

• ■   Unclear decision-making process

• ■   Ineffective leadership

The question arises of how we build an effective team; that is, how do we form a team that possesses the above listed positive qualities and not the problems of ineffective teams. Unfortunately, many managers fail to appreciate the effort that has to be invested and the attention to detail needed for successful team formation. Forming an effective team is not just a matter of throwing a set of capable individuals together to accomplish a common goal (often an ill-defined goal).

There are lots of ideas and opinions, some divergent, on how to build effective teams. The following discussion presents techniques that have proved the most fruitful.

Set Goals

Setting team goals provides the foundation for successful teamwork. This can provide a shared sense of purpose, which unifies the team members and offers a framework for deciding on team direction and for assessing team performance. Goals should be measurable in order to assess project progress and to provide guidance on how to make adjustments, when there are problems. This means that progress toward reaching goals should be regularly monitored and measured.

The following are some example team goals:

• ■   Milestones, and associated deliverables, will be completed as scheduled.

• ■   The team will follow the prescribed changed control process.

• ■   Decisions will be made in a collaborative manner.

• ■   Data will be collected for the project (development process, productivity, quality customer satisfaction, etc.) and analyzed to assess progress, and product, and process quality.

Define Roles and Responsibilities

It is critical that each team member understands her/his role on the team and there is a clear description of the responsibilities and expectations for that role. This makes it easier to assign task leadership and establish solid working relationships between team members and to assess individual performance. It is unrealistic to expect all members of a team to undertake appropriate roles and responsibilities without some guidance and direction.

Table 1.2 in Chapter 1 provides an example of how roles and responsibilities might be defined. Notice that each role description includes a responsibility for leading or managing a significant part of the project activities. This is an example of shared responsibility, which is critical for the team to feel that work is distributed equitably and that all team members are essential to team success. It also illustrates that a variety of talents and capabilities are needed in such projects.

Establish Communication and Decision-Making Procedures

Even though team members may have reasonably good oral and written communication skills, in a common language, there are a number of issues that might negatively affect good communication:

• ■   One’s cultural background might influence how others understand the meaning and significance of what is being communicated.

• ■   Team members do not use active listening as part of their interaction with each other.

• ■   The team is too large or poorly organized for one-on-one or small group communication.

• ■   The team decision-making structure discourages or obviates open communication.

• ■   There are inadequate defined procedures and methods for communication: insufficient documentation standards, regular team meetings, and status reports; and limited use of communication technology such as online discussion groups, resources for storing and exchanging team documents, and the use of electronic communication.

An ill-defined or ineffective decision-making procedure can doom a team to failure. There are various team structures that influence communication patterns among members and prescribe the decision-making paradigm:

• ■   Controlled Centralized – this is top-down hierarchical decision structure, much like that existing in military organizations.

• ■   Democratic Decentralized – all decisions are made by group consensus of the team; all work is considered group work.

• ■   Controlled Decentralized – attempts to combine the benefits of centralized and decentralized control; there is centralized decision team, with communication decentralized to the rest or team (or subteams if the overall team is very large).

The team structure must fit the organizational structure, the application domain, the size and complexity of the project, and the competencies and experience of the team members.

Ensure a Team has Control of Its Work

Effective teams must have some control over their work, the more the better. While complying with project constraints (e.g., budget and schedule constraints), teams should control how they organize and plan their work and how they go about their day-to-day tasks. This approach supports building cohesive, committed teams.

Start with Team Building Activities

Team building activities can be conducted by a “team building” trainer or by a team member who has had success in building and leading effective teams. However, even seasoned professionals may need training – to be introduced to or reminded of what it takes to build an effective team. Examples of such activities include the following:

• ■   Develop a set of Team Goals

• ■   Complete the Team Problems exercise in Chapter 1

• ■   Develop a Team Policies Statement (describes team roles and the responsibilities, defines the decision-making policy, presents strategies for dealing with disputes between team members, describes the procedures for holding a team meeting – defined agenda, rules for interacting, meeting roles)

• ■   Develop a Team Expectations Agreement (a common set of realistic expectations that the members generate and agree to honor)

Exercise 2.1: Forming an Effective Team

Jose Ortiz and Disha Chandra felt after the team building tutorial the team needed to start working on forming a cohesive and effective team. The earlier Team Problems activity (see Chapter 1) was a good start, but they both felt an additional Team Formation activity was needed.

The exercise, described at the end of this chapter, deals with the Team Formation activity designed by Jose and Disha to help the DH Team become an effective cohesive working group.

Software Development Process

MiniTutorial 2.2: Software Process Fundamentals

A process is a set of practices performed to achieve a given purpose. A defined process would include such things as a process script, tools, methods, standards, and identified roles and responsibilities. Processes differ according to project scope, complexity, and domain; and they must accommodate a business’ goals and culture, and the developer experience. While process is often described as a leg of the process-people-technology triad, it may also be considered the “glue” that unifies the other aspects.

Software processes are designed and used to improve the development of software – cost, schedule, and quality. Table 2.1 displays a process script that describes a process for launching a software project (although it certainly could be used for non-software projects).

Plan-Driven Processes and Agile Processes

There are many approaches and opinions about how software should be developed. Boehm and Turner [Boehm 2004] provide an excellent summary and overview of various software methods and approaches. Processes are often classified as “Plan-Driven” or “Agile”.

Plan-Driven Processes (sometimes called “heavyweight” or “traditional”) typically incorporate repeatability and predictability, a defined process, extensive documentation, up-front system architecture, detailed plans, process monitoring and control, risk management, software configuration management, and well-formulated verification and validation. They are often criticized for their inflexibility, lack of innovation, and poor response to the need for change. Advocates of plan-driven methods point to the need for structure and discipline in the development of large, complex systems with long development schedules, large developer teams, and mission-critical systems dependent on safety, security, reliability, or other quality attributes that require a rigorous process.

Agile Processes (sometimes call “lightweight”) have been developed to address the criticism that plan-driven processes are unresponsive to change (e.g., change in requirements or change in technology). Agile processes have the goal of reducing the cost and time to make changes throughout a project. Agile developers advocate the following (referred to as the “Agile Manifesto”) [Highsmith 2001]:

• ■   Individuals and interactions over processes and tools

• ■   Working software over comprehensive software documentation

• ■   Customer collaboration over contract negotiation

• ■   Responding to change over following a plan

As with most two-category classification systems, the plan-driven processes versus agile processes debate often captures the extremes and ignores the middle ground. As we will see in the following discussion of various software processes, there is a “middle-weight” division – that is, in the application of any process model some combination and agile and plan-driven methods may be used.

Software Life Cycle Models

A software development life cycle (SDLC) consists of the various phases and activities that a software product or service goes through during its “life” – from its initial conceptual formulation to its specification, design, construction, and test, and forward to its operation and maintenance, and finally to its retirement/disposal.

A software life cycle model is a high-level depiction of the life cycle phases and how they relate to each other. In this mini-tutorial, we do not discuss all such models, but provide an overview of several popular models with intent to show the variety and flexibility of models. In the next section, we describe in more detail specific processes used to develop software.

Waterfall Model

The waterfall model is a SDLC that is intended to progress through its life cycle phases in a sequential manner, as depicted Figure 2.1. In reality, this is rarely the case. For example, if in the design phase a problem is discovered in the statement of a software requirement (maybe an imprecise or ambiguous statement), it may be necessary to return to the Requirements Analysis and Specification phase. Such situations occur often, especially in the development of large, complex systems. So although a linear or sequential SDLC may be intended, it is typical in practice that the process is iterative – cycling back through previous phases as problems are encountered or there are changes mandated by circumstances out of control of the developers. So although a process may appear fixed and unyielding to variation, in practice it must adopt some “agile” approaches.

Figure 2.1   Waterfall model.

The first formal description of the waterfall model was in an article by Winston W. Royce [Royce 1970]. Although there has been much criticism of a “pure” waterfall model, almost all software development models bear some similarity to the waterfall model. As we shall see in the other models discussed in this mini-tutorial, they all incorporate at least some phases similar to those used in the waterfall model.

Spiral Model

The spiral model, developed by Barry Boehm [Boehm 1988] and as depicted Figure 2.2, is a software development process, which combines the features of the prototyping and the waterfall model. Starting at the center, each turn around the spiral goes through several task regions:

Figure 2.2   Spiral model.

• ■   Determine the objectives, alternatives, and constraints for each new iteration.

• ■   Evaluate alternatives and identify and resolve risk issues.

• ■   Develop and verify a prototype and product artifact for the iteration.

• ■   Plan the next iteration.

Although the waterfall features of the Spiral Model might prompt a plan-driven approach, the cyclic nature of the Spiral, along with the evolution of prototypes, represents agile-type features.

V-Model

The V-Model, depicted in Figure 2.3 is a SDLC model that represents a restructuring of the waterfall model, with the non-testing software phases of the life cycle on the left side of the V and the testing phases on the right side of the V. The V-Model uses the double arrowhead dashed line to show the relationship between developing a software artifact (Need Statement, Requirements Specification, an Architectural Design document, Module Design document) with the test that will be used to verify the artifact. For example, when a software architecture for a system is determined, developers can, and they should, start planning for the test of integration of the architectural components. Likewise, when conducting an integration test, the defects discovered typically point to problems in the architecture. So, this is a two-way street.

Figure 2.3   V-Model.

Chapter 3 discusses the various testing phases, including their purpose, planning, execution, and analysis.

Incremental Model

Figure 2.4 illustrates the Incremental Model. The figure shows that a software system is built in increments and assembled as each increment is completed. There are a number of advantages of this approach:

Figure 2.4   Incremental model.

• ■   It uses a “divide and conquer” to reduce scope and complexity, allowing developers to concentrate on just a subset of the problem to be solved.

• ■   Since the scope of the first increment is necessarily less complex than the whole development activity, it provides an opportunity for project team to do some experimentation (e.g., use of a new tool or methodology) and learn new approaches, without great risk to the entire project.

• ■   The first increment also provides the opportunity for the project team to establish effective working relationships and communication mechanisms, without being overwhelmed by the size and complexity of the entire system development.

• ■   Depending on the nature of the increments, customers may be able to observe working portions of the system, providing timely feedback to developers and giving the customers a clear view of project progress.

An incremental approach is widely used by software developers and is incorporated in many software processes.

Capability Maturity Model

In the late 1980s, the Software Engineering Institute (SEI), at Carnegie Mellon University, developed the SW-CMM (Software Capability Maturity Model) to help organizations build effective software engineering processes [Paulk et al. 1993]. The SW-CMM and its successor the CMMI (Capability Maturity Model Integration) have been widely adopted in industry, primarily by large and moderate sized software development organizations.

The CMM is not a software process model, like the above models, but is rather a software process framework or a reference model of mature practices, which is organized into a five-level model encompassing good engineering and management practices. Figure 2.5 describes the five levels of maturity practices.

Figure 2.5   SW CMM maturity levels.

This framework is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. Although some aspects of the model may be involved in agile processes [Paulk 2001], it has primarily been used in organizations that adopt a plan-driven approach.

Specific Software Processes

In this section, we describe specific defined software processes that are used by project teams in the life cycle development of software. All the processes are customizable and are typically adapted to the project application domain and to an organization’s structure and culture. Although our discussion is not exhaustive, it illustrates a range of plan-driven and agile methods.

Unified Process

The Unified Process (UP) is an iterative and incremental software development process model [Scott 2002]. The best-known refinement of the UP is the Rational Unified Process [Kruchten 2004]. Figure 2.6 displays the UP phases:

Figure 2.6   UP process.

• ■   Inception – Define the scope of the project and develop the business case.

• ■   Elaboration – Plan project, specify features, and baseline the architecture.

• ■   Construction – Build the product.

• ■   Transition – Transition the product to its users.

UP practices include the following:

• ■   Iterative development within the Inception, Elaboration, Construction, and Transition phases

• ■   Each iteration through each of the phases results in an “increment” release

• ■   Use cases, discussed in Chapter 5, are used to capture the functional requirements and to define the contents of the iterations

• ■   Architecture provides the focus for system development efforts to the most critical risks that are addressed in the early phases of development

eXtreme Programming Process

The eXtreme Programming (XP) process is an agile process designed for work in small to medium teams (less than ten members), building software with vague or rapidly changing requirements, and it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. The XP life cycle has four basic activities [Beck 2000]:

• ■   Continual communication with the customer and within the team

• ■   Simplicity, achieved by a constant focus on minimalist solutions

• ■   Rapid feedback through unit and functional testing

• ■   Emphasis on dealing with problems proactively

Figure 2.7 depicts XP practices, some of which are described as follows:

Figure 2.7   XP practices.

• ■   Planning Game – Quickly determine the scope of the each release by combining business priorities and technical estimates. The customer decides scope, priority, and dates from a business perspective, whereas technical people estimate and track progress.

• ■   Small Releases – Puts a simple system into production quickly. Release new versions on a very short (2 week) cycle.

• ■   Metaphor – Guide all development with a simple shared story of how the overall system works.

• ■   Test-Driven Development – Developers continually write unit tests (before unit design and code) that must run flawlessly for development to continue; customers write tests to demonstrate that features are finished.

• ■   Refactoring – Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.

• ■   Pair Programming – All production code is written by two programmers at one machine.

• ■   Continuous Integration – Integrate and build the system many times a day, every time a task is completed.

• ■   Collective Ownership – Anyone can change any code anywhere in the system at any time.

• ■   Coding Standards – Programmers write code in accordance with rules that emphasize communication throughout the code.

XP introduced a number of new practices and terms (pair programming and refactoring), but also uses certain plan-driven aspects (Planning Game and Coding Standards) and builds on the incremental model (Small Releases and Continuous Integration).

Scrum Process

The Scrum process is an empirical process – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements. Scrum concentrates on project management without dictating other software development practices (such as analysis, design, construction, and testing) [Schwaber 2004]. Figure 2.8 outlines the key features of the Scrum.

Figure 2.8   Scrum features.

A sprint is the basic unit of development in Scrum. The sprint duration is fixed in advance for each sprint and is normally between one week and one month. Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made. This is followed by a review where the team and the customer review and evaluate the product, and finally a retrospective meeting, where the process is assessed is reviewed and lessons and continuous improvement opportunities for the next sprint are identified.

The set of features that go into a sprint come from the Product Backlog, which is an ordered list of requirements. Which backlog items go into the sprint (the sprint goals) is determined during the sprint planning meeting.

Each workday, the Scrum team holds a Daily Scrum: the meeting lasts for 15 minutes and is held in the same location and at the same time; all members give updates; all are welcome, but normally only the core roles speak. The Scrum Master asks each team member three questions, in turn:

• ■   “What have you done since the last meeting?”

• ■   “What do you plan to do before the next meeting?”

• ■   “What impediments are in your way?”

Team Software Process

The Team Software Process (TSP) was developed by the SEI and includes most of the key process areas of the SW-CMM [Humphrey 2000, Davis 2003] and is considered a Level 5 process, at least at the team level (see Figure 2.4). The objective of the TSP is to create a team environment that supports disciplined individual work and builds and maintains a self-directed team.

Software is developed incrementally in multiple cycles, with each cycle made up of multiple phases. Figure 2.9 illustrates n-cycle version. Each cycle represents a life cycle development of some component of the final product with previous components integrated in each cycle.

Figure 2.9   TSP organization.

The TSP focuses on team-building, team-management, team member capability, quality assurance, and software process improvement. The defined team roles promote shared team management and a collegial work environment (e.g., Planning Manager and Support Manager). Although TSP uses mostly plan-driven methods, it does exhibit some agile features [Paulk 2001].

At the completion of the Software Process Fundamentals MiniTutorial, Massood approached Jose during one of the breaks and discussed the possibility of using an agile process (such as Scrum) for the development of the prototype. Jose had recently heard about the Scrum process and its adaptation in mainly software industries but was not really familiar with the process and its advantages and disadvantages. Since Massood was a new hire and the youngest member of the team, Jose did not want to ignore his suggestion. He was also intrigued by the idea that the most junior member of the team had taken initiative and proposed an alternate approach. Therefore, Jose told Massood that he would like him to prepare and deliver several Scrum MiniTutorials to educate the team about Scrum. This made Massood very happy, because he realized HomeOwner valued the opinion of every member of the team.

NOTE: The collection of the Scrum process MiniTutorials can be found in Chapter 10.

Exercise 2.2: Evaluating a Software Process

The Project Launch Process (Table 2.1) specifies the activity “Establish the DH Development Process”. So part of the two-day launch workshop was devoted to this topic.

Prior to the workshop, Jose Ortiz had prepared a draft of the DigitalHome Development Process Script (Table 2.2) to guide the DH project work. He requested that the DH project team review the process script and provide him with an evaluation of its viability, with comments and recommendations.

Table 2.2   DigitalHome Development Process Script

Purpose	Guide the development of the DigitalHome software system.
Entry Criteria	Identification of a problem or opportunity, which may need a software solution.
Phase	Activity
Project Inception	Establish the business case and feasibility for the project Determine the scope of the project Develop a customer need statement Develop a high-level requirements document
Project Launch	Establish development team, and their roles, responsibilities, and goals. Analyze Need Statement Establish a Development Process Identify External Interfaces and create Context Diagram Create a Conceptual Design Determine a Development Strategy Research and study of possible project technology
Planning (discussed in Chapter 4)	Develop Task, Schedule, and Resource Plans Develop a Risk Plan Develop a Quality Plan Develop a Configuration Management Plan Determine project standards and tools Perform project planning/tracking
Analysis (discussed in Chapter 5)	Review the Need Statement and prepare for requirements elicitation Elicit requirements from potential customers and users Analyze requirements and build object-oriented analysis models Specify and document requirements in an SRS Inspect and revise the SRS Obtain customer agreement to requirements Develop a System Test Plan Develop Requirements Traceability Matrix (RTM) Develop User Manual Track, monitor, and update plans (Task/Schedule/Quality/CM/Risk) & RTM
Architectural Design (discussed in Chapter 6)	Develop OO high-level design models Refine the OO analysis models Develop additional design models Specify and document design in an SDS (Software Design Specification) Develop a Build/Integration Plan Review and revise the SDS Consult with customer, and revise SRS and SDS, as appropriate Track, monitor, and update plans (Task/Schedule/Quality/CM/Risk) & RTM
Construction Increment 1, 2,... (discussed in Chapter 7)	Complete Class Specifications (data types and operation logic) Develop Increment (Class/Integration) Test Plan Set up appropriate test environment (e. g, test harness, stubs/drivers) Review the Class Specifications Write source code Review and test the source code Integrate code with previous increments Perform Increment (Class/Integration) Test Consult with customer, and revise SRS, SDS, and code, as appropriate Track, monitor and update plans (Task/Schedule/Quality/CM/Risk) & RTM
System Test (discussed in Chapter 3)	Update test environment Update System Test Plan Perform the System Test Consult with customer, and revise requirements, design, and code as appropriate Track, monitor, and update plans (Task/Schedule/Quality/CM/Risk) & RTM
Acceptance Test (discussed in Chapter 3)	Prepare Acceptance Test materials (including a user’s manual) Set up customer test environment Customer performs Acceptance Test Revise SRS, SDS, code, and User Manual as appropriate Track, monitor, and update plans (Task/Schedule/Quality/CM/Risk) & RTM
Postmortem	Perform postmortem analysis of project process and product quality
Exit Criteria	Completed SRS, SDS, RTM, User Manual, System Test Plan Source code for a thoroughly reviewed and tested program Completed plan documentation Project postmortem report

The exercise, described at the end of this chapter, deals with the evaluating the draft DH Development Process.

Development Strategy

On the second day of the DH Launch Workshop, Michel Jackson, the DH System Analyst, led the discussion of the DH Conceptual Design. Michel explained that they would be developing a Context Diagram for the DH system and a Conceptual Design, presenting a high-level view of the principle components for the DH system.

Massood Zewail said he understood the role of the context diagram (a view of how the system as a whole interacts with external entities) and why it was developed early in the process, but he did not understand why we would be doing design work prior to specifying the DH requirements. He was taught in his master’s program that developers should resist thinking about the design before the requirements are established – “don’t try to solve the problem before you understand it”.

Michel agreed that they should not try to design a solution before the DH requirements had been analyzed and specified. However, the “Conceptual” Design would not be an actual solution, but a rather a pre-planning document that would make it easier for the team to establish a development strategy and prepare a detailed project plan. The Conceptual Design would be like a “throwaway” user interface prototype: a tool used to show a user what the system looks like in order to elicit requirements, but thrown away once the requirements are discovered. Another advantage of the conceptual design is the fact that it will be used for project size and effort estimation.

Georgia Magee chimed in with a comment about her work at the Volcanic Power Company, where she was a member of an XP team. Georgia described the “Planning Game” method they used, early on the project, to develop a strategy for planning the project iterations; she thought was very helpful and agreed with Michel’s comments. Yao Wang added that he had worked on team that used the UP process, and in the Inception phase they developed a “candidate architecture”, which had seemed similar to the Conceptual Design idea.

Massood said “okay, I see the rationale for a conceptual design - thanks”.

In the next two hours, the DH Team developed the Context Diagram in Figure 2.10 and the Conceptual Diagram in Figure 2.11. After this, Disha Chandra led the team in generating a DH Development Strategy. Disha explained that in the next phase of the project, the Planning Phase, they would develop a detailed list of tasks, estimate the amount of effort required of each task, scheduled the tasks, and assign lead responsibility. She also pointed out that their development process (Table 2.2) includes multiple construction increments, which raises questions about what will be developed in each increment and how long each increment will take to complete.

Figure 2.10   DH context diagram.

Figure 2.11   DH conceptual design.

Disha stated that the team needs a strategy for development to do project planning. That is, a strategy that sets down how many increments will be developed, what will be constructed in each increment, and provides estimates of the size and effort required for each increment.

So, how do we start? Disha asserted that the central issue is what criteria will be used to determine the Development Strategy:

• ■   Should the first increment be a minimum subset of the DH functionality? This could provide the opportunity for the team to experience some early success, avoiding the risk of failure by taking on too much.

• ■   Should the first increment provide a base for DH construction that can easily be enhanced in future increments, making integration of components easier, perhaps a walking skeleton?

• ■   Should the team start with the most difficult functionality, solving the most difficult problems in the beginning, allowing time during subsequent increments to correct errors and to enhance the initial solution?

• ■   Or something else?

Exercise 2.3: DH Development Strategy

The team then proceeded to produce a strategy criterion and an allocation of conceptual design components to the various construction increments.

The exercise, described at the end of this chapter, deals with generating a DH Development Strategy.

Case Study Exercises

Exercise 2.1: Forming an Effective Team

Jose Ortiz and Disha Chandra felt that after the team building tutorial the team needed to start working on forming a cohesive and effective team. The earlier Team Problems activity (see Chapter 1) was a good start, but they both felt an additional Team Formation activity was needed.

Learning Objectives

Upon completion of this exercise, students will have increased ability to:

• Discuss some of key issues in building effective teams

• Develop techniques for building effective teams

• Appreciate the need for project team members to work together effectively

Exercise Description

1. As preparation for the exercise, read Chapter 1.

2. You will be assigned to a small group.

3. Each group designs a team building activity to help the team to coalesce and become a cohesive, effective team. The team building activity should follow the below guidelines:

   • Can be completed in 45 minutes by a team of 4 or 5 people. Possibly followed by 15-minute class discussion.

   • Ensures all team members participate.

   • Concerns something related to the team’s work on its project and produces something useful to the team.

4. Each team summarizes its discussion and conclusions in a written report. One member of their group is chosen to report to the class on the group’s discussion and the team building activity it designed.

Exercise 2.2: Evaluating a Software Process

Jose Ortiz has asked the project team to review the draft of the DigitalHome Development Process Script (Table 2.2). He requested that they provide him with an evaluation of its viability, with comments and recommendations.

Learning Objectives

Upon completion of this exercise, students will have increased ability to:

• Understand and analyze the purpose and implementation of software processes.

• Evaluate the fundamental elements of the content and structure of a software process for a given project.

Exercise Description

1. As preparation for the exercise, read Chapter 1.

2. You will be assigned to a small group.

3. Each team evaluates the DH Development Process Script. The following questions should be considered in the evaluation:

   • Is this an agile or a plan-driven process?

   • What are the strengths and weaknesses in the process?

   • Is the process appropriate for the domain area, development context, and delivery schedule?

   • Is the process clear and easy to understand? Does it have sufficient detail? Or is it too detailed?

   • Is the process complete? Are there any missing phases or activities?

   • Are there ways that the process could be improved with changes or additions or deletions?

   • Which phases should be assigned to individual DH Team members to lead?

4. Each team summarizes its discussion and conclusions in a team evaluation report. Choose one member of each group to report to the class on the team’s evaluation.

Exercise 2.3: Creating a DH Development Strategy

During the Launch Workshop Disha Chandra led the DH Team in creating a DH Development Strategy. This exercise concerns this activity.

Learning Objectives

Upon completion of this exercise, students will have increased ability to:

• Discuss the purpose and need for a Development Strategy.

• Develop a Development Strategy for a software project.

• Assess the adequacy of a Conceptual Design to support creating a Development Strategy

Exercise Description

1. As preparation for the exercise, study the DH Context Diagram and Conceptual Design, and the section of this Chapter on the Development Strategy.

2. You will be assigned to a small team.

3. Each group carries out the following activities:

   • Determine the Development Strategy Criteria.

   • Determine the number of development increments.

   • Allocate conceptual design modules to each increment.

   • Estimate module size and development effort for each increment.

4. Each team documents their Development Strategy for DH in the below template. One member of their group is chosen to report to the class on the group’s discussion and resulting strategy

DigitalHome Development Strategy
Team Names
Strategy Criteria
Increment #	Module/Element	Size (LOC)	Effort (days)
1	…
1	…
…
2	…
2	…
…