CSE 3310 SWE Exam 1

What is software?

Computer programs + Configuration data and files + User and system documentation

What is software engineering?

An engineering discipline which is concerned with all aspect of software production.

Computer science is concerned with ___ while software engineering is concerned with __.

CS = theory and fundamentals
SWE = practical asepcts of developing and delivering software

SWE challenges:
1.
2.
3.

1. Coping with legacy systems

2. Coping with increasing diversity

   1. Coping with faster and cheaper

SWE is what % engineering, science, and art?

50% engineering, 30% science, 20% art

What is a software process?

A set of activities and associated results which produce a software product.

4 Fundamental process activities:

1.
2.
3.
4.

1. Software specification

2. Software development

3. Software validation

   1. Software evolution

What is a software process model?

A representation of software process from a specific perspective

Examples of software process models:

Workflow model: sequence of activities in the process along with their inputs, outputs and dependencies

Data-flow or activity model: set of activities that carry out some data transformation

Role/Action model: represents roles of people involved in the software process and activities for which they are responsible.

Software Development Models:

Definition: abstract representation of a software (i.e. roadmap)

The waterfall approach: complete one phase before going to the next

Evolutionary development: build quick, modify, and redo until completion

Formal transformation: transform specifications, using mathematical methods, to a program; guarantee correctness

Incremental method: Design and deliver parts as they become available

Attributes of good software are

Maintainability

Dependability

Efficiency

Usability

Ethical responsibilities are

Confidentiality

Competence

Intellectual property rights

Computer misuse

Waterfall Model “Life Cycle”

conducted in 5 phase: requirements, design, code, testing, maintenance

Pros: simple to follow, track progress, and has a good structural design

Cons: in practice, phases often overlap, hard to modify, need complete requirements before starting

Evolutionary Development Model

Develop, expose, refine

2 types:

1. Exploratory: start with well defined requirements and add new features when customers propose new ones

2. Throw-away prototyping: use prototyping to focus on poorly understood requirements, redefine as you progress

Pros: Happier customers, flexibility in modifying, very visual (no ambiguities)

Cons: Hard to trace progress, , poorly structured, special tools may be required, not cost effective

Formal Systems Development

Based on mathematical because math is 100% right

Requirements are refined into detailed specs which are expressed in mathematical notion.

Requires specialized expertise and is not often used

HEAVILY USED IN DFW FOR SOME REASON THOUGH

Reuse-oriented development

Relies on large base of reusable software components!

Pros: reduced cost and risk

Cons: requires large component base, some loss over control of the system evolution, and potential issues in backward/forward compatibility

Incremental Development

hybrid model where software spec, design, implementation and testing is broken down into a series of increments which are developed and delivered.

Pros: Delivered incrementally (faster), lower risk of project failure, requirements are implemented based on priority

Cons: Relationship b/w increments may be cumbersome or non-cohesive, size of each increment and # of increments may cause challenges

Spiral development

Hybrid model where development of the system spirals outward from initial outline to final developed systlem

Each loop represents a phase of the software process

Each loop is split into 4 sectors:

1. Object setting: set specific object for that phase

2. Risk assessment and reduction

3. Development and validation: select a development model based on risk levels

4. Planning: decide if a next loop is required

Pro: explicit consideration of risks, more detailed processes

Cons: Cost, difficult to implement, time consuming

Software validation activities:

Unit testing

module testing

sub-system testing

system testing

acceptance testing

what is CASE?

Computer-aided software engineering

Name given to software that is used to suppot software process activities such as requirements engineering, design, program development and testing

It’s tools include:

design editors, compilers, data dictionaries, debuggers, etc. (any toosls you buy outside to help you out)

Why is software management distinct from other engineering managements?

1. Software product is intangbile

2. no standard process

3. large software projects are usually different from previous projects

Risk Management Stages

1. Risk Identification (project, product, business)

2. Risk analysis (likelihood and consequences)

3. risk planning (avoiding, minimizing risks)

4. risk monitoring (constant assessment)

What is “Software Requirements”?
What are 2 the types?

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

1) Functional requirements - describe system services/functions

2) Non-Functional requirements - constraint on the system or on development process (I.e. speed of everything)

What is a requirement?

ranges from high-level abstract statement of a service to a detailed mathematical functional specification

-basis for a bid for a contract (open to interpretation

-basis for contract itself (defined in detail)

Types of requirements

1) User requirements: written for customers

2) System requirements: written as contract b/w client and contractor

3) Software specification: written for developers

Functional Requirements

• services the system should provide

• Can state what the system shouldnt do too

• Should be complete and consistent (avoid ambiguity)

Non-Functional requirements

• requirments not directly concerned with functions delivered by system

• relates to the system as a whole rather than individual functions

• could be deciding factor on survival of a system (reliabilty, cost, reponse time)

Domain Requirements

• derived from application domain of system rather than specific needs of the users

• may be new functional requirements, constrain existing, or set out how computations must take place

• ex: tolerance level of landing gear on an aircraft, or what happens to fiber optics line in case of sever weather during winter Olympics

Problems with natural language:

1. lack of clarity

2. requirements confusion

3. requirements amalgamation (several requirements may be expressed together)

4. ambiguity

5. over-flexibility

Alternatives to natural language specification

• structured natural language

• program description language

• use-cases

• mathematical specification

structured language specifications

• limited form of natural language may b eused to express requirements

• removes some problems like ambiguity and flexibility, and imposes uniformity on specification

• best supported using form-based approach

PDL-Based requirements

• defined operationally using a program. lang. but with more flexibility of expression

• used when

  1. operation is specified as sequence of actions and order is important

  2. hardware and software interfaces have to be specified

• CONS: may not be sufficiently expressive, only understandable to people with PL knowledge, may be taken as a design specification rather than a model

The requirements document

• official statement of what is required of system developers

• includes both a definition and specification of requirements

• NOT a design document. should set WHAT the system should do, rather than HOW

Requirements engineering processes

• processes used to discover, analyze, validate system requirements

• 4 generic activities of RE:

  • Requirements elicitation, analysis, validation, management

Ethnography

• observational technique used to understand social and organizational requirements (*SOCIAL ISSUES*)

• developed in project studying air traffic control process

• CONS: studies existing practices which may have historical basis which may be no longer relevant

Enduring and Volatile Requirements

Enduring: stable requirements from core activity of the customer organization (I.e. hospital will always have doctors, nurses)

Volatile: requirements which change during development or when the system is in use (I.e. health care policy in a hospital)

Classification of requirements

• Mutable Requirements

• Emergent Requirements

• Consequential Requirements

• Compatibility Requirements