Although home building has its ups and downs, the long-term prospects call for increases in total home square footage and intensified interest by home owners in high technology devices. New home owners, especially young professionals, are interested in living in houses that have “smart” features that automate and facilitate energy efficiency, entertainment delivery, communication, household chores, and home security. The design and construction of such dwellings relies on the latest technology (devices with smart capabilities, distributed computing, wireless and web communications, intelligent agents, etc.).

In August 202X, HomeOwner held its annual strategic planning retreat. During these one-week sessions HomeOwner officers and other upper-level managers concentrate on new initiatives that will advance the HomeOwner position as the industry leader in household product retailing.

On the first day of the 202X retreat, Dick Punch (VP of Marketing) and Judy Fielder (Chief Information Officer) made a presentation about the trend for “smart” technology and the market for building dwellings that integrate smart technology into every aspect of home living (environmental and energy control, security, communication, entertainment, household chores, etc.). Punch and Judy argued that the potential market for “smart” houses is tremendous, and although HomeOwner currently sells a number of smart home devices, it does not market the “complete package”. There are construction companies that during the planning and building phases incorporate computer and communication systems needed to combine and control the smart devices in such a way that best serves the needs and desires of today’s new tech-savvy upwardly mobile professional. Punch and Judy recommended that HomeOwner become a competitor in this field, and look for opportunities to push the industry to building “smarter” houses.

Red Sharpson, CEO of HomeOwner, loved the smart house idea and decided to devote the rest of the week to formulating plans for this new initiative. After days of discussion and debate the following decisions were made:

■ Establish a new DigitalHomeOwner Division of HomeOwner to be headed by Jose Ortiz (currently Deputy CIO).
■ Develop a two-year strategic plan for the division.
■ Assemble a staff for the division.
■ Develop a one-year division budget plan.

In the next year, DigitalHomeOwner will carry out the following activities:

■ With the assistance of the Marketing Division, DigitalHomeOwner will research the existing smart houses, and conduct a needs assessment for a DigitalHome product, which will provide the computer and communication infrastructure for managing and controlling the “smart” devices in a home to best meet the needs and desires of homeowners. In other words, building houses that take the advantage of Internet of Things (IoT) technology.

■ Choose a set of features for the DigitalHome product to develop a high-quality “proof of concept” prototype to illustrate how the DigitalHome needs will be met. Because of time constraints, the features chosen will be a subset of the actual needs. It is envisioned that this will primarily be a “software effort”, with simulation being used to represent dwelling structures, hardware devices, and communication links.

■ Jose Ortiz will form a team and supervise it in the development of the DigitalHome prototype.

■ Jose Ortiz will deliver a report on the DigitalHome efforts at the August 202Y strategic planning retreat.

■   In addition, DigitalHome will include the following special considerations:

–   It is anticipated that the DigitalHome prototype will be the foundation for future development of DigitalHomeOwner products. Hence, it is essential that the development team use established software engineering practices and fully document their work.

–   In development of the prototype, DigitalHomeOwner should have two primary client groups: (1) potential DigitalHome users and (2) the upper management of HomeOwner. These clients should be part of an acceptance testing process for the prototype.

–   At the retreat, Judy Fielder, the CIO, also presented a proposal (HomeOwner Cloud Computing Initiative Proposal) for development of a HomeOwner cloud server. Although the decision on the cloud initiative was tabled for further study, it was recommended that the DigitalHome developers consult the guidance provided in the proposal, especially as related to the privacy and security of client communication and data.

Judy Fielder pointed out that to make this project a success it was important that the project team use the best software engineering practices. Red Sharpson stated that he had little understanding about software engineering and did not know what the “best” software engineering practices were. Judy suggested that they ask Jose Ortiz to deliver a talk on software engineering on the last day of the retreat. Red agreed.

MiniTutorial 1.1: What Is Software Engineering?

