Comp 490 Final Exam Review

Project Management (Chapter 22, pp. 593-595 & 602-617)

How are software engineering projects different from other types of engineering projects?

Project management activities

Project planning

Reporting

Risk management

People management

Proposal writing

Managing People

Critical factors in people management

Consistency

Respect

Inclusion

Honesty

Motivating People (Human needs)

Physiological needs

Safety needs

Social needs

Esteem needs

Self-realization needs

Personality types

Task-oriented

Self-oriented

Interactive-oriented

Benefits of a cohesive team

The group can establish its own quality standards

Individuals learn from and support each other

Knowledge is shared

Refactoring and continual improvement is encouraged

Aside from cohesiveness, team effectiveness depends on:

The people on the team

The team organization

Technical and managerial communications

What factors determine how a team should be organized?

Factors influencing team communications

Group size

Group structure

Group composition

The physical work environment

The available communication channels

Project Planning (Chapter 23, pp. 618-626 & 631-650)

Software pricing depends on:

Market opportunity

Cost estimate accuracy

Contractual terms

Requirements volatility

Financial health

What are the differences between “plan-driven” and “agile” development?

Parts of a project plan

Introduction

Project organization

Risk analysis

Hardware and software resource requirements

Work breakdown

Project schedules

Monitoring and reporting mechanisms

Project plan supplements

Quality plan

Validation plan

Configuration management plan

Maintenance plan

Staff development plan

The two-stage approach to agile planning

Release planning

Iterative planning

Estimation techniques

Experienced-based techniques

Estimate project effort based on past experiences

Algorithmic cost modeling

Effort = A x Size^B x M

The COCOMO II Model

Project Duration and Staffing

The nonlinear relationship between number of staff and development time

Requirements Engineering (Chapter 4, pp. 82-117)

What is the difference between user and system requirements?

What is the difference between functional and non-functional requirements?

Categories of non-functional requirements

Product requirements

Organizational requirements

External requirements

User requirements

System requirements

What metrics would you use to specify the following non-functional requirements?

Performance (speed and size)

Usability (ease of use)

Reliability

Robustness (availability)

Portability

The software requirements document

Who are the users of this document?

What are the main sections of this document?

In what form can requirements be expressed?

Natural language sentences

Structured natural language

Design description languages

Graphical notations

Mathematical specifications

The requirements engineering process

Requirements elicitation and analysis

Requirements discovery

Interviewing

Creating scenarios or use cases

Ethnography

Requirements classification and organization

Requirements prioritization and negotiation

Requirements specification

Why is eliciting requirements a difficult process?

Requirements validation

Check requirements to ensure that they are:

Really what the stakeholders want

Consistent

Complete

Realistic

Verifiable

Techniques for validation

Reviews

Prototyping

Test-case generation

Requirements management

Why do requirements change?

Requirements management planning requires

Requirements identification

A change management process

Traceability policies

Tool support

Risk Management (Chapter 22, pp. 595-602)

Categories of Risks

Project risks

Product risks

Business risks

Types of Risks

Technology risks

People risks

Organizational risks

Tools risks

Requirements risks

Estimation risks

Risk Management Tasks

Risk identification

Risk analysis

Likelihood (probability of occurring)

Impact (effect of occurrence)

Prioritization

Risk planning

Avoidance/minimization (Mitigation) planning

Contingency planning

Planning a monitoring approach

Risk monitoring

Project Scheduling (Chapter 23, pp. 626-631)

The Scheduling Process

Identify activities

Identify activity dependencies

Critical path

Estimate resources for activities

Allocate people to activities

Create project charts

Bar charts (Gantt charts)

Activity networks (PERT charts)

Women and Minorities in Computing

What are the effects to society that women and minorities are underrepresented?

Intellectual Property Rights

Patents

Copyrights

Trade marks

Trade secrets

Are these needed for software?

System Modeling (Chapter 5, pp. 118-138)

Be able to describe the various kinds of system models.

Be able to explain when a given model is useful.

Context Models

Interaction models

Use case modeling

Sequence diagrams

Structural models

Class diagrams

Generalization models

Aggregation models

Behavioral models

Data-driven modeling (data flow diagrams)

