Software Design and Engineering -- Module 1

Software Products

Large and complex systems that requires analysis and synthesis during development

Analysis

Decomposing a large problem into smaller, understandable pieces. Abstraction is the key

Synthesis

Building software from smaller blocks created through analysis. Composition is challenging

Method

Refers to a formal procedure

Tool

An instrument or automated system for accomplishing something in a better way

Procedure

Combining tools and techniques to produce a product

Paradigm

Philosophy or approach for building a product

Computer Science

Field that focuses on hardware and programming languages

Software Engineering

Field that focuses on computer as a problem-solving tool

• Fault

• Failure

2 types of bugs

Fault

Occurs when a human makes a mistake/error in performing some software activities

Failure

A departure from the system’s required behavior caused by the fault

Safety-Critical

When a system’s failure poses a threat to life or health

1. Transcendental

2. User

3. Manufacturing

4. Product

5. Value-Based

The 5 views/perspectives on quality

Transcendental View

Perspective wherein quality is something we can recognize but not define

User View

Perspective wherein quality is fitness for purpose

Manufacturing View

Perspective wherein quality is conformance to specification

Product View

Perspective wherein quality is tied to inherent product characeristics

Value-Based

Perspective wherein quality depends on the amount the customers is willing to pay for it

Good Software Engineering

An engineer that practices implementing strategies for producing quality software

• Quality of Product

• Quality of Process

• Quality of Product in Business Environment

3 ways of considering quality

Quality of Product

Users judge a product’s external characteristics such as correct functionality, number of failures, and types of failures

Quality of Product

Designers and maintainers judge the products internal characteristics such as its type of faults

Quality of Product

The user’s external view must be related/aligned to the developer’s internal view

Quality of Process

The quality of the development and maintenance process. Just as important as the quality of product

Quality of Process

Requires detailed/extensive modeling of the development process

Modeling

This process address questions like:

• Where to find particular faults

• How to find faults earlier

• How to build in fault tolerance

• What are alternative activities

• Capability Maturity Model (CMM)

• ISO 9000

• Software Process Improvement and Capability Determination (SPICE)

3 models for process improvement

Business Value

Must be quantified when in relationship to technical value. It is as important as technical value

Return on Investment (ROI)

A common approach for business value. Giving up assets for other purposes

Return on Investment (ROI)

Has many interpretations such as reducing costs, predicting savings, improving productivity, and costs (efforts and resources)

Customer

The company, organization, or person who pays for the software system

Developer

The company, organization, or person who builds the software system

User

The person or people who will actually use the system

Activity

An event initiated by a trigger

Objects/Entities

The elements involved in activities

Relationship

Defines the interaction among entities and activities

System Boundaries

Determine the origin of input and destinations of the output

Interrelated Systems

Systems that are dependent to other systems, and these interdependencies can be complex. Thus why it’s also sometimes referred to as a layered system

Interrelated Systems

Situation where one system exists inside another system.

Boundary Definitions

If these are defined well and are detailed building larger systems from smaller ones become relatively easy

Designers

Members of the team who generates a system-level description of what the system is supposed to do

Trainers

Members of the team who show users how to use the system

Librarians

Prepares and stores documents such as software requirements

Configuration Management Team

Member of the team who maintains correspondence among various artifacts

Transformation

In this design of software engineering from before the 1970s, input is converted to output

Transaction

In this design of software engineering from after the 1970s, input determines which function should be performed

Abstraction

It hides details thus it becomes a description of the problem at some level of generalization

Analysis and Design Methods and Notations

Provides documentation, facilitates communication, offers multiple views, and unifies the different views

User Interface Prototyping

Building a small version of a system which helps in developing good user interface

Software Architecture

Describes the system in terms of a set of architectural units and relationships between these units

Potential concerns with software reuse

• Generalized components take more time to build

• It may be faster to build smaller applications than searching for reusable components

• Generality vs. Specificity

Platform Integration

Tools/integrated environments on heterogeneous networks

Presentation Integration

Tools/integrated environments for commonality of user interface

Process Integration

Tools/integrated environments that links the tools and the development process

Data Integration

Tools/integrated environments used to share common data

Control Integration

Tools/integrated environments where one tool has the ability to initiate action in another one