The IEEE Standard Systems and Software Engineering Vocabulary [IEEE 24765] defines software engineering as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software”. One of the earliest recorded uses of the term “Software Engineering” was in the 1968 NATO Software Engineering Conference; in the Conference report [Naur 1969], it was stated that the term was used to imply “the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering”. Hence, software engineering is a relatively young engineering discipline.

Software Engineering Problems

Software plays a critical and central role in almost all aspects of human endeavor. The size, complexity, and number of application domains of software products and services continue to grow. Unfortunately, there are serious problems in the cost, timeliness, and quality of development of many software systems. A significant number of development projects are never completed, and many of those completed do not meet the user requirements and are late, over budget, and of poor quality [Standish 2020]. A 2002 study from the National Institute of Standards and Technology [Tassey 2002] reports that software defects are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually, or about 0.6% of the gross domestic product. Parnas and Lawford [Parnas 2003] state “Despite more than 30 years’ effort to improve software quality, companies still release programs containing numerous errors. Many major products have thousands of bugs”.

Although, software development has improved considerably in the last 40 years, the development and maintenance of software systems are still plagued by serious budget, schedule and quality problems. One of the reasons for this is the lack of software engineers with adequate qualifications and background. There is a very high demand for software engineers; the Occupational Outlook Handbook 2016–17 edition (Bureau of Labor Statistics) [BLS 2016] highlights the increased need, in the coming decade, for software engineers. The handbook states, “Employment of software developers is projected to grow 17% from 2014 to 2024, much faster than the average for all occupations. The main reason for the rapid growth is a large increase in the demand for computer software”.

The Nature of Software

Another reason for the problems in software engineering is that by its nature, software is different from other engineered products. In the paper “No silver Bullet” [Brooks 1995], Brooks argues that software has the following “essential difficulties” that do not plague other engineering products (or at least not to the same extent):

■ Complexity – Brooks argues that software entities are more complex, for their size, than perhaps any other human construct. Even moderately complex software systems may have millions of distinct parts (components/packages, classes/objects, variables, methods, and statements), which may be stored in an extremely small physical space.

■ Conformity – Other engineering fields (such as mechanical engineering) deal with complexity by building models that conform to the known laws of physical world (e.g., Newton’s laws of motion). Software engineers also build models, but software does not have the unifying principles based on the physical world that it must conform to; hence, software models must deal with an arbitrary conformity imposed by the expected software capability – often rather open-ended, depending on user/customer needs.

■ Changeability – Software is easy to change, at least relative to changing a physical object. For example, adding a turn arrow to the traffic signals in a city’s traffic system is a major undertaking, while making such a change to a simulated traffic system might be the weekend activity of a single programmer. But the ease of software change has its negative side. Changing software in haste can lead to injecting defects into a system or can have unintended side effects in some other part of the system (a common occurrence). Also, the changeability nature of software can lead users/customers to expect quick and cheap addition of features to a software product.

■ Invisibility – Software is invisible. It lacks physical structure and substance. Although software engineers use graphic models to help them to understand software’s nature (e.g., a use case diagram – see Chapter 5), such graphic models are abstractions and only represent some aspect of the software’s use or organization, not its “physical appearance”.

Advancing Software Engineering

In the past decade, there has been significant progress in the advancement of software engineering as a profession. In recent years, task forces and working groups from the Association of Computing Machinery (ACM), the Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS), the Accreditation Board for Engineering and Technology (ABET), and the Software Engineering Institute (SEI), at Carnegie Mellon University, have been at work to advance the state of software engineering, and have developed the following components, which help define and characterize the nature and content of software engineering and to improve its practice:

The Software Engineering Body of Knowledge (SWEBOK)

The SWEBOK [Bourque 2014] has had a major influence on understanding the nature of software engineering and on the development of education and professional development programs. It is also a major influence on the content and character of this book. The SWEBOK provides the description of the Software Engineering Practice Knowledge Areas (KAs) listed in Table 1.1. Topics from each of the “Practice” KAs will be covered in this text, which is referred to in the Location column of Table 1.1. The SWEBOK also includes KAs labeled as Software Engineering Foundations: Engineering Economy Foundations, Computing Foundations, Mathematical Foundations, and Engineering Foundations.

