CSS 360 Midterm 2 Review

Metric

A measurement provided quantitative information about quality and productivity of software projects and processes.

FP (Function Points)

A metric that counts the number of data structures used - input types, output types, queries, logical internal files, and interfaces.

Model-View-Controller (MVC)

A pattern of app design in which view controllers serve as the communication pipeline between views and the data model. The objective is to promote separation, and allows you to have multiple views on the data and different ways to control data. Method invocations are represented by solid arrows and events by dotted arrows. This is often used in GUIs or user interfaces.

Incrementality

A process that proceeds in a stepwise fashion. An application includes the ability to identify useful early subsets that can be released to customers to get early feedback. It is almost always incorporated in Agile SDLC models.

Anticipation of Change

A quality essential for successful software - it should be able to change in response to changing requirements or environments often during its lifetime. It reduces cost of maintenance and cost over time.

Story Points

A relative unit of size, used for estimating, planning and tracking in an Agile project. Based on a combination of the size and complexity of the work, and is unitless but numerically relevant in its estimates.

System Reliability Factors

A set of factors that affect reliability. Some include hardware and infrastructure, software errors, and human error, and external factors like physical environment, operations, and business environments (enforcement, ethics, etc.)

Shrink-Wrap Software

A software package sold as a product for profit. This can be an in-store product, a downloadable product, or a subscription-based online application.

Absolute Quality

A software quality that is based on binary choice - it either satisfies or does not satisfy the requirement.

Relative Quality

A software quality where you can be a little bit off, but that is still okay for the user's purpose.

Information Hiding

A special case of abstraction, treating modules in a system as "black boxes," with inputs, outputs, and purposes all in one.

Client-Server Architecture

A special case of layered architecture with 2 different versions (2-tier [2 layers] or 3-tier [2 layers and an additional application server between them]). Best used where centralized data or processing is needed, like a business application or web application.

Abstraction

A special case of separation of concerns. It is a process where important aspects of phenomena are identified but their details are ignored. Examples in code (usually for developers) and user interfaces (usually for users) - they represent the same reality, the code in this case.

Context Diagram

A systems model where the shapes have specific meanings: - The circle is the system being developed - The arrows are data flows - The boxes are external systems or data sources - every box needs to work in order for the Intranet to work.

Systems Model

A way to classify subsystems and components based on functionality, location, and other factors.

Separation of Concerns

A way to deal with different aspects of a problem so you can concentrate on and prioritize each part.

Requirements Traceability Matrix (RTM)

A way to keep track of which requirement is related to which testing. All requirements and test cases are identified with numbers and letters here, respectively.

Interfaces in Design

Abstractions of the functionality of a component, defining the set of services that components require or provide. - Required interfaces are defined by interactions with the provided interface's services. - Provided interfaces implement the services the required interfaces need. - They are like a contract - an agreement between different components. Other components rely on them, and if you change them, it can have far-reaching consequences.

Direct Data Manipulation

Addresses data editing, modification, and transformation.

Performance

An external quality based on user requirements, while efficiency is a internal quality that affects performance. Both affect usability and scalability.

Required Interface

An interface that connects to other components' provided interface.

Provided Interface

An interface that specifies one or more operations that a block (or one or more of its parts) must provide.

IT (Information Technology)

An organization's computing infrastructure support group. Also called Information Systems/Services (IS) and Management Information Systems (MIS).

COCOMO 2

An updated cost estimation model that - takes into account recent developments in SDLCs like code reuse, platforms, and distributed development. It uses object points and lines of code together as its metrics.

Middleware

Any extension to an operating system.

Systems Engineering

Applies engineering principles in designing and managing large complicated projects.

Navigation

Assists the user in navigating through menus, webpages, and interactive display screens.

Design Patterns

Broad strategies for designing software to communicate objects and classes and solve a category of problems.

Forms and Input

Considers a variety of design techniques for form-level input.

Adapter Pattern

Design pattern that converts interfaces of a class to another interface the client expects. Used when you want to create a reusable class or when you want to create an existing class, but its interface does not match the one you need.

Custom Development

Developing unique software for one particular customer and problem. This may be performed by internal IT people or contractors - it is viewed as an evolution of changes and enhancements. It is easier to deploy and implement changes here than in shrink-wrap. Customers are always managers supporting the system's development.

Requirements Document

Document which includes a needs statement, a source of data, and a summary of calculations, often used as a contract between the team and the customers.

Layered Architecture

Each layer relies on the facilities and services of the layer immediately beneath it. It supports separation between layers because each layer has its own set of services, and supports independence because you can pull one layer out and substitute another one with the same interfaces in without affecting other layers. Best used in the design of operating systems and network protocols.

Search

Enables content-specific searches through information maintained within the site or contained by data storages accessible via interactive applications.

Workflow Patterns

Flow of events to help address recurring business processes and facilitate the flow of work

Configuration

How components and connectors are connected to one another in SW architecture.

Requirements Identification

How requirements are individually identified. Identify the problem to be solved, the features of the solution, the business case, and the acceptance criteria

Page Elements

