COMPUTING SCIENCE 220
Software Engineering and Human-Computer Interfaces

Software Engineering Concepts

Project

All the activities related to the development of a software system, from the identification of a problem to the delivery of a product; a software development effort taking a system through a life cycle [1].

Activity

A set of tasks that is performed toward a specific purpose; for example,

• requirements elicitation
• design
• management
• delivery

Phase

In some life cycle models, equivalent to 'activity'; in others (such as the Unified process), the span of time between two major milestones of a development process [2]:

• inception
• elaboration
• construction
• transition

Milestone

An important project event. A major milestone is a point at which management makes important business decisions (e.g., go/no-go, schedule, budget).

Task

An atomic unit of work that can be managed (assigned to a developer, monitored by the manager)

• consumes resources
• results in work products
• depends on work products produced by other tasks

Resources

Assets used to accomplish work.

• time
• equipment
• labour (see participant)

Work Product

An artifact (a document or a piece of software) produced during development.

• Internal work product — used by other developers.
• Deliverable — for the client

Participant

A person involved in a project.

• client
• developer
• project manager
• end user

Role

A set of responsibilities in a project or system.

• associated with a set of tasks
• assigned to a participant
• A participant can fill multiple roles.

[Images from Rational Unified Process: Best Practices for Software Development Teams]

Goal

A high-level principle that guides a project; the important attributes of a system.

• functional requirement — a requirement that specifies an action that a system must be able to perform; a specification of the input/output behaviour of a system.
• nonfunctional requirement — a requirement that specifies system properties or physical constraints.

Notation

A graphical or textual set of rules for representing a model (e.g., UML)

Method

A repeatable technique for solving a specific problem (e.g., rationale management, configuration management)

Methodology

A collection of methods for solving a class of problems (e.g., Unified Software Development Process, Object Modeling Technique (OMT), Booch method, Objectory, Catalysis, Fusion); the methods specified for the activities of the process vary from methodology to methodology, but typically include the activities listed in the next section.

Software Engineering Development Activities

• Requirements Elicitation — The client and developers define the purpose of the system, including both functional and nonfunctional requirements, producing a description of the system in a use-case model, including actors and use cases.
  • actors — external entities that interact with the system, including end users, other computers the system needs to deal with, and the environment.
  • use cases — general sequences of events that describe all the possible actions between an actor and the system for a given piece of functionality, using the language of the customer.
• Analysis — The development of a conceptual model of the problem [see 3]; the transformation of the use cases into an object model that completely describes the system using the language of the developers.
• Design
  • system design — strategic decisions, such as decomposing the system into subsystems which can be assigned to teams, selecting the platform (hardware, operating system) on which the system will run, deciding how to handle persistent data, adopting an access control policy, etc.
  • object design — transforms analysis model into an object model that can be implemented (or, in the case of components, purchased or reused).
• Implementation — the translation of the object model into source code.
• Testing — verification of the result from implementation by testing each build and identification of defects to be fed back to the design and implementation activities.

References

[1] Jacobson et al., The Unified Software Development Process (Addison Wesley, 1999), p. 447.

[2] Ibid.

[3] Martin Fowler, Analysis Patterns: Reusable Object Models (Addison Wesley, 1997), p. 1.