Table 1.1 SWEBOK Knowledge Areas for Software Engineering Practice
Knowledge Area	Description	Location
Software Requirements	Concerned with determining, documenting, and managing the requirements for a software product or service.	Chapters 5,10
Software Design	Focused on deciding how the software requirements will be fulfilled: determining the design components and their description, and how they will interact with each other.	Chapter 6
Software Construction	Concentrated on the design, coding, and testing the units that make up the software design components.	Chapter 7
Software Testing	Ensuring through tests on an executing software system or its units/components that the software operates properly.	Chapter 3
Software Maintenance	Covers the evolution of software as it changes over its operational life.	Chapter 8
Software Configuration Management	Encompasses the management of the software artifacts (such as plans requirements, design, and code) of software as it is developed: version control, change control, and document archiving.	Chapter 4
Software Engineering Management	Involves planning, coordinating, measuring, reporting, and controlling a software project.	Chapter 4
Software Engineering Process	Includes the definition, implementation, evaluation, and improvement of the processes used to develop software.	Chapters 2, 10
Software Engineering Models & Methods	Describes models and methods used to develop and maintain software.	Chapters 2, 8, 10
Software Quality	Covers the processes and practices used to assure software quality.	Chapters 3, 10
Software Engineering Professional Practice	Concerned with the capabilities and attitudes that software engineers must possess for professional, responsible, and ethical practice of their profession.	Chapter 9

Table 1.2 describes some of the different roles and responsibilities that a software engineer might take on. This arrangement of software engineering roles will be used in composing the DigitalHome project team with each member also assuming the role of a component developer. The roles in an agile team are discussed in Chapter 10.

Table 1.2 *DigitalHome* Development Team’s Role Description
Role	Description
Team Leader	The team leader is responsible for guiding and motivating team members throughout the development phases. This includes running the day-to-day operations, resolving conflicts, managing and tracking issues, conducting meetings, and managing team resources. He/she serves as the team’s interface with the customer and management. The team leader is also responsible for monitoring team members’ work and ensuring process discipline. An effective team leader strives for open and effective team communication. He/she makes sure that project’s status is communicated to the rest of the team members as well as to management and the customer.
Software Analyst	The software analyst is responsible for identifying the purpose of the software system and the individual goals of the customer. He/she leads the development of the requirements specification that includes a model of the system’s environment and a description of the purposes, goals, performance constraints, resource constraints, implementation constraints and external interfaces of the system. The analyst must know the technology and be able to understand and respond to what is found in observing and talking with those who are commissioning a new system or will be the end users of it. The software analyst must have considerable written communication as well as generalization skills.
Software Architect	The software architect is concerned with the structure of the software system. In particular, an architect leads the team in defining the software components and the interactions among these components with respect to the specification. He/she leads the team in the development of the high-level architecture as well as the high-level and detailed-level component designs. The architect is responsible for recording decisions that determine the implementation strategy. He/she must have underlying technical knowledge of component development (modular design, programming, and testing) in order to tie his/her decisions to reality.
Quality Manager	The quality manager leads the team in producing and tracking the team quality plans, as well as alerting the team leader to arising quality issues. The team quality manager assures that updates to quality plans are done periodically and accurately. He/she is also responsible for making sure that Verification and Validation activities (reviews, inspections, tests) are performed properly and that the results of these activities are recorded correctly and appropriate changes and follow-ups are completed. This person is also responsible for making quality improvement recommendations at the end of each development cycle to assure continuous quality improvement of process and product.
Planning Manager	The planning manager leads the team in producing a detailed, balanced, and accurate team development plan as well as individual plans. He/she is responsible for tracking progress against developed plans, and alerts the team leader in case of deviation from these plans. This manager ensures that team members measure and record their work (effort and size). The planning manager leads the team in producing the team schedule for each development cycle, as well as producing a cycle report at the end of each cycle.
Component Developer	The module developer is responsible for developing and integrating the modules that make up an architectural component. He/she develops the detailed design for the modules, translates the design into program code, tests the modules, and integrates them into a component.

