Software Engineering Chapter 1 & 2

Second Law of Software Engineering

Software should be written for people first

Initiating actor

(also called primary actor or simply user): initiates the use case to realize a goal, which depends on the actor's responsibilities and the current context

FURPS+

Functionality lists additional functional requirements that might be considered, such as security, which refers to ensuring data integrity and authorized access to information Usability refers to the ease of use, aesthetics, consistency, and documentation—a system that is difficult and confusing to use will likely fail to accomplish its intended purpose Reliability specifies the expected frequency of system failure under certain operating conditions, as well as recoverability, predictability, accuracy, and mean time to failure Performance details the computing speed, efficiency, resource consumption, throughput, and response time Supportability characterizes testability, adaptability, maintainability, compatibility, configurability, installability, scalability, and localizability

Participating actor

(also called secondary actor): participates in the use case but does not initiate it; there are two subcategories: (a) Supporting actor: helps the system-to-be to complete the use case—that is, our system-to-be initiates the supporting actor (b) Offstage actor: passively participates in the use case, i.e., neither initiates nor helps complete the use case, but may be notified about some aspect of it

System Sequence Diagrams

A system sequence diagram represents in a visual form a usage scenario that an actor experiences while trying to obtain a service from the system. In a way, they summarize textual description of the use case scenarios.

incremental and iterative

1. Break the big problem down into smaller pieces (increments) and prioritize them. 2. In each iteration progress through the development in more depth. 3. Seek the customer feedback and change course based on improved understanding.

Waterfall process

1. Requirements Specification - Understanding the usage scenarios and deriving the static domain model 2. Design - Assigning responsibilities to objects and specifying detailed dynamics of their interactions under different usage scenarios 3. Implementation - Encoding the design in a programming language 4. Testing - Individual classes/components (unit testing) and the entire system (integration testing) 5. Operation and Maintenance - Running the system; Fixing bugs and adding new features

Test-driven development (TDD)

A development methodology in which tests for a function are written before the function is written

requirements specification

A document that sets out the customer requirements of a computer system. It is written as part of the systems analysis and can be used later to evaluate the system when implemented. It represents the problem statement in a semiformal or formal manner to ensure clarity, consistency, and completeness.

A well- defined problem

A set of criteria ("requirements") according to which proposed solutions either definitely solve the problem or fail to solve it. The description of the resources and components at disposal to solve the problem.

User Story

A small, concise statement of functionality or quality needed to deliver value to a specific stakeholder. // user-role + capability + business-value

Object-Oriented Design

A software design method that models the characteristics of abstract or real objects using classes and objects. In software development, the key activity in the design phase is assigning responsibilities to software objects. A software application can be seen as a set or community of interacting software objects. Each object embodies one or more roles, a role being defined by a set of related responsibilities. Roles, i.e., objects, collaborate to carry out their responsibilities. Our goal is to create a design in which they do it in a most efficient manner. Efficient design contributes to system performance, but no less important contribution is in making the design easier to understand by humans.

Agile Development

A software development methodology that delivers functionality in rapid iterations, measured in weeks, requiring frequent communication, development, testing, and delivery.

stakeholder

A stakeholder is an individual, team, or organization with interests in, or concerns related to, the system-to-be.

access designations

Access to object attributes and methods is controlled using access designations, also known as visibility of attributes and methods. When an object attribute or method is defined as public, other objects can directly access it. When an attribute or method is defined as private, only that specific object can access it (not even the descendant objects that inherit from this class). Another access modifier, protected, allows access by related objects, as described in the next section.

Domain Model

An object model of the domain that incorporates both behavior and data

Boundary Testing

Boundary testing is a special case of equivalence testing that focuses on the boundary values of input parameters.

Domain Analysis & Modeling

Domain analysis and modeling identifies the system elements needed to solve the problem (i.e., meet the requirements) The goal of domain modeling is to understand how system-to-be will work

Equivalence Testing

Equivalence testing is a black-box testing method that divides the space of all possible inputs into equivalence groups such that the program "behaves the same" on each group.

Use Cases vs. Domain Model

In use case analysis, we consider the system as a "black box" In domain analysis, we consider the system as a "transparent box"

Object Relations

Is-a relationship (hollow triangle symbol ∆ in UML diagrams): A class "inherits" from another class, known as base class, or parent class, or superclass Has-a relationship: A class "contains" another class

Unified Process

Methods that are even more aggressive in terms of short iterations and heavy customer involvement are characterized as Agile.

Product development phase

Planning / Specification Design Implementation Evaluation

Requirements engineering

Requirements engineering helps software engineers understand the problem they are to solve. It involves activities that lead to understanding the business context, what the customer wants, how end-users will interact with the software, and what the business impact will be.

Customer

Requires a computer system to achieve some business goals by user interaction or interaction with the environment in a specified manner

Polymorphism

Same method behaves differently on different subclasses of the same class

First law of software engineering

Software engineer is willing to learn the problem domain(problem cannot be solved without understanding it first)

Software engineer's do?

Software engineer's focus is on understanding the interaction between the system-to-be and its users and the environment, and designing the software-to-be based on this understanding.

Black Box Testing

Testing, either functional or non-functional, without reference to the internal structure of the component or system.

Traceability

The ability to identify related items in documentation and software, such as requirements with associated tests. Traceability must be maintained across the lifecycle. Maintaining traceability involves recording, structuring, linking, grouping, and maintaining dependencies between requirements and other software artifacts.

Requirements gathering

The analysis of this information leads to the development of a concept for a new system. This concept is used to build a set of analysis models.

requirements analysis or systems analysis

The goal is to produce the system specification—the document that is an exact description of what the planned system-to-be is to do. Requirements analysis delimits the system and specifies the services it offers, identifies the types of users that will interact with the system, and identifies other systems that interact with ours.

key of incremental and iterative

The key of incremental and iterative methods is to progressively deepen the understanding or "visualization" of the target product, by both advancing and retracting to earlier activities to rediscover more of its features.

Requirements Analysis

The second phase in the SDLC, in which developers conduct user interviews; evaluate existing systems; determine new forms/reports/queries; identify new features and functions, including security; and create the data model. It involves refining of and reasoning about the requirements received from the customer during requirements gathering

Domain Modeling

To achieve N different things, we need N different tasks-

Software Engineer's task

To understand how the system-to-be needs to interact with the user or the environment so that customer's requirement is met and design the software-to-be

Non-functional requirements

describe some quality characteristic that the system-to-be shall exhibit.

Functional requirements

determine the system's expected behavior and the effects it should produce in the problem domain. These requirements generally represent the main product features.

Sizing the Problem

guess and multiply by two

actor

is any entity (human, physical object, or another system) external to the system-to-be that interacts with the system-to-be. Actors have their responsibilities and seek the system's assistance in managing those responsibilities.

Software architecture

the set of principal design decisions about the system, is a set of high-level decisions made during the development and evolution of a software system.

Software Development Methods

➢Method = work strategy ▪The Feynman Problem-Solving Algorithm:(i) Write down the problem (ii) think very hard, and (iii) write down the answer. ➢Waterfall ▪Unidirectional, finish this step before moving to the next ➢Iterative + Incremental ▪Develop increment of functionality, repeat in a feedback loop ➢Agile ▪User feedback essential; feedback loops on several levels of granularity

Software Engineering Blueprints

➢Specifying software problems and solutions is like cartoon strip writing ➢Unfortunately, most of us are not artists, so we will use something less exciting: