Test

Question 1

1. Attributes of good software?

Answer 1

Good software should deliver the required functionality and performance to the user and should be maintainable, dependable, and usable.

Question 2

2. Software products: generic products & customized products

Answer 2

Generic Products: Stand-alone systems that are marketed and sold to any customer who wishes to buy them; cookie-cutter based products. Ex: Project management tools, photoshop software, calculator program, C book, etc.

Customized Products: Software that is commissioned by a specific customer to meet their own needs. Ex: Embedded control systems, traffic monitoring systems, bank management software, a system to operate a company’s machinery.

Question 3

3. Software process activities?

Answer 3

Software Specification - Customers and engineers define the software that is to be produced and the constraints on its operation.
Software Development - Software is designed and programmed.
Software Validation - Customer checks to ensure that the software is what the customer requires.
Software Evolution - Software is modified to reflect changing customer and market requirements.
Useful Acronym: SDVE

Question 4

4(a). Stand-Alone Applications

Answer 4

Run on a local computer, such as a PC or phone. Includes all necessary functionality and does not need to be connected to a network.

Question 5

4(a). Interactive Transaction-Based Applications

Answer 5

Applications that execute on a remote computer and are accessed by users from their own PCs or terminals. Ex: E-commerce applications that interact with a remote system.

Question 6

4(a). Embedded Control Systems

Answer 6

Software control systems that control and manage hardware devices.

Question 7

4(a). Batch Processing Systems

Answer 7

Business systems that are designed to process data in large batches; process large numbers of individual inputs to create corresponding outputs

Question 8

4(a). Systems for modeling and simulations

Answer 8

Developed by scientists and engineers to model physical processes or situations, which include many separate interacting objects.

Question 9

4(a). Data collection systems

Answer 9

Systems that collect data from their environment using a set of sensors and send that data to other systems for processing. “Big data” analysis may involve cloud-based systems carrying out statistical analysis and looking for relationships in the data.

Question 10

4(a). System of systems

Answer 10

System composed of a number of other systems.

Question 11

4. 8 Software Application Types

Answer 11

Stand-alone, Embedded Control Systems, Batch Processing, Systems for modeling and simulations, Data collection systems, system of systems, Entertainment, Interactive-transaction based

Question 12

5. Software engineering ethics

Answer 12

Confidentiality - Respect the confidentiality of employers or clients regardless of a formal agreement.
Competence - Engineers should not knowingly accept work that goes beyond their competence (ability).
Intellectual Property Rights - Be aware of local laws governing the use of intellectual property such as patents, copyright, etc.
Computer Misuse - Do not use technical skills to misuse other people’s computers. Can be minor (gaming on a PC) or major (spreading a virus or keylogging).

Question 13

6. Four activities that are common to all software processes

Answer 13

Specification - Defining what the system should do.
Design and Implementation - Defining the organization of the system and how it will be implemented.
Validation - Checking that the software does what the customer wants.
Evaluation (Evolution) - Modifying the system in response to changing customer needs.

Question 14

Waterfall model

Answer 14

A plan-driven model with separate and distinct phases of specification and development. Effective for large system engineering products where a system is developed at several sites and when requirements are fairly well-known from the start.
Advantages:
* Useful when the requirements are well-understood and changes will be fairly limited during the design process.
Cons:
* There is difficulty accommodating change after the design process is underway.
* Difficult to respond to changing customer requirements.

Question 15

Incremental Development

Answer 15

Incremental Development - Specification, development, and validation are interleaved. Developed as a series of versions (increments), with each version adding functionality to the previous version. Can be plan-driven or agile.
Advantages:
* The cost of accommodating changing customer requirements is reduced.
* It is easier to get customer feedback on the development work that has been done.
* Quicker delivery and deployment of useful software to the customer.
Cons:
* The process is not visible (hard to produce documents for every version).
* System structure tends to degrade as new increments are added.