Forming a Project Team

At the 202X Homeowner Retreat, Jose Ortiz was appointed the head of the new DigitalHomeOwner Division of HomeOwner. One of his first tasks was to form a project team. The following sections describe how the team was formed and discusses the team members’ background and experience.

Jose Ortiz was born in San Diego, CA, in 1970. He received a B.S. in electrical engineering at San Diego State University and subsequently earned an MBA at California State at Transylvania. After working at several aerospace firms in the 1990s, Jose was employed as a technical manager at a small IT start-up firm, Network Solutions, in 1999. After the firm’s IPO (Initial Public Offering) in 2000 it had tremendous growth and success. In 2010, Jose was hired by HomeOwner as its Deputy CIO.

In early September 202X, Jose began to assemble a software team to develop the DigitalHome prototype. Although Jose had outstanding management skills and excellent technical knowledge about network administration, IS evolution, and IT architectures, he had little detailed knowledge about software development and recent advancements in software engineering methods and practices.

To help him in the team formation task, Jose contacted his old friend Michel Jackson, who retired after a 30-year career in software development. As a new Stanford graduate in Computer Science in 1982, Michel started his career as embedded systems programmer for a major aerospace company. Since then Michel worked in almost every facet of the software business: as a programmer, a software architect, a software/system analyst, a quality assurance director, a project manager, and an entrepreneur. He has worked on large, custom built real-time, embedded systems, shrink-wrapped software, and major web-centric applications. Most recently, Michel headed a small company that specialized in software analysis and modeling, exploiting the use of the Jackson Analysis Framework. After selling his firm last year he has been in quasi-retirement, with part-time consulting work occupying his non-leisure time.

Michel eagerly agreed to help Jose in recruiting a DigitalHome development team. Jose and Michel conferred about the team organization for the project and agreed that the team should be organized in a quasi-democratic manner, with each member assigned prescribed responsibilities and all major decisions to be made after team discussion, with the Team Leader making the final call. Table 1.2 contains the description of the DH Team roles. All team members may be assigned responsibility for a software unit (component/unit design, coding, and testing).

Michel first contacted Disha Chandra, who he had met when he did some consulting work for SoftMedic. Disha had come to HomeOwner three years ago, after a decade of work at SoftMedic. At SoftMedic she worked in a variety of roles on the development and maintenance of a number of widely used software applications in the field of health delivery and management. Most recently, at Homeowner, Disha lead the development of an in-house application used by HomeOwner store managers to train new employees.

Disha is 38 years old and came to the U.S. from India in 2000 to work on a degree in Computer Science at Valley State University. After completing her degree, she went to work for SoftMedic, became a U.S. citizen, and earned an online Master of Software Engineering degree from Lancaster Institute of Technology. She is considered a strong leader and an effective manager with excellent knowledge and experience in almost all areas of software engineering.

Jose interviewed Disha and was very impressed with her experience, and the confident and organized way she approached her work. He offered her the job of Team Leader. She accepted with one stipulation, she wanted Michel to serve as the project’s Software Analyst. Jose and Disha conferred with Michel about the Software Analyst role and Michel was enthusiastic about working on the project and accepted the offer.

From this point, Disha and Michel worked together to form the rest of the team. In the next ten days they contacted and interviewed eight persons for the DigitalHome project. After some consideration and agreement from Jose Ortiz, the following team members were selected.

■ Yao Wang, Software Architect, DH System

Yao Wang is considered a whiz kid of object-oriented design. At 26 years of age he shows great promise to be an innovative leader in software design of embedded consumer products. He was hired by Jose Ortiz right after graduation from Rational University and is viewed as future principal player in the DigitalHomeOwner Division.
■ Georgia Magee, Quality Manager, DH System