Implements specific elements of a webpage or display screen.

Relations Between Interfaces and SWE Principles

Interfaces are closely related to core SWE principles, because interfaces modularize functionalities of a system, abstract implementation details (only exposing what it needs or what other components can use), anticipate change (exposing methods that are highly stable and hiding those that are not).

Why SW Architecture is Important

It affects performance, robustness, and distributability of systems. Functional requirements depend on components but non-functional requirements depend on architecture. SW architecture always affects qualities.

Problems with Bad Design

It will never be completely implemented, due to a lack of modularity and abstraction. This leads to conflicts among developers and many integration problems. Not anticipating change in your design leads to redesigns and reimplementations, lack of generality leads to "code bloat," which is unnecessarily long or slow performance, and lack of incrementality leads to a "big bang" (final build, unusable) approach that is likely to fail and frustrates users and developers alike.

Object Points

Measures counting the types of items to implement, and measure the complexity of a project.

Object-Oriented Architecture

Multiple objects with multiple procedure calls affecting them. Best used in applications where developers want a close correspondence with the real world, and in applications that utilize dynamic data structures.

Sequence Pattern

Pattern indicating that work occurs linearly, one step at a time.

Parallel Split

Pattern indicating the work can split into two branches, where the branches work parallelly.

Synchronization

Pattern showing that work can occur in any order, meeting at the end.

UI Patterns

Patterns used for designing the user interface, the means by which a user and a computer system interact.

Tables

Provide design guidance for creating and manipulating tabular data of all kinds.

Whole UI

Provides design guidance for top-level structure and navigation throughout the entire interface.

Cloud Computing

Provides software services where applications run remotely - users do not buy any hardware or software.

Scenario

Real-life examples of how a system can be used, good for adding details to outline requirements descriptions. They include descriptions of the starting situation, descriptions of the normal flow of events, descriptions of what should go wrong, information about the other concurrent activities, and a description of the ending.

Move from Architecture to Modules

Repeat and apply the design process: - Designing internal architecture - Defining purpose - Defining provided interfaces - Defining required interfaces

Connectors

Representations of communication in SW architecture, represented by boxes with single outlines or rounded boxes.

Components

Representations of computation in SW architecture, represented by boxes with double outlines or square boxes.

Interfaces (SW Architecture)

Representations of entry and exit for components and connectors in SW architecture, represented by lines.

High-Level Software Processes

SWE processes that answer two important questions: - What shall we do next? - How long shall we continue doing it? These are typically expressed as SDLCs.

Entertainment Software

Software (games) that always has a mass market, and is highly multidisciplinary because its development requires teams of artists and engineers. It is similar to film or television production, and performance is the most important quality, as games are highly dependent on user actions.

Embedded Software

Software embedded into a larger hardware-based system. Users indirectly interact with software, even if they don't realize it. Functionality is provided by the system as a whole - the software only assists in digital processing, and usually involves real-time systems that interact with the external environment in a timely manner.

Consumer Mass Market Software

Software of general or consumer interest. Some examples include office software, antiviruses, and home accounting or tax software. They help users accomplish tasks.

Vertical Market Software

Software that directly improves key processes of a specific business. Some examples include electronic CAD systems and Point-of-Sale (POS) software. These are often bundled with hardware and software.

Web Services

Software that enables services to be sold through the Internet. A "service" is one specific functionality.

E-commerce

Specific to websites, implementing purchase and sales models.

Real-Time Systems

Systems that directly interact with environments through sensors and actuators, and require scheduling of tasks.

Traceability Policies

The amount of information about requirements relationships that is maintained - it tells users how traceability will be tested.

Modularity

The breakdown of complex systems into simple pieces. Breaking down into modules can enhance reusability, either in the next version or the next product. The pieces are called modules. It is important because of high cohesion (strength of relationships between elements in one module) and low coupling (strength of relationships between modules).

Software Process

The business process of SWE - a structured set of activities covering the creation, deployment, and maintaining of software.

Traceability

The capability to determine whether requirements are satisfied. Concerned with the relationships between requirements, their sources, and the system's design.

Software Design

The creation of a blueprint that solves problems posed by requirements analysis. This process involves the selection of key technologies and/or approaches.

Main Program and Subroutines

The main program invokes different functions and methods. In this case, it makes procedure calls to different functions (the subroutines). Typical uses for this architecture style are small programs, and this style will not scale onto larger programs.

Requirements

The parameters placed on the development of a product or system. The requirements include the safety needs, the physical laws that will limit the development of an idea, the available resources, the cultural norms, and the use of criteria and constraints.

Change Management Process

The process followed when analyzing requirements changes.

Requirements Engineering

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

Software Architecture

The set of principal design decisions about the system. Principal decisions are defined by the development team's decision of system goals.

Software Quality

The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs.

Page Layout

The way text, graphics, and space are organized. Addresses the general organization of pages for websites or the distinct screen displays for interactive applications.

Upper CASE Tools

Tools that help with documentation and modeling of problems and its solutions. They assist with capturing requirements as well as modeling and design, and they support the top phases of Waterfall models.