Question 16

Integration and Configuration

Answer 16

Integration and Configuration - Based on software reuse where systems are integrated from existing components or application systems (“off the shelf”). Reused elements may be configured to adapt the behavior and functionality of a new user’s requirements. Standard approach for building many types of business systems.
Advantages:
* Reduced costs and risks.
* Faster delivery and development of the system to be made.
Cons:
* Requirement compromises are inevitable.
* Loss of control over the evolution of reused system elements.

Question 17

9. Component testing, system testing, and customer testing.

Answer 17

Component Testing - Individual components are tested independently, without other system components.
System Testing - Tests the system as a whole to find errors that result from unanticipated interactions between components and component interface problems.
Customer Testing - Testing with customer data to check that the system meets their needs.

Question 18

Prototyping

Answer 18

Prototyping is using the initial version of a system to demonstrate concepts and try out design options. Used in the requirements, design, and testing processes.
Benefits include: Improved system usability, having a closer match to user needs, improved design quality and maintainability, and reduced development effort.

Question 19

Agile Development

Answer 19

In agile development, program specification and design and implementation are interleaved.
The system is developed as a series of versions or increments with stakeholders involved in version specification and evaluation. There is minimal documentation; working code is the focus.

Question 20

12. Advantages and disadvantages of agile development?

Answer 20

Advantages:
* Can get feedback from the customer quickly.
* The whole team has visibility of the product.
* Effective when a product has many requirement changes over time, and when developing small or medium-sized products.
Disadvantages:
* Lack of product documentation.
* Keeping customers involved in the development process.
* Maintaining the continuity of the development team.

Question 21

13. Extreme Programming: test-first development, refactoring, on-site customer, small releases, and collective ownership.

Answer 21

Extreme Programming (XP) - An “extreme” approach to iterative development. New versions may be built several times per day. Increments are delivered to customers every 2 weeks. All tests must be run for every build, and the build is only accepted if tests run successfully.
* Remember, XP uses test-first development! Development cannot proceed until test cases have been developed.
Refactoring - Changing the code to create a more efficient way to run the program. All developers are expected to refactor the code continuously as soon as possible to keep the code simple and maintainable. This is done even when no software improvements are immediately needed.
On-Site Customer - A representative of the end-user of the system should be available full-time for the use of the XP team. This person is responsible for bringing system requirements to the team for implementation on the behalf of the customer.
Small Releases - The minimally useful set of functionality that provides business value is developed first. Releases of the system are frequent; incrementally add functionality to the first release.
Collective Ownership - Pairs of two developers work on all areas of the system, so that no islands of expertise develop and all developers take responsibility for the code. Anyone can change anything.

Question 22

14. What is scrum?

Answer 22

Scrum is an agile method that focuses on managing iterative development, rather than specific agile practices.
Three phases: Outline planning, sprint cycles, and project closure.

Question 23

15. Roles in Scrum: Scrum master, team, and product owner.

Answer 23

Scrum Master - Responsible for ensuring that the scrum process is followed and guides the team in the effective use of Scrum.
Team - A self-organizing group of software developers responsible for developing the software and other essential project documents. No more than 7 people should be in a team.
Product Owner - An individual or small group whose job is to identify product features or requirements, so they can prioritize these for development. They continuously review the product backlog to ensure that the project continues to meet critical business needs.

Question 24

16. Keywords: Velocity, product backlog, sprint planning, sprint review, product owner, and multi-team Scrum.

Answer 24

