307 Final

What is software?

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

Types of software

Applications (video games, spreadsheets, etc.) System (OS, drivers, etc.) Embedded (firmware, microcode) Real Time (control & monitoring, often safety critical)

Types of software development

Custom Generic Embedded

What is software engineering?

IEEE: (1) the application of a systematic, disciplined, quantifiable approach to the development, operation, maintenance of software; that is, the application of engineering to software. (2) the study of approaches as in (1)

Ways in which software engineering differs from other disciplines

Abstract/logical vs. concrete/physical Discrete vs. continuous math Foundations in computer science not natural science No "manufacturing" phase Maintenance = evolution

Ways in which software engineering is similar to other disciplines

Series of decisions Trade-off analysis conducted Work quantitatively Calibrate measurements Use approximations based on experience and empirical data Emphasize disciplined process Multiple roles for engineer Use tools Advance field through professional societies

Ethical categories

Public Client & Employer Product Judgement Management Profession Colleagues Self Responsibility

Public ethic

Software engineers shall act consistently with the public interest

Client & employer ethic

Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest

Product ethic

Software engineers shall ensure that their products and related modifications meet the highest professional standards possible

Judgement ethic

Software engineers shall maintain integrity and independence in their professional judgment

Management ethic

Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance

Profession ethic

Software engineers shall advance the integrity and reputation of the profession consistent with the public interest

Colleagues ethic

Software engineers shall be fair and supportive of their colleagues

Self ethic

Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession

Responsibility ethic

Software engineers must commit themselves to making software engineering a beneficial and respected profession

Stakeholders

Users Customers Developers Managers

Software quality attributes

For product operation For product revision For product transition

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 without failure in the user's environment

Usability (Operation attributes)

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

Revision attributes

Flexibility Maintainability Testability

Flexibility (Operation attributes)

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 (Transition attributes)

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

Software development cycle phases

Requirements phase Design phase Implementation phase Test phase Installation and checkout phase

Software life cycle models

Code and fix Stagewise and waterfall Prototyping Evolutionary Spiral Agile/Scrum

Code and fix model

Code, fix, repeat until resources exhausted

Waterfall model

System engineering System analysis System design Implement the system Test the system Maintain the system

Prototyping model

Determine requirements Build a prototype Do a partial design Evaluate the system Engineer the product

Evolutionary model

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

Determine objectives Evaluate alternatives Develop, verify next-level product Plan next phases (repeat)

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 No sub-teams (testing, etc)

Scrum 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 Quality attributes do not change Scope may be clarified/re-negotiated

Sprint planning

Work to be performed in upcoming sprint is planned Suggested eight hours for a one month sprint

Sprint backlog

Selected product backlog items, along with The Plan Organized by team Estimate time to complete each item Assign tasks to individual members

Daily scrum

Fifteen minutes for team to "synchronize" and plan for the next 24 hours What has been done, what will be, roadblocks Held same time, same place

Sprint review meeting

Development team presents accomplishments Form of a demo of new features or progress Informal

Sprint retrospective

Opportunity to reflect and plan for improvements during the next sprint

Sprint artifacts/documents

Project charter Product backlog Sprint backlog Burn down chart

Project charter

Problem statement: short and succinct (one or two sentences) Project objectives: what the project will achieve Stakeholders: persons who will be actively involved with the project Project sponsor, types of users, etc. Deliverables: major results or services that will be produced

Product backlog

Ordered list of everything that might be needed in the product Product owner is responsible for the backlog Never complete Lists all features, functions, requirements, enhancements, and fixes that need to be made "As a, I want, so that"

Burndown chart

Graphical representation of work left to do vs. time left in which to do it

Domain analysis

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

Types of requirements

Real: functional and performance Constraints: non-functional Possible: non-measurable, subjective, political Probably not: expectations, wishes, desires

Steps to gathering and analyzing requirements

Observation Interviewing Prototype

Greenfield

Completely new project, built from scratch

Brownfield

Project that has previously existed already

User stories

Short, simple descriptions of a feature told from the perspective of the person who wants the feature "As a ... I want"

Use case

A typical sequence of actions that a user performs to complete a given task 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

Use Case Diagrams Extensions

Make optional interactions explicit Handle exceptional cases Think "hardware interrupt"

Use Case Diagrams Generalizations

Represents several similar use cases Similar to superclasses in a class diagram

Use Case Diagrams 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

Steps to managing requirements

Review them Track them Verify them Control the changes to them

Requirement review considerations

Benefits Important Unambiguous Consistent Quality Realistic Verifiable Identifiable

Cons to reusability

Takes extra time Sometimes only reward visibility Costs money

Pros to reusability

Prevents taking shortcuts Should be part of the culture

Framework

Reusable software that implements a generic solution to a generalized problem

Framework slots

Certain classes or methods are missing

Framework hooks

Optional functionality, allowance made for developer to provide it

Product line

Set of products built on a common technology base

Distributed system

System of discrete networked components Have concurrency Lack a global clock Can encounter independent failure of components

Server

Program that provides a service for other programs

Client

Program that accesses one or more servers to obtain services

Communication channel

Generally a computer network Client must initially know the server, but not vice versa

Basic client-server sequence

Create socket Bind socket to address Listen for clients Client creates a socket Client attempts to connect to server Server accepts connection Read and write (send and receive data)

Advantages of client-server

Work is distributed Client can access server from distance Client and server can be designed separately Data stored centrally at server

Thin-client

Client is as small as possible Most work done on server

Fat-client

As much work as possible delegated to clients Server handles more clients

UML

A "general purpose" modeling language Provides a standardized method for designing a system

Types of UML diagrams (and static/dynamic)

Class diagrams (static) Composite structure diagrams (static) Sequence diagrams (dynamic) Activity diagrams (dynamic) State machine diagrams (dynamic)

Class diagram

Describes system attributes, operations, relationships among objects

Composite structure diagram

Shows internal structure of a class Parts: runtime role of a classifier (e.g., class) or a collection of instances Port: connects classifiers with their parts and environment Connector: binds two or more entities together

Activity diagrams

Graphical workflow showing stepwise activity and actions Similar to a state diagram except most transitions caused by internal events Can represent concurrency Visualize interrelation and interaction between different use cases

Association

Shows how two classes relate to each other

Multiplicity (*, #, ..)

Many, Number, Or

Generalization

Labeled group with a common superclass

Discriminator

Describes the criteria used for specializing/generalizing

System domain model

Models aspects of domain represented by the system Omits many classes needed for a complete system

System model

Includes classes for UI and system architecture Includes system domain model Architectural classes Utility classes

Design patterns

Recurring aspects of designs Context: the general situation in which the pattern applies Problem: short description of the main difficulty tackled Forces: issues or concerns to consider when solving the problem Solution: recommended way to solve the problem

Sequence diagrams

Shows the sequence of messages exchanged by a set of objects performing a specific task Actor on left Messages are arrows between sender and receiver Lifeline attached to each object/actor

State diagram

Describe the behavior of a system, part of a system, or an individual object

Fork

One incoming transition, multiple outgoing transitions

Join

Multiple incoming transitions, one outgoing transition

Rendezvous

Multiple incoming and multiple outgoing transitions

Swimlanes

Partition activities among classes

Developer quality issues

Testable Maintainable Enhanceable Correct Robust Reliable Installable Liability Manufacturable Marketable

User quality issues

Affordable Valuable Correct Usable Learnable Robust Safety Security Serviceable Tailorable