Lower CASE Tools

Tools that support activities in the lower phases of Waterfall models, like coding, testing, and maintenance.

Reusability

When a product can be used to build another product.

Robustness

When a program behaves "reasonably" even in circumstances that were not anticipated in the requirements specification.

Correctness

When a program behaves according to its stated functional specifications.

Interoperability

When a system can coexist and cooperate with other systems, like incorporating a chart produced by a graphics package into a spreadsheet.

Usability

When human users can find a program easy to use. It is highly subjective.

Maintainability

When modifications can be made easily to software systems after initial release. There are several kinds: Corrective (removes residual errors), adaptive (adjusts software to changes in the environment), and perfective (changes software to improve some of its qualities or add new features)

Understandability

When software can be used and understood easily. Internally, this is for maintenance, but externally, this is for usability.

Portability

When software can run in different environments, usually to isolate dependencies on the opening system into a few isolated modules.

Reliability

When users can depend on software. It is partly based on the probability that software will operate as expected over a specific time interval - it is okay to have an "incorrect" system that is still reliable.

Sense-Compute-Control

When you want a system to react to stimuli, you use this model. There are a set of sensors that sense environmental conditions, a computer component that computes based on data, and actuators that call specific actions. An example is a self-driving car, where the sensor senses vehicle speed, the compute component checks speed laws, and the actuator is the gas pedal, which can change the car's speeds.

Repository Architecture

(Blackboard Architecture) A good way to share large amounts of data among interacting components. Actions are invoked based on changes to data, and components operate around and agreed data model. Typically used when you want components to interact through changes to centralized data.

CASE Tools

(Computer-Aided Software Engineering) A range of tools that support software professionals by automating or assisting with the use of SWE methods.

COCOMO

(Constructive Cost Modeling) A predictive model that estimates cost through attributes affecting productivity, called cost drivers.

Detailed Design

(Module Design) The more detailed design of individual components, focusing on internal workings of a component and its functionality (how does it work?)

SWEBOK

(SoftWare Engineering Body of Knowledge) A resource that describes knowledge areas that comprise all of the concepts, methods, and practices related to SWE.

KLOC

(Thousand Lines of Code) Not a good metric because instead of counting lines people can count things that would be more useful.

Metrics for Quality and Productivity

- Amount of code per unit of time (KLOC/time or FP/time) - Amount of features per unit of time - Cost per KLOC - Faults per KLOC or faults per hour of review (for quality assurance)

Advantages of Story Points

- Forcing the use of relative estimating: studies have shown that people are good at this. - Focusing on estimating size rather than duration: we derive duration empirically by seeing how much we complete per iteration. - Putting estimates in units we can add together: time-based estimates are not additive, and time is different for everyone.

Advantages of SW Architecture

- Helping with stakeholder communication, because the development team could use designs to develop better software. - Helping with systems analysis by analyzing the design and detecting flaws before code is written. - Helping with large-scale reuse because one can reuse architectural styles from scratch. It is like a design template.

Applying Fundamental SWE Principles to Design

- Separation of concerns works so that work can be parallel. Abstraction allows work in isolation, because interfaces guarantee that components will work together. Modularity allows work in isolation because components are independent of each other. - Anticipation of change allows changes to be absorbed seamlessly. - Generality allows the reuse of components throughout the system. (We never covered generality in class, it is just the creation of general purpose code) - Incrementality allows software to be developed with working results.

Differences Between Software Engineering and Systems Engineering

- Systems engineering deals with all aspects of creating and maintaining complete systems - hardware, software, infrastructure, operations, and everything else. - Software engineering concentrates specifically on the software component of the larger system. - They are difficult to separate in software-dominated systems.

Software Project Accuracy

- The degree to which the planner has properly estimated the size of the product to be built. - The ability to translate size estimates into human effort, calendar time, and money. - The degree to which the project plan reflects abilities of the software team. - The stability of product requirements and the environment supporting the development.

Advantages of Planning Poker

- Those who do the work estimate the work, and estimators are required to justify their estimates. - Most estimates are focused within an approximately low order of magnitude. - Combining of individual estimates through group discussion leads to better estimates. - Emphasizes relative rather than absolute estimating. - Estimates are constrained to a set of values so teams don't waste time in meaningless arguments. - Everyone's opinion is heard.

Architectural Patterns

A collection of architectural design decisions applicable to recurring design problems. Different styles serve different purposes.

Open Source Software

A community-based approach to software development. There is collaboration among paid and unpaid developers. It is not always free, and it can often contain a license.

Planning Poker

A consensus-based cost estimation technique in Scrum, mostly used to estimate effort or relative size of tasks in software development. The steps are as follows: 1. Each estimator is given a deck of cards, with each one having a valid estimate written on it. 2. The customer/product owner reads a story and it is discussed. 3. Each estimator selects a card for their estimate. 4. The cards are turned over so everyone can see the. 5. The team members discuss differences (especially outliers). 6. The team re-estimates until estimates converge.

Requirements Statement

A consolidation of all system models, discovery prototypes, and supporting documentation.