Georgia Magee has worked for the last three years as a programmer and a test engineer at HomeOwner. Prior to that, she had a four-year stint with the Volcanic Power Company, as a junior software engineer developing electric power management software. Georgia is married, 30 years old, and recently became a mother with the birth of her first child, George.
■ Massood Zewail, Planning Manager, DH System

Massood recently graduated from the University of Central California (UCC) with a joint degree: an undergraduate degree in computer engineering and master’s degree in software engineering. Although Massood was an outstanding student (3.87 GPA) and had two summers of student intern work with MacroSoft Corporation working on two different projects which followed two different development processes (spiral and agile), this is his first full-time professional employment.

As part of the team formation, Disha, in consultation with the other members, decided that each team member would have additional responsibility as a Component Developer, developing one or more software components.

Assessing DigitalHome’s Needs

One of the key decisions at the August 202X HomeOwner retreat was for DigitalHomeOwner, with the assistance of the Marketing Division, to conduct a needs assessment for a DigitalHome product that would best meet the needs and desires of homeowners. In early September, Jose Ortiz met with Dick Punch, VP of Marketing, and they decided on a set of parameters to use in developing a Need Statement for the DigitalHome product. Dick agreed to have the Marketing Division draft two documents in the coming weeks: a DH Customer Need Statement and a DH High-Level Requirements Definition (HLRD).

DH Customer Need Statement

The Marketing Division of HomeOwner produced a draft Need Statement for DH and submitted it to Jose Ortiz for review and feedback. The Need Statement was based on research that involved structured interviews and focus groups of potential DH customers and users. The results were analyzed and assembled into statements about the needs of a fictional Wright family, who represent a set of typical potential DH users. The DH Customer Need Statement is in Appendix A.

DH High-Level Requirements Definition

After some discussion about the DH Need Statement, the Marketing Division prepared a DH High-Level Requirement Definition (HLRD). The HLRD is not meant to cover all the expectations in the Need Statement, but rather represents a subset of needs that can form the basis for a prototype development. As such, it follows the directive issued in the HomeOwner August retreat: “Choose a set of features for the DigitalHome product to develop as a prototype to illustrate how the DigitalHome needs will be met. Because of time constraints, the features chosen will be a subset of the actual needs”. The HLRD is included in the below section.

High-Level Requirements Definition

Introduction

This is a “high-level” definition of the requirements (HLRD) for the development of a “Smart House”, called DigitalHome, by the DigitalHomeOwner Division of HomeOwner Inc. A “Smart House” is a home management system that allows home owners (or renters) to easily manage their daily lives by providing for a lifestyle that brings together security, environmental and energy management (temperature, humidity and lighting), entertainment, and communications. The Smart House components consist of household devices (e.g., a power and lighting system, an air conditioning unit, a sound system, a water sprinkler system, small appliances, security system, etc.), sensors and controllers for the devices, communication links between the components, and a computer system, which will manage the components.

The HLRD is based on the DigitalHome Customer Need Statement. It is made up of a list of the principal features of the system. This initial version of DigitalHome will be a limited prototype version, which will be used by HomeOwner management to make business decisions about the future commercial development of DigitalHomeOwner products and services. Hence, it does not include all features discussed in the Need Statement, and the HLRD is not intended as a comprehensive or complete specification of DigitalHome requirements. The main purpose of the HLRD is to support an effective project planning activity. The HLRD was prepared by the Marketing Division of HomeOwner Inc, as part of a needs assessment for the DigitalHome project.

DigitalHome Prototype Features

The DigitalHome System shall allow any web-ready computer, cell phone, or other device to control a home’s temperature, humidity, lights, and the state of household appliances (coffee maker, stove, etc.). The communication center of the system shall be a personal home owner web page, through which a user can monitor and control home devices and systems.

Each DigitalHome shall contain a master control device that connects to the home’s broadband Internet connection, and uses wireless communication to send and receive communication between the DigitalHome system and the home devices and systems.

