CSE 3310 SWE Exam 1

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

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

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

1. Coping with legacy systems

2. Coping with increasing diversity

   1. Coping with faster and cheaper

50% engineering, 30% science, 20% art

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

1. Software specification

2. Software development

3. Software validation

   1. Software evolution

A representation of software process from a specific perspective

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.

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

Maintainability

Dependability

Efficiency

Usability

Confidentiality

Competence

Intellectual property rights

Computer misuse

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

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

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

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

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

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

Unit testing

module testing

sub-system testing

system testing

acceptance testing

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)

1. Software product is intangbile

2. no standard process

3. large software projects are usually different from previous projects

1. Risk Identification (project, product, business)

2. Risk analysis (likelihood and consequences)

3. risk planning (avoiding, minimizing risks)

4. risk monitoring (constant assessment)

-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)

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)

1) User requirements: written for customers

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

3) Software specification: written for developers

• services the system should provide

• Can state what the system shouldnt do too

• Should be complete and consistent (avoid ambiguity)

• 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)

• 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

1. lack of clarity

2. requirements confusion

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

4. ambiguity

5. over-flexibility

• structured natural language

• program description language

• use-cases

• mathematical specification

• 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

• 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

• 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

• processes used to discover, analyze, validate system requirements

• 4 generic activities of RE:

  • Requirements elicitation, analysis, validation, management

• 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: 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)

• Mutable Requirements

• Emergent Requirements

• Consequential Requirements

• Compatibility Requirements