CS 307 Final

Software

Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system

Nature of Software

Software is intangible

Software is easily reproducible

Software development is labor-intensive

Untrained people can hack something together

Software is easy to modify

Software does not wear out

Types of software

Applications → Business, CAD, databases, spreadsheets, simulations, video games, word processors

\
System → OS, Device drivers, Privileged utilities

\
Embedded → Firmware, microcode

\
Real time → control and monitoring, must react within some delta T, often safety critical

\

Development

Custom

\
Generic

\
Embedded

Software Engineering

1. The application of a systematic, disciplined, quantifiable approach to the development, operation, maintenance of software; that is, the application of engineering to software.


1. The study of approaches in 1)

\
Coined in 1968

Solving problems

Within constraints:

Cost

Time

Customer

Others

Solutions

Require effective communication

Sometimes one can Assemble from existing components or buy

Software engineering vs other engineering

Discrete rather than continuous math

Abstract/logical entities vs concrete/physical artifacts

No manufacturing phase

Maintenance refers to continued development, or evolution

\
Commonalities:

“Engineered”

Disciplined process

Can have multiple roles in development

\

Ethics

A theory or system of moral values

Principles of conduct governing an individual or group

ACM Ethics

Section 1: Fundamental ethical principles

Section 2: More specific considerations of professional responsibility

Section 3: Leadership

Section 4: Principles for compliance

General ethical principles

Contribute to society and to human well being, acknowledging that all people are stakeholders in computing

Avoid harm

Be honest and trustworthy

Be fair and take action not to discriminate

Respect the work required to produce new ideas, inventions, creative works, and computing artifacts

Respect privacy

Honor confidentiality

Professional Responsibilities

Strive to achieve high quality in both the processes and products of professional work

Maintain high standards of professional competence, conduct, and ethical practice

Know and respect existing rules pertaining to professional work

Accept and provide appropriate professional review

Give comprehensive and thorough evaluations of computer systems and their impacts, including analysis of possible risks

Perform work only in areas of competence

Foster public awareness and understanding of computing, related technologies, and their consequences

Access computing and communication resources only when authorized or when compelled by the public good

Design and implement systems that are robustly and usably secure

\

Professional leadership principles

Ensure that the public good is the central concern during all professional computing work

Articulate, encourage acceptance of, and evaluate fulfillment of social responsibilities by members of the organization or group

Manage personnel and resources to enhance the quality of working life

Articulate, apply and support policies and processes that reflect the principles of the Code

Create opportunities for members of the organization or group to grow as professionals

Use care when modifying or retiring systems

Recognize and take special care of systems that become integrated into the infrastructure of society

\

Compliance with the code

Uphold, promote, and respect the principles of the Code

Treat violations of the Code as inconsistent with membership in the ACM

Stakeholders

\

Users

Customers (Project owners)

Software developers

Development managers

\

Quality

Conformance to requirements

Fitness for use

I know it when I see it

Value to someone

Operation attributes

Correctness

Efficiency

Integrity

Reliability

Usability

Correctness

The degree to which a program satisfies the user’s requirements

\

Efficiency

The amount of computing resources, time and space, required to perform a user-defined function or task

Integrity

How well is the software and data protected from security breaches and installation errors?

Reliability

To what degree can the system be expected to perform its intended function to perform its intended function without failure in the user’s environment?

Usability

How much effort do the users have to spend learning to use the system efficiently

Revision attributes

Flexibility

Maintainability

Testability

Flexibility

How much effort will be required to enhance the system?

Maintainability

How much effort will be required to locate and repair defects in the system?

Testability

How much effort will be required to test the structure and functionality of the system?

Transition attributes

Interoperability

Portability

Reusability

Interoperability

How much effort will be required to link this program or system to another?

Portability

How much effort will it take to transfer a program or system from one machine to another?

Reusability

To what extent can the design, or system modules be used in other applications. How much effort will it take to reuse them?

Tension

Software qualities conflict

Increased integrity may impact efficiency…

Software development cycle

Begins with decision to develop software product