The DigitalHome shall be equipped with various environmental sensors (temperature sensors, light sensors, humidity sensors, power sensors, contact sensors, water sensors, etc.). Using wireless communication, sensor values can be read and saved in the home database.

The DigitalHome security system
consists of a set of contact sensors and a set of security alarms, which are activated when there is a security breach.
1. The security system shall use wireless signals to communicate through the master control unit.
2. The system shall use both sound and light alarms and will be able to manage up to 30 door and window sensors.

The DigitalHome programmable Thermostat shall allow a user to easily monitor and control a home’s temperature from anywhere using any web-ready computer, cell phone, or other device.
1. Thermostats can be placed throughout the home and can be controlled individually or collectively, so that temperature can be controlled at different levels in different home spaces.
2. A thermostat unit shall communicate, through wireless signals, with the master control unit.
3. The system shall support Fahrenheit and Celsius temperature values.
4. The system shall be compatible with most centralized HVAC (Heating, Ventilation and Air Conditioning) systems: gas, oil, electricity, solar, or a combination of two or more.
5. The user shall always be able to override the scheduled settings at any time.

The DigitalHome programmable Humidistat shall allow a user to easily monitor and control a home’s humidity from anywhere using almost any web-ready computer, cell phone, or other device.
1. Humidistats can be placed throughout the home and can be controlled individually or collectively, so that humidity can be controlled at different levels in different home spaces.
2. A Humidistat unit shall communicate, with wireless signals, through the master control unit.
3. A Humidistat unit shall manage humidity sensors and dehumidifiers/humidifiers located in a specified home space.
4. The user shall be able to select the humidity levels found most comfortable — from 30% to 60%.

The DigitalHome programmable Power Switch shall provide for management of a home’s household appliances and shall allow the user to turn appliances and lights on or off as desired.

The Power Switch unit can control the central lighting in each room and up to forty 115-V, 10 amp appliances that plug into a standard wall outlet.
The system shall be able to provide information about whether an appliance or a light is off/on.
A user shall be able to monitor the state of the appliance, and turn on or off any appliance through any web-ready computer, cell phone, or other device.
The sensors should be able to monitor the state of the appliance and manipulate the power setting in order to reach the highest energy efficiency. For example, monitor the water temperature and adjust water heater power supply accordingly to increase its energy efficiency.

The DigitalHome Planner shall be able to provide a user with the capability to direct the system to set various home parameters (temperature, humidity, security level, and on/off appliance/light status) for specified time periods.
1. DigitalHome provides a monthly planner on its website.
2. Parameter values can be scheduled on a daily or hourly basis.
3. All planned parameter values can be overridden by a user.
4. Various plan profiles (normal monthly profile, vacation profile, summer profile, holiday profile, etc.) may be stored and retrieved to assist in planning.
5. The DigitalHome Planner shall be able to provide various reports on it management and control of the home (e.g., historical data on temperature, humidity, lighting, etc.).

Dick Punch told Jose Ortiz that he understood that it was typical at the beginning part of a project to determine a “concept of operations”. Jose agreed, and Dick asked if Jose could prepare a presentation of the concept.

Minitutorial 1.2: Concept of Operations

This HLRD (along with the DH Customer Need Statement and the DH Conceptual Design in the next chapter) could be considered a Concept of Operations (ConOps) document. Appendix B in the IEEE standard life cycle processes — Requirements engineering [IEEE 29148] describes a ConOps as “the organization’s assumptions or intent in regard to an overall operation or series of operations of the business with using the system to be developed, existing systems, and possible future systems”. The ConOps document can be used to communicate overall system characteristics (both quantitative and qualitative) to the user, customer, developer, and other organizational entities (e.g., training or maintenance staff). We note that for the DH System we are speaking of a “software-intensive” system.

The ConOps Document for complex, multifaceted systems would provide the following:

■ A description of the elements of the user organization.
■ A description of the user’s operational needs without including detailed technical issues, which would be addressed in subsequent development activities (e.g., requirements analysis).
■ Documentation of system characteristics that can be verified by the user without requiring any special technical knowledge beyond normal user understanding.
■ A place for users to state their desires, visions, and expectations.
■ A mechanism for users and customers to express thoughts and concerns on possible solution strategies.