` Event-driven modeling (state diagrams)

Architectural Design (Chapter 6, pp. 147-164)

Be able to explain what is meant by architectural design.

Be able to identify examples of architectural design decisions.

Be able to discuss the relationship between architectural design & non functional requirements.

Be able to describe the different architectural views.

Logical

Process

Development

Physical

Be able to describe different architectural patterns.

Model-view-controller

Layered

Repository

Client-server

Pipe and filter

Design and Implementation (Chapter 7, pp. 176-202)

Be able to use UML to design software.

Understand the difference between structural and dynamic models.

Structural models

System context model

Use-case models

High-level architectural models

Subsystem models

Object class diagrams

Dynamic models

Sequence diagrams

State diagrams

Be able to describe what is meant by a design pattern and how one is specified.

Pattern name

Description

Problem description

Solution description

Consequences

Be able to describe the different levels of reuse.

Reuse at the abstraction level

Reuse at the object level

Reuse at the component level

Reuse at the system level

Be able to describe the activities associated with configuration management.

Version management

System integration

Problem tracking

Be able to explain the host-target model in software development.

Be able to explain what is meant by open-source development.

Verification and Validation (Chapter 8, pp. 205-231)

Be able to explain the goals of testing.

Meets requirements

Discover bugs

Be able to distinguish between verification and validation.

Be able to identify advantages of inspections/reviews over testing.

Be able to describe the different types of testing.

Development testing

Unit testing

Partition testing

Guideline-based testing

Component (interface) testing

Parameter interfaces

Shared memory interfaces

Procedural interfaces

Message passing interfaces

Interface errors

Misuse

Misunderstanding

Timing

System testing

Release testing

Requirements based testing

Scenario testing

Performance testing

User testing

Alpha testing

Beta testing

Acceptance testing

Be able to describe the concept of test-driven development.

Quality Management (Chapter 24, pp. 651-675)

Be able to describe the contents of a quality plan.

Product introduction

Product plans

Process descriptions

Quality goals

Risks and risk management

Be able to explain why software quality is not comparable to quality in manufacturing.

Be able to identify and describe software quality attributes.

Safety Understandability Portability

Security Testability Usability

Reliability Adaptability Reusability

Resilience Modularity Efficiency

Robustness Complexity Learnability

Be able to explain why software standards are important.

Be able to explain the difference between process and product standards.

Be able to describe the ISO 9000/9001 standards (at a high level).

Be able to describe the software review process.

Pre-review activities

The review meeting

Post-review activities

Be able to describe the unique features of inspections as review mechanisms.

Be able to explain how software measurement can be used to aid in software development.

Be able to explain what is meant by a software metric.

Control metrics (process metrics)

Predictor metrics (product metrics)

Static metrics

Dynamic metrics

Be able to identify internal attributes to measure to assess external quality attributes.

Privacy and Security

Be able to explain what the ACM Code of Ethics says about privacy.

Be able to discuss the privacy and security challenges in developing software.

Sample short answer questions:

1. What does a sequence diagram show?

2. In object-oriented design, what is the difference between inheritance and aggregation?

3. Briefly describe the repository architectural pattern?

4. Give an example of how a non functional requirement can impact software architectural design.

5. Briefly explain the difference between structural and dynamic software design models.

6. In the context of configuration management, what is meant by version control?

7. Identify and describe one of the goals of testing.

8. Explain what is meant by partition testing?

9. Identify and describe one element of a software quality plan.

10. Identify and describe one feature of a software inspection that is not necessarily present in other forms of review.

Sample essay questions:

1. Develop a sequence diagram showing the interactions involved when a student registers for a course in a university. Courses may have limited enrollment, so the registration process must include checks that seats are available. Assume that the student accesses an electronic course catalog to find out about available courses.

2. Based on your experience with a bank ATM, draw an activity diagram that models the data processing involved when a customer withdraws cash from the machine.

3. Draw a state diagram for an automatic washing machine that has different programs for different types of clothes.

4. Describe three examples of design conflicts that might arise when developing an architectural model to satisfy multiple non functional requirements. Specifically, explain why satisfying both the availability and security requirements might be difficult to achieve, and identify two additional pairs of non functional requirements and explain the inherent design conflicts invloved.

5. Explain the advantages of using architectural patterns when designing the architecture of a large system.

6. Using the UML graphical notation for object classes, design an object class for a library catalog. Use your own experience to decide on the attributes and operations that should be associated with this object.

7. Using examples, explain why configuration management is important when a team of people is developing a software product.

8. Some people argue that developers should not be involved in testing their own code but that all testing should be the responsibility of a separate team. Give arguments for and against testing by the developers themselves.

9. What are the benefits of involving users in release testing at an early stage in the testing process? Are there any disadvantages in this level of user involvement?

10. Explain why a high-quality software process should lead to high-quality software products. Discuss possible problems with this approach to quality management.

11. Explain how standards may be used to capture organizational wisdom about effective methods of software development. Give specific examples of organizationally defined standards that might be useful in software development. Be sure to explain why each provides benefit to development activities.

12. Explain why many systems developed today do not adequately address privacy and security needs. Suggest ways to improve the development process to address this problem.

13. One of the key roadblocks to reuse is getting software developers to consider reusing existing components, rather than reinventing new ones. (After all, building things is fun!) Suggest several different ways in which a software organization can provide incentives for software engineers to reuse existing software components and when new development is necessary, develop components that are reusable. What technologies should be in place to support the reuse effort?

14. Suppose you worked for a software company that did not have a formal process for reviewing the code or any of the other software artifacts (e.g., requirements, designs, test plans, etc.) before formal testing. What arguments could you use to try to convince your company's management to change the process to include formal software inspections as a routine practice? That is, what are the advantages of software inspections, and how would one begin to implement a change to incorporate them within the software development process?

15. Suppose one of the risks for a software project that you are managing is that you suspect that the customer does not really know what he/she needs or wants. That is, you expect that the requirements are likely to change. Develop an RMMM plan for this risk. In particular, specify what steps you would take to try to mitigate the risk, how you would monitor the situation, and what your contingency plan would be if it appeared that customer changes were going to affect the schedule or cost.