CSCI 310 Midterm

Software Engineering Failures

​ Ariane 5 Rocket - overflow caused rocket to explode

Mars Climate Orbitor - did not use metric units so orbitor crashed

Therac 25 - gave 100x radiation due to lack of testing and user interface

World War III - soviet early warning system registered sun off of clouds as nukes

Hartford Coliseum Collapse - wet snow caused roof to collapse since there was an error in domain knowledge by the cad software

Patriot Fails - gulf war missle interception system had a rounding error that caused the missiles to be too slow and a barracks blew up

Disastrous Study - The New England Journal of Medicine reported increased suicide rates after severe natural disasters but were false since error doubled the suicides for one year

y2k - computer systems only used 2 numbers for date which would cause issues in 2000 cost billions

healthcare.gov - did not test with lots of users so only 1% of people could sign up

Challenges in Software Design

Scale: Larger = harder

Complexity: lots of APIs, web services

Uniqueness: no software is the same

Culture: requires a lot of planing of complex systems and maitnence

Speed: software expected to be faster which is hard

Legacy software: understanding and using past software

Changeability software must be flexible

Systematic

done according to a plan

diciplined

controlled behavior

Quatifiable

measuring how productive engineers are

development

creating software

Operation

creating good user interfaces

matenience

knowing how to fix bugs, update software, etc.

Software project

something that uses software development processes

Product

output of a software project

Waterfall lifecycle

​Requirements (RE)

Planning

Design

Implementation

Testing

Maintenance

Distribution of effort

Matenice 60%

Of the rest 40%

- Testing = 45%

- Implementation = 20%

- Design = 15%

- Requirements = 10%

- Specification = 10%

Functional Requirment

what the system should do/ how it should behave

Non-functional Requirement

how the system should preform

Product - Efficiency, Reliability, Portability, Usability

Organizational - Delivery, Implementation, Standards

​External - ​Interoperability, Ethical, Legislative

Software Requirement

A property that must be exhibited by some aspect of the system

Challenges with RE

Change - Requirements can change over time

Different words - language can be interpreted differently

Accuracy - hard to be accurate and avoid requirement conflicts

Assumptions - thinking something is obvious to everyone when it is not

RE Process

Elicitation - understanding the problem

Specification - describing the solution

Negotiation - agreeing upon the boundaries of the problem

Validation - agreeing on the nature of the problem

Elicitation

Interviews

Scenarios

Specification

writing the SRS

Use: Structured english, regular expressions, discussions tables, finite state automata, formal methods

Negotiation

​Feasibility studies

MoSCoW

Validation

Reviews, prototyping, test-case generation, ​

Automated consistency analysis, ​

Stakeholder verification

Good Requirement

Correct - does the right thing

Complete - cover all aspects of the requirement

Unambiguous - cannot be interpreted multiple ways

Verifiable - can write a test for it

consistent - does not contradict another requirement

Ranked - which requirement is more important

Modifiable - use variable in place of number

Traceable - ​Be able to show that a requirement is satisfied/ use unique ID

​Management of requirements change

Define process of change, define levels of change, communicate with stakeholders

Primary PMP Activities

Process Planning

Determine Deliverables

Estimate Costs

Scheduling

Resource Allocation

Risk Management

Quality Management

Configuration management​

Termination analysis

Metircs

​Quantifiable measures of characteristics of system or process

​Measurement

​Process of obtaining value for metrics (Direct/Indirect)

Modeling

Mechanism for estimating the metrics and measurements

Useful with metrics with no way to model

Effort Formulation

