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


                        Risk management

                        People management

                        Proposal writing

            Managing People

                        Critical factors in people management





Motivating People (Human needs)

Physiological needs

Safety needs

Social needs

Esteem needs

Self-realization needs

Personality types




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


                        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 SizeB 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)


                        Robustness (availability)


            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


                                                Creating scenarios or use cases


                                    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                                        





                                    Techniques for validation



                                                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)


                        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



            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.





            Be able to describe different architectural patterns.





                        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


                        Problem description

                        Solution description


            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




                                    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.