Ends when the software is delivered

Typically includes:


1. Requirements phase
2. Design phase
3. Implementation phase
4. Test phase
5. Installation and checkout phase

Software life cycle

Software development cycle and:


1. Operation and maintenance phase
2. Retirement phase

Code and fix model

Code a little

Fix a lot

Repeat until your time, money, people, and customers run out

Waterfall model

Difficult to measure real progress

Good for real time system critical

Not very efficient

System engineering

Business considerations

Technical considerations

Manufacturing considerations

People

Environmental considerations

Legal considerations

Develop an installation plan

System analysis

The what part

Identify the real system requirements

Hopefully work with and involve the user

Develop an acceptance test plan

System design

The how part

Identify the hardware and software system specifications

Develop the system integration test plan

System implementation

Build the system

Test the parts

Carefully complete all system documentation

System test

Carry out system integration test plan

Carry out the acceptance test plan

Carry out system installation plan

Establish system regression test library

System maintenance

Manage change

Fix defects

Port the system

Enhance the system

Retire the system

Prototyping

Done when user is not very computer literate

When the user is unable to completely pre-specify the needed system requirements

When there is little algorithmic detail

Whenever you are not sure your design will work

Evolutionary development models

Can become a modern version of code and fix

Product evolves over time as the real requirements become known

Assumes the customers will tell us what they like and dislike about each incremental release

Spiral model

Incremental, risk oriented

Four main phases:

Pros:


1. Reduces risk of failure
2. Functionality can be added later
3. Software produced early
4. Early feedback

Cons:


1. Risk analysis requires expertise
2. Complex

Scrum

Roles:

Product owner

Scrum master

Development team

Product owner

Defines the features of the product

Decides on release date and content

Prioritizes features

Adjusts features and priority every iteration, as needed

Accepts or rejects work results

Scrum master

Represents management to the project

Responsible for ensuring adherence to scrum practices

Removes impediments

Ensures that the team is fully functional

Shields team from external interference

Development team

Members are assumed cross-functional

Not always possible

Only title for members is developer

No sub-teams

Optimal size 3 to 9 members

Events

Sprint

Sprint planning

Daily scrum

Sprint review

Sprint retrospective

Sprint

Usually one month or less

Done usable, and potentially releasable product increment is created

New sprint starts immediately after previous ends

No changes are made that impact goals

Team composition remains constant

Quality attributes do not change

Scope may be clarified/renegotiated

Sprint planning meeting

Work to be performed in upcoming spring planned

Suggested eight hours for a one-month sprint

Two parts:


1. What will be delivered?
2. How will the work get done?

\

Deliverables

Product owner presents a list of items to complete

Team develops a sprint goal:


1. Product backlog
2. Latest product increment
3. Capacity of the team
4. Past performance

\

Burn down chart

Greenfield

From scratch

Brownfield

Must work with existing systems

Domain analysis

Process by which software engineer learns about the domain to better understand the problem


1. The domain is the general field of business or technology in which the software will be used
2. A domain expert is a person who has deep knowledge of the domain

Benefits


1. Faster development
2. Better system
3. Easier to anticipate future modifications

Domain analysis

Defining the problem

Collect the requirements → real, possible, constraints, probably not

\

Collecting and analyzing requirements

Observation

Interviewing

Prototype

Comments on domain analysis

If you can change it, it’s system

If you can influence it, it’s the border

If you cannot change it, rest of the world

Organize and prioritize

Must have and can be met?

Must have but not sure can be met? → buy info, build prototypes

Nice to have?

Gold plating

Generate the requirements

List the requirements indicating priority

Establish requirement tracking procedure

Establish a requirements verification plan

User story

Short, simple descriptions of a feature told from the perspective of the person who wants the feature

Use cases are expansion of user story

Choosing user stories:


1. Often one user story can be identified as central to system'
2. Other reasons to focus on particular user stories:


1. May represent high risk
2. May have high political or commercial value

Help define scope of system

Be used to plan development process

Used to develop and validate requirements

Form the basis for test cases

Help structure user documentation