The IEEE standard [IEEE 29148] provides a detailed outline for a ConOps document, addressing each of the above bulleted features. The DH Team did not feel that a full ConOps document, with all of the above features, was needed or appropriate for the DH System: the DH System has a prototype focus, and the primary user group for DH is an amorphous, unstructured group.

Exercise 1.2: Assessing Customer Needs

Disha Chandra set up a meeting between the DH Team with Karen Mullen, the lead for the DH needs assessment effort, to address questions and concerns about the DH Customer Need Statement and the DH HLRD.

The exercise, described at the end of this chapter, deals with preparation for the meeting.

Case Study Exercises

Exercise 1.1: Team Problems

During the DigitalHome project launch, Jose Ortiz wanted to build a strong team that would work well together. Since none of the team members had worked together in the past, he designed a team activity where team members would discuss teamwork problems that they had experienced in previous projects.

This exercise presents some of the past problems experienced by the DH team members and asks questions about resolving the problems.

Learning Objectives

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

Describe some of the personnel problems that may be experienced by software project teams.
Develop solutions to team personnel problems.
Appreciate the need for project team members to work together effectively.

Exercise Description

As preparation for this exercise, read the Chapter 1 material on the DH Team Formation.
You will be assigned to a small team. Each team is assigned one of the team problem descriptions listed below, which describes a team personnel problem.
The team meets and discusses the problem, and answers the questions about the problem. Then, the team decides on various approaches that might be taken to solve the problem.
Each team summarizes its discussion and conclusions in a team report. Choose one member of their team to report to the class on the team’s discussion and conclusions.

Georgia Magee’s Problem: Don’t Worry Your Pretty Little Head

While working at Volcanic Power Company, Georgia served in a project team to develop a power regulation product. One of Georgia’s teammates was a young software engineer named Kevin: Kevin had been writing programs since he was in middle school, had graduated with honors in computer science from Carnegie Mellon University, and was considered a real whiz at constructing software. The Team Leader, Roy, is an easygoing fellow who just wants to get through the project without making too many tough decisions. During project launch, Kevin argued strongly that he was best qualified to be the development manager (responsible for managing system analysis and design). Without consulting with anyone else, Roy designated Kevin as the project Development Manager. So far, in the first development cycle, Kevin has completed the whole design by himself (without consulting with anyone) and written nearly all of the source code. The team is ready to go into system test and Kevin has told everyone not to worry, he is great at testing software and he will handle it. Georgia was assigned the role of Process/Quality Manager. She complained to Roy that because Kevin is doing everything, the team is not really following the Company’s established development process. Roy tries to convince Georgia that things are going great, Kevin is doing a great job, and not to worry her pretty little head about such things as “design” and “coding” and just concentrate on the process stuff.

Suppose you are the VP of Information Technology at Volcanic Power and Georgia brings her complaints to you. What would you do?

Massood’s Problem: Slacker on the Loose

While attending the UCC Massood was enrolled in a senior design project course, which involved development of an autonomous chemical sensing robot. The design team was made up of computer science and computer engineering majors. One of the team members, Burt, has spent more time in his life trying to get out of work than actually working. He seems to really enjoy concocting schemes for avoiding labor of any sort. He is bright enough, and this has allowed him to stumble through three years of a CS program at UCC with a C minus average. Unfortunately, he is now enrolled in the senior design course and has been assigned as a programmer on the project team. Each week, Burt is supposed to submit a report on his work (tasks completed, time spent on the project, and a description of any problems incurred) to Massood, who is the project Planning Manager. Massood became really fed up with Burt. Burt’s reports were always late and incomplete, and they look like they were made up minutes before submission. Massood discussed this with the other team members, and they all agree that Burt was a slacker and had contributed next to nothing to the project. They urged the Team Leader, Juan, to discuss this with the teacher. They would like to get Burt off their team before he does too much damage.