Velocity - An estimate of how much product backlog effort a team can cover in a single sprint. Can help estimate what can be covered in a sprint and provides a basis for measuring performance.
* Sprint: A development iteration. They are usually 2-4 weeks long.
Product backlog - A “to do” list of items that the scrum team must tackle. May feature definitions for the software, software requirements, user stories, or descriptions of supplementary tasks that are needed.
Sprint planning - The team pulls a chunk from the product backlog and decides how to complete it.
Sprint review - Reviews the product to see if the work is potentially shippable.
Product owner - Defined in Question 15 above.
Multi-team Scrum - Scrum that has been adapted for large-scale development. Characteristics include:
* Role Replication - Each team has a product owner for their work component and Scrum Master.
* Product Architects - Product architects collaborate to design and evolve the overall system architecture. Each team gets one.
* Release Alignment - Dates of product releases from each team are aligned so that a demonstrable and complete system is produced.
* Scrum of Scrums - There is a daily scrum of scrums where representatives from each team meet to discuss progress and plan work to be done that day.
Bonus: Remember that Scrum and XP are examples of agile development techniques.

Question 25

17. User Requirements vs. System Requirements

Answer 25

User Requirements: Statements in natural language, plus diagrams of the services the system provides and its operation constraints. Written for customers.

System Requirements: Structured document setting out detailed descriptions of the system’s functions, services, and operational constraints. Defines what should be implemented, so the document may be part of a contract between client and contractor.

Question 26

18. Stakeholders

Answer 26

Stakeholders - Any person or organization who is affected by the system in some way, and therefore has legitimate interest. They can have a direct or indirect influence on the requirements of the system.
* Stakeholder Types: End users, system managers, system owners, and external stakeholders.

Question 27

18. Functional Requirements

Answer 27

Functional Requirements - Statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. May be high-level, detailed statements of what the system should do or should not do.
Example (Bank Website): Users should be able to log into the system. The system could offer:
* Transfer Funds
* Pay Bills
* View Account Balance

Question 28

18. Non-functional requirements

Answer 28

Non-functional requirements - Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often applied to the system as a whole rather than individual features or services.
* Process requirements may also be specified mandating a particular IDE, programming language, or development method.
* Non-functional requirements can be more critical than functional requirements. If they are not met, the system may be useless.
Example (Bank Website):
* Product requirements, such as details about the memory usage and security of the website.
* Users should login within 4 seconds.
* Each request should be processed within 10 seconds.

Question 29

18. Requirements elicitation/discovery

Answer 29

Requirements elicitation/discovery - Involves technical staff working with customers to find out about the application domain, the services that the system should provide, and the system’s operational constraints. May involve stakeholders such as end users, managers, maintenance engineers, domain experts, trade unions, etc.

Question 30

19. How to elicitate requirements?

Answer 30

19. How to elicitate requirements?
    Software Engineers work with a range of system stakeholders to find out the application domain, the services that the system should provide, the required system performance, hardware constraints, etc.
    The 4 Stages of Requirement Elicitation:
    * Requirements Discovery - Interact with stakeholders to discover their requirements.
    * Requirements Classification and Organization - Take the unstructured collection of requirements, group related requirements, and organize them into clusters.
    * Requirements Prioritization and Negotiation - When multiple stakeholders are involved, requirements will conflict. Find agreement on compromised requirements and prioritize them.
    * Requirements Specification (Documentation) - Requirements are documented and put into the next round of the spiral. An early draft of the software requirements may be produced at this stage.

Question 31

20. What is the requirements specification?

Answer 31

Requirements specification is the process of writing down the user and system requirements in a requirements document.
* User requirements have to be understandable by end-users and customers who do not have a technical background.
* System requirements are more detailed requirements and may include more technical information.

Question 32

21. Why do we do requirements validation?

Answer 32

Requirements validation is concerned with demonstrating that the requirements define the system that the customer really wants. Requirement error costs are high, so validation is important to get right the first time. Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

Question 33

22. Reasons for requirement changes.

Answer 33

Hardware and interfaces are always changing, which means requirements will have to change along with them. Law-making also has an impact on changing requirements. Other reasons include:
* The people who pay for a system and the users of that system are rarely the same (user changes).
* There may be conflicting requirements that need to be resolved, or old requirements may need to be removed.