​Effort(person months) = A * (Size)^B * PI(i=1 -> # of cost drivers)[EM_i]

A: constant derived from historical project data

Size: KSLOC (thousand sources lines of code)

B: constant dependent on diseconomy of scale (5 scale drivers)

EM_i: the effort multiplier for the ith cost driver

​Schedule formulation

​

Schedule(months) = C (Effort)^(.33+.2(B-1.01)) x SCED%100

Schedule: calendar time in months from the requirements baseline to acceptance

C: constant derived from historical project data, 3.67

Effort: estimate person months excluding SCED effort multiplier

B: sum of project scale factors

SCED: compression/expansion percentage in the SCED cost drive

Cost Factors

Significant factors of cost development

Scale Drivers

​Sources of exponential effort variation

​Precedentedness (PREC): Degree to which system is new and past experience applies

Development Flexibility (FLEX): Need to conform with specified requirements

Architecture/Risk Resolution (RESL): Degree of design thoroughness and risk elimination

Team Cohesion (TEAM): Need to synchronize stakeholders and minimize conflict

Process Maturity (PMAT): SEI CMM process maturity rating

Cost Drivers

Sources of linear effort variation

Product Factors

Platform Factors

Personnel Factors

Project Factors

Product Factors

​Reliability (RELY): measures extent to which software must preform its intended function over time

Ask: what is the effect of a software failure?

Data (DATA): captures effect large data requirements have on development to generate test data that will be used to excersize the program

Complexity (CPLX): measures complexity of operations (control, computational, device-dependent, data, UI) done with the system

Reusability (RUSE): accounts for additional effort needed to construct component for reuse

Documentation (DOCU): what is the sustainability of the project's documentation to its lifecycle needs

Platform Factors

​Time constraint (TIME): percentage of available execution time expected to be used by the system

Storage constraint (STOR): percentage of available storage space expected to be used by the system

Platform volatility (PVOL): assesses the volatility of the platform (how ofter the software/hardware will have to change)

Personnel Factors

​Analyst capability (ACAP): analysts work on RE, high level design, and detailed design

Consider analysis and design ability, efficiency and thoroughness, and the ability to communicate and cooperate.

Programmer capability (PCAP): evaluation of programmers as a team

Consider ability, efficiency and thoroughness, and the ability to communicate and cooperate.

Applications experience (APEX): assess the team's equivalent level of experience with this type of application

Platform experience (PLEX): asses the team's equivalent level of experience with this platform including:

The OS, GUI, networking, database, and distributed malware

Language and tool experience (LTEX): measure the level of programming language and software tool experience of the team

Personnel continuity (PCON): measures the projects annual personnel turnover

Project Factors

​Software tools (TOOL): assesses the usage of software tools to develop the project in terms of capabilities and maturities

Multisite development (SITE): assesses and average two factors

Site collation: measures how close in proximity the company/product is contained

Communication support: measures complexity of communication network

Required schedule (SCED): measures the imposed schedule constraint in terms of the percentage of schedule stretch-out or acceleration with respect to nominal

Design Process

Feasibility Stage - Identify a set of feasible design concepts

Preliminary Design Stage - Selection and development of best design concept

Detailed design stage - development ad engineering descriptions of the concept

Planning stage - evaluating and altering concept to suit requirement of production

Different Methodlogies

Data Flow

Functional (de)composition

Object oriented

Data Flow

Structured analysis (SA): Logical design drawn as a set of data flow diagrams

Structured design (SD): transforming logical design into a program structure drawn as a set of structure charts

Functional (de)composition

Bottom-up or top-down

not used because clients do not know what they want

design has a yo-yo character

Object Oriented

Identify objects

Determine their attributes and service

Determine relationship between objects

What make a good design?

High cohesion, low coupling, information hiding, abstraction, simple complexity

View

representation of one or more aspects of an architecture that illustrates how the architecture addresses the concern held be one or more of the stakeholders

Viewpoint

collection of patterns, templates, and conventions for constructing one type of view

Logical View

Functionality that the system provides to the end user

Physical view

depicts system from an engineer's point of view (hardware)

Deployment View

system from programmer's point of view (combo of physical and logical)

Concurrency view

depicts parts of that system that can execute concurrently and those that execute serially

Entity

Distinguishable object of some typw

Entity type

category of entities (represented by box with entity inside)

Attribute value

piece of information describing an entity

Attribute

category of attibributes values (represented by oval with attribute value inside)

Relationship

association between 2 or more entities

State

set of attributes of an object (circle)

Class

set of objects of with the same attributes

Individual object

instance

behavior

set of resposiblities

service

invoked by sending a message

is-a

expressed in hierachy

whole-part, has

aggregation of parts into a whole

member-of, has

relationship between a set and its members

static diagrams

show static structure

Ex: class

Dynamic diagrams

shows execution of the program

Ex: State machine, Sequence, Communication, Use case

State machine

represents FSMs

Allows for local variables to states

Has external inputs/outputs

Hierarchical states

Sequence diagram

emphasizes orderings of events using a lifeline

Communication diagram

emphasizes orderings ordering of events using a lifeline

Use case

represents possible ways a user will interact with the system

shows high level activities organized by goals

Implementation goal

not to reduce implantation costs, but to reduce costs of later phases, easier for tester and maintainer

Readability

Most important thing

Naming conventions, information hiding, user defined types, reduce nesting, side effects, module size, number of paths

Naming coventions

consistent, useful names

Information hiding

makes code much easier to read

User defined types

in place of multiple complex data sturcutes

Nesting

can make things complex so be careful

side effects

code may have unexpected behavior

module size

easy to go overboard (cohesion) does not enhance readability

How to measure complexity

Cyclomatic complexity = number of pathes

Computes by E-n+2p (e = edges, n=nodes, p=connected components

Number of predicates +1 for structured programs

Max CC = 10

Verification

are we building the right system?

Test input

data passed into application

expected output

anticipate seeing some kind of output

test suite

multiple test cases

failure

symptom: expectaion message, no images found text

things that you see

faulr

reason for faliure

error

reason for fault

coincidental correctness

faults don't imply falure

goals of software testing

improve software quality by finding errors

providing confidence in the dependability of the software project

Testing process

1. When do we stop testing

2. test selection/prioritization

3. Test input generation

4. Check output of tests

5. Thoroughness of testing

When do we stop testing?

Satisfy the testing criterion

rate of finding faults decreases to an acceptable level

run out of resources

determine cost is not worth it

test selection/proritization

selecting the subset of inputs to use

we want an S that gives test suites that guarantee correctness but we settle fo an S that gives test suites that improve

Test input generation

given a testing requirement R, how do we generate test inputs to satisfy R

Check output of test

An oracle provides the expected reults of a test is succesfull or not

Human = tediuoes, error prone

Autmated = expensive

Thoroughness of testing

Adequacy score of a test suite is the percentage of coverable items that are covered by the test suite

Black box

testing specifically based on SRS

Testing based on how you write your SRS

Scales well

Cannot reveal error that depend on impentaion

White box

Based on the code, not based on the SRS requirements

Focuses on branches, loops, etc

does not scale, test cases increase exponential

cannot reveal errors due to unimplemented functionality