Juan met with you, the teacher, explained the situation, and asked that Burt be removed from their team. If you were the teacher what would you do?

Disha’s Problem: It’s Time to Make Some Changes

On her first project at SoftMedic, Disha was a member of a team for which Sally was the Team Leader. Sally was intelligent, hard-working, and very ambitious; but she had never led a project of this magnitude. After the first cycle, the SoftMedic Quality Assurance Director gave the team an overall assessment of the team’s work. Most would consider Sally’s team “average”. They worked fairly hard, but were a technology-oriented group and did not aspire to move up the corporate ladder, like Sally. Sally wanted the team to be viewed as outstanding and made this clear to her teammates. In the second cycle, Sally has taken a firmer hand and has now given direct orders to each of the team members about how and when they should do their work. If work is not completed the way she expects, she will berate a team member in the weekly team meeting. After the cycle 2 design inspection, Sally stated

It’s clear to me that you guys just don’t care about this project, and I think it is time to make some changes! From now on, we will meet every evening at 6, and I expect each of you to make a daily report on what you have been doing.

The team, mostly a mild-mannered group, does not dispute Sally’s proclamation and walks off mumbling to themselves.

As the VP of Development, one of the team members comes to you to complain about the situation. What should you tell the team member? What should you do with Sally, if anything? How should you handle the situation?

Yao’s Problem: Double Trouble

Yao’s last project at HomeOwner involved development of an inventory application that could be embedded in checkout scanners and handheld devices. Yao was designated as the Design Manager and he looked forward to the project. However, two of the team members caused problems: Greg and Whitney just do not like each other; they had been involved in several run-ins in the past. They were both excellent engineers, but just could not get along. Greg was the Requirements Analyst and Whitney the Planning Manager. The team had just completed the requirements phase and was starting the design phase. During the requirements inspection meeting, Greg and Whitney had a big disagreement about the way one of the requirements was written, and almost came to blows. In the first meeting about the design, Yao presented a preliminary design architecture. Greg and Whitney proceeded to spend almost the entire meeting bickering over every detail of the architecture. Finally, Harry, the Team Leader, said “Enough! We can’t do anything productive until you two stop acting like children”. After the meeting Harry met with both of them, separately, and tried to resolve the problem, but he could not make any headway.

Harry comes to you, the Division Head, for help. What do you do?

Exercise 1.2: Assessing Customer Needs

The HomeOwner Marketing Division produced the two documents: the DH Customer Need Statement and the DH HLRD. After reviewing the documents with her team, Disha Chandra asked Jose Ortiz if he could set up a meeting between the Marketing Division and the DH Team to discuss the questions the team had about the Need Statement and the HLRD. Jose contacted the Marketing VP and set up a meeting between the DH Team and Karen Mullen, the lead for the DH needs assessment effort. This exercise deals with how the team will prepare for the meeting with Karen.

Learning Objectives

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

Analyze a customer need statement and the initial set of requirements for a system.
Acquire additional information from a customer about his/her needs.
Work effectively as part of a team.
Prepare and organize for a meeting.

Exercise Description

As preparation for this exercise, read Chapter 1.
You will be assigned to a small development team (like the DH Team).
Your team is to take on the role of the DH Team and prepare for a meeting with Karen Mullen. The team should carry out the following tasks:
1. Analyze the DH HLRD and discuss any problems or concerns about their understanding of the HLRD.
2. Formulate objectives for the meeting with Karen.
3. Make up a set of questions the team would like answers to prior to commencement of project planning and software requirements analysis. d.
4. Assign individual roles for the meeting (e.g., meeting facilitator, taking notes, asking questions, etc.).
5. Make up an agenda for the meeting.
6. Complete the following meeting preparation form.

Meeting Preparation Form
Meeting Date & Time
Meeting Purpose
Meeting Participants and their Roles
Meeting Agenda
Questions 1
2
3
4
5
6
7
8
9
10