CS302: Software Engineering

4a. Choose data types

1. Why are we interested in data?
2. What are some of the properties of data that are relevant to a software development project?

Various types of data are gathered and analyzed in each phase of the development. Software engineers gather data pertaining to the problem or task at hand. From this data, they specify the information that is needed to solve the problem or perform the task. In addition, they identify the relevant relationships that apply to this information. The resulting description of the data is a Problem Domain Model.

In the Requirements Phase, additional information on what is needed is elicited from stakeholders and used together with the Problem Domain Model to describe a Requirements Model. In the Design Phase, additional information on how to process the data is gathered and used together with the Requirements Model and Problem Domain Model to describe a Design Model. In the Implementation Phase, additional information on the details of the data and how it is processed is gathered, and used together with the previous models to create the software that solves the problem or performs the needed task. Thus, a data trail guides us in transforming the initial problem domain model into a solution model. To review, read page 83 of The New Software Engineering.

Several properties of data are helpful in building the project data models, including the time period of the data, its structure, completeness, ambiguity, semantics, and volume. Can you explain each of these properties in the context of each development phase? These properties are important considerations in building each of the phase data models. To review, read pages 83-87 of The New Software Engineering.

4b. Interpret data/requirements gathering techniques

1. How do we gather data?
2. How do we verify and validate the data?

Data is gathered in each phase of the life-cycle. It is a primary activity in the Requirements Phase, and is called requirements gathering in that phase. Data can be gathered from project and company documents, software artifacts, stakeholders, and external sources. Name the techniques that are used to gather data. To review, reread subunit 4.3.

Depending on the source, data gathered may be ambiguous and subject to interpretation, biased, incomplete, and incorrect. How is the data verified and validated? See the paragraph on page 87 of The New Software Engineering on triangulation. Verification pertains to correctness; validation pertains to agreement or approval by significant stakeholders.

4c. Compare and contrast data gathering techniques most appropriate for each application type

1. What are the strengths and weaknesses of data gathering techniques?
2. Which techniques are more efficient or effective for a phase activity?
3. Why is professionalism and ethics important for data gathering?

Data is characterized by properties (or 'dimensions'), and there are many various data gathering techniques that could be used to collect that data. Any technique could be used, but we would like to use the techniques that are most effective and efficient for a given type of data for our application. To identify the 'best' techniques, we must understand the properties of the data, the strengths and weaknesses of each technique, and the type of data associated with our application. If we understand an application, we will know some of the properties of the data. As we gather data, we will learn more about the data. If we understand the strengths/weaknesses of the techniques, we can select the technique that will be 'best' for the data of our application. Review the following tables in The New Software Engineering: Table 4-7 on page 99 relates data collection technique to data properties. Table 4-8 on page 100 relates application type to data properties. These two tables can be combined to link data collection technique to application type, as shown in Table 4-9 on page 101.

Data gathering and data collection techniques can put a software engineer in situations that put the rights of confidentiality, privacy, and ownership of stakeholders and organizations at risk. Can you describe a situation in a data gathering techniques where a right of a stakeholder is at risk? Suppose you were a participant in a group interview and one of the other interviewees revealed what you said in the interview to project team members who were not in the interview. No matter what you had said in the interview, its revelation could inhibit open discussion in future interviews and therefore result in incomplete data being collected. Moreover, what you said in the interview could create a negative impression of you or others in the project. To review, read pages 103-107 of The New Software Engineering.

4d. Create request for proposal and evaluation of proposal regarding hardware and software

1. How do we decide whether or not to perform a project, phase, activity, or task, 'in house' or to outsource?
2. How do we decide to whom a project, phase, activity, or task is assigned?

At the project, phase, activity, or task level, a feasibility study may result in a recommendation to outsource a part of the project or even the entire project. Reasons for outsourcing include lower cost, lack of time or resources, lack of expertise or experience, a company strategic decision, or contract negotiations with a customer. To identify a vendor or subcontractor, a request for proposals (RFP) is sent out. Instead of gathering data, the project is now a provider of data to vendor or subcontractor companies. The data types and data collection techniques presented in this unit now apply to the vendor or subcontractor. The project now has a different, passive role. For example, the project does not conduct interviews; instead, the project may be interviewed.

Assignment of software activities and tasks is consistent with the principles of efficiency and effectiveness. Increasing specialization and availability of open source subsystems and application libraries means that software purchasing and subcontracting are being considered more frequently. Once proposals from vendors or subcontractors are received, the project is again in the role of gathering data, but from external sources. All of the considerations you have been studying apply: application types, data properties, data gathering techniques, professionalism, and ethics. The accuracy of data on qualifications, potential misuse of confidential or proprietary information, and potential conflicts of interests are of concern when dealing with vendors and subcontractors. To review, read pages 103-104 of The New Software Engineering.

Unit 4 Vocabulary

This vocabulary list includes terms that might help you with the review items above and some terms you should be familiar with to be successful in completing the final exam for the course.

Try to think of the reason why each term is included.

• Data model
• Time aspect of data
• Structure of data
• Data completeness
• Data ambiguity
• Data semantics
• Volume of data
• Interview types
• Questionnaire
• Artifact review
• Observation and/or participation
• Confidentiality
• Privacy
• Ownership
• Intellectual Property
• Vendor
• Subcontractor
• Outsourcing