Use case analysis

A use case is a typical sequence of actions that a user performs to complete a given task

Use case model


1. Set of use cases
2. Optional description or diagram indicating how they are related

\

Use Case

Cover the full sequence of steps from beginning to end

Describe the user’s interaction with the system

As independent as possible from the UI design

Only include actions arising from actor interacting with system

\

Use case diagrams

Use case → horizontal ellipse

Actor

Associations

Extensions

Make optional interactions explicit

Handle exceptional cases

Keeps basic use case simple

Think “hardware interrupt”

Generalizations

Similar to superclasses in a class diagram

Represents several similar use cases

One or more specializations provides details of the similar use cases

\

Inclusions

Allow one to express commonality between several use cases

Included in other use cases

Represent the performing of a lower level task with a lower level goal

Reviewing requirements

Each requirement should:


1. Have benefits that outweigh the costs
2. Be important for the solution
3. Be unambiguous
4. Be logically consistent
5. Lead to a quality system
6. Be realistic
7. Be verifiable
8. Be uniquely identifiable
9. Not over-constrain the design of the system

\

Problems

Unknown - missing requirements

Incomplete requirements

Ambiguous requirements

Non-requirements

Product questions

What is the skill level of the user?

What environment is this product likely to encounter?

What are the performance and resource constraints?

What are the safety and security needs?

Building on the experience of others

Software engineers should avoid redeveloping software

Reusability and reuse

Reuse and design for reusability should be part of the culture of software development organizations

Software is often created without enough attention to quality or reuse

Vicious cycle

Developers take shortcuts to save time, sacrificing quality and reusability

Important to recognize that:


1. This cycle costs money
2. Investing in reusable code is important
3. Attention to quality is essential


1. Employing reusable components often simplifies design

Frameworks

A framework is reusable software that implements a generic solution to a generalized problem

Based on the principle that applications that do related things tend to have similar designs

Frameworks promote reuse

Intrinsically incomplete

Developers use the services that the framework provides → API

Object-oriented frameworks

Framework is composed of a library of classes


1. API is defined by the set of all public methods
2. Some classes intentionally abstract

\

Product line

A product line is a set of products built on a common technology base

Distributed system

A distributed system is a system of discrete networked components


1. Have concurrency
2. Lack a global clock
3. Can encounter independent failure of components
4. Coordinate by passing messages

Components cooperate to create a system

Client-server architecture

One kind of a distributed application or system

Server

Client

Communication channel

Server

\

Client

Thin vs. fat client

Thin


1. Client is small as possible
2. Most work done on server
3. Client easy to download

Fat


1. As much work as possible delegated to clients


1. Server can handle more clients

Protocols

To communicate what programming languages are to computation

Server and client are programmed to understand the protocol

Object client-server framework

UML

A general purpose modeling language

Has detailed semantics

Has extension mechanisms

Has an associated textual language

Not a methodology

A good model

Uses standard notation

Is understandable by all stakeholders

Helps software engineers gain insight into the system

Provides abstraction

Diagram essentials

Classes

Associations

Attributes

Operations

Generalizations

Diagrams

Static view → class diagrams

Dynamic view → sequence diagrams

Class diagrams

System’s classes

Composite structure diagrams

Shows internal structure of a class

Parts: runtime role of a classifier or a collection of instances

Port: connects classifiers with their parts and environment

Connector: binds two or more entities together

Sequence diagrams

Associations and multiplicity

Association → shows how two classes relate to each other

Symbols indicating multiplicity are shown at each end of the association

Many to one

A company has many employees

Many to many

An assistant can work for many managers

A manager can have many assistants

One to one

For a given company, exactly one board of directors

Avoid unnecessary one to one associations

Association classes

When an attribute concerning two classes cannot be placed in either

Reflexive associations

An association can connect a class to itself

Generalization

A generalization set is a labeled group of generalizations with a common superclass

System domain model vs system model

System domain model omits many classes needed for a complete system

Complete system model includes


1. System domain model
2. UI classes
3. Architectural classes
4. Utility classes

\