Cs 594 software engineering
Download
1 / 60

Class 1-24-2000 - PowerPoint PPT Presentation


  • 266 Views
  • Uploaded on

CS 594 Software Engineering Lecture 1 - 1/24/2000 Dr. Thomas E. Potok [email protected] 865-574-0834 Agenda Class introduction Why study software engineering History Evolving structure Requirements Who are you? Setup Volunteer?? Class Overview Course Description

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Class 1-24-2000' - JasminFlorian


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Cs 594 software engineering l.jpg

CS 594Software Engineering

Lecture 1 - 1/24/2000

Dr. Thomas E. Potok

[email protected]

865-574-0834

T. E. Potok - University of Tennessee


Agenda l.jpg
Agenda

  • Class introduction

  • Why study software engineering

  • History

  • Evolving structure

  • Requirements

T. E. Potok - University of Tennessee


Who are you l.jpg
Who are you?

Setup Volunteer??

T. E. Potok - University of Tennessee


Class overview l.jpg

Class Overview

T. E. Potok - University of Tennessee


Course description l.jpg
Course Description

  • Overview of practical and theoretical software engineering techniques and approaches

  • 2 Small Projects

    • Class formed into groups

    • Define requirements, design, prototype code

    • Simulate industrial software development

    • 1/2 hour of each class on project

  • Texts:

    • R. S. Pressman, Software Engineering: A Practitioner’s Approach, Fourth Edition, McGraw-Hill, 1997

    • R. L. Glass, Software Runaways, Prentice Hall, 1998.

    • Assigned papers

T. E. Potok - University of Tennessee


Course overview l.jpg
Course overview

  • Requirements Gathering and Analysis (1 week)

  • Project size estimation (3 weeks)

  • Planning (5 weeks)

  • Team interaction (2 weeks)

  • Methodology (3 weeks)

  • Runaway Projects (2 weeks)

T. E. Potok - University of Tennessee


Tests and grading l.jpg
Tests and Grading

  • Tests and Grading

    • Mid-term exam 30%

    • Final exam 30%

    • Homework (including projects) 40%

    • Last year roughly 30% of the class made an A, the rest received a B.

  • Office Hours

    • 1 hour before/after class by appointment

    • Email or phone calls are fine

T. E. Potok - University of Tennessee


Class format l.jpg
Class format

  • Professional conduct

    • Class starts and ends on time

    • Contact me if you are going to miss a class

    • I will most likely miss one or two classes

  • Schedule

    • 50 Minutes lecture - 10 Minute break

    • 50 Minute lecture - 10 Minute break

    • 10 minute Summary

    • 30 minutes project time

  • Guest

    • There will be several guests in the class, I expect them to be treated with the utmost respect

T. E. Potok - University of Tennessee


Projects l.jpg
Projects

  • The class will develop components of software to meet the needs of two real customers with hypothetical problems

    • Using the techniques learned in class

    • Working in groups

    • Simulating a realistic software development environment

T. E. Potok - University of Tennessee


Why study software engineering l.jpg

Why Study Software Engineering?

T. E. Potok - University of Tennessee


Why study software development l.jpg
Why study software development?

  • Just hire the best people you can, and let them go

  • Look at any successful project, and you will find that one key person who was willing to do what ever it takes to succeed.

  • You can document processes and techniques all day long, no one ever follows them.

  • “Software development is more of an art form than engineering”.

T. E. Potok - University of Tennessee


Have programmers gotten better l.jpg
Have programmers gotten better?

  • Do you think that the value added to a corporation by the typical software engineer has increased in the last 20 years?

  • If so, by how much?

  • Abdel-Hamid notes spending on application development tools has increased at a 19 percent annual growth rate or higher,

  • However, looking at the value that was added per software developer adjusted for inflation, shows no improvement in the past two decades [Abdel-Hamid (1996)].

T. E. Potok - University of Tennessee


Productivity crunch l.jpg
Productivity Crunch

  • 70’s 3-5 year development cycles

  • 80’s 2-3 year development cycles

  • 90’s 12-18 months

    • 6 week feasibility studies are common

    • “Web year” 3 months

    • My two most recent software research projects were 4 months, and 9 months in duration

T. E. Potok - University of Tennessee


High stakes development l.jpg
High Stakes Development

  • IRS - Computerworld: IRS wastes $50 billion per year resulting from repeated failures to integrate its "stovepipe" computer systems.

  • Denver baggage claim system 16 months late, 2 Billion dollars over budget

  • Air traffic control...

T. E. Potok - University of Tennessee


There has got to be a better way l.jpg
There has got to be a better way

  • Technology - Better tools and languages

  • Methodology - Structured analysis, Object-oriented, agent-oriented,...

  • People - Better trained, better paid (???)

  • Process - CMM, ISO 9000

  • Better management - Focus on deliverables, not people

T. E. Potok - University of Tennessee


What is software development l.jpg
What is software development?

  • Engineering?

  • Art?

  • Craft?

  • Science?

T. E. Potok - University of Tennessee


Software development l.jpg
Software Development

  • Art

    • For entertainment and enjoyment

    • Can make a statement

    • Creator extremely significant

    • One of a kind, unrepeatable

  • Engineering

    • Based on scientific foundation

    • Can be very creative and innovative

    • Process followed is significant (patents)

    • A repeatable process can be define, followed, and standardized

T. E. Potok - University of Tennessee


Software development18 l.jpg
Software Development

  • Craft

    • Mainly for function

    • Artistic features

    • Craftsman important

    • Elements are repeatable

  • Science

    • Mainly for discovery

    • Based on time honored method

    • Scientists reputation is very important

    • Discovery needs to be reproduced

T. E. Potok - University of Tennessee


Why most software is not art l.jpg
Why most software is not art

  • Think of two outstanding programmers, and two great artists, Picaso and Monet.

    • The programmers can both produce software to solve a problem, and it will not be obvious who wrote what.

    • The artists can paint a vase, it is clear who painted what

  • A program that works better than others will replace the competition. Obsolete software is useless.

  • A Picaso and a Monet are not replaceable. They gain value over time.

  • A group of skilled programmers can duplicate any software currently on the market given time and money

  • A skilled artist can duplicate a Picaso, or a Monet, to fool most experts, but it has little value.

T. E. Potok - University of Tennessee


Software as craft l.jpg
Software as craft

  • Similar to art, craft work is distinctive based on the talent of the craftsman

  • Handmade work is more valuable than machine made work

  • With software it is hard to tell who wrote what, or whether the code was hand crafted, or machine generated.

  • Are you interested in the credentials of the people who write the software you use?

T. E. Potok - University of Tennessee


Computer science l.jpg
Computer “Science”

  • Scientist are interested in problems that have not been solved

  • They show a solution to a problem which is often little more than a prototype

  • Most software solves a problems that have been solved many times before

  • Software that is not industrial strength is of little value

T. E. Potok - University of Tennessee


So software development is engineering l.jpg
So Software Development is Engineering

  • What science underlies software development?

    • Mathematics?

  • Is standardization in progress?

    • Windows, HTML, Java…

  • Programmers seem more influenced by style than convention

T. E. Potok - University of Tennessee


So who cares l.jpg
So who cares?

  • If software is art

    • The artist’s creatively is the key to producing software

  • If a craft

    • Learning is done through apprenticeships

    • Ability is more important than education

  • If software in engineering

    • There is a process to it that can be

      • Repeated, and can be

      • Improved over time

T. E. Potok - University of Tennessee


Brief history of software engineering l.jpg
Brief History of Software Engineering

  • Nato conference in 1968

    • Software should follow an engineering paradigm

  • Brook’s Mythical Man Month

    • Experiences from the development of the IBM 360 operating system

    • Brook’s law

T. E. Potok - University of Tennessee


The 60 s l.jpg
The 60’s

  • Remember ‘2001 a Space Odyssey’? One large intelligent computer running a spaceship...

  • In the 60’s and 70’s software was written to solve some very basic problems, such as how to tell the computer to manage it’s own resources.

  • The trick in those days was to actually get the software working.

  • Computer time was scarce and the computers themselves were quite limited, however, there seemed to be no bounds on what a computer could do.

T. E. Potok - University of Tennessee


Programming in the 70 s l.jpg
Programming in the 70’s

  • Shift from mainframe computers to mini-computers.

  • A change in understanding what computer can really do.

    • The hardware gets faster, smaller, and cheaper, while the software becomes more complicated with less promise.

  • Software was written by elite, well trained, well paid programmers who worked for industry.

  • The most expensive part of developing software was now the programmer’s time, not the computer time.

  • Customers of this software were elated if you ignored only 90% of their requirements, and were a mere 6 months late

T. E. Potok - University of Tennessee


Programming in the 80 s l.jpg
Programming in the 80’s

  • The start of the personal computer revolution, PC on desk tops, and even in homes.

  • A college dropout could work in his garage with a clone PC developing and sell software.

  • Virtually anybody with a home computer could develop software in his or her garage or carport and sell it on the open market.

  • The trick was no longer merely to get it working, but now to make it useful and useable.

  • Software was now sold in stores for the average user.

T. E. Potok - University of Tennessee


Programming in the 90s l.jpg
Programming in the 90s

  • Large and small powerful computers connected throughout the world that can communicate with each other.

  • Develop software faster, with more function, and cheaper than the competition.

  • Like in the old garage computing days, anyone can develop a software package, but now, they can do it anywhere in the world.

  • However,

    • there are not as many interesting problems to solve anymore.

    • Either they have been solved many times over, or no one can figure out how to solve them.

T. E. Potok - University of Tennessee


Summary l.jpg
Summary

  • The software development environment has changed quite a bit over the past 30 years.

  • Lessons learned in the 60’s and 70’s may be irrelevant to current software development, or they may be fundamental principles of creating software.

  • Without a yardstick to measure the results of such concepts, it is merely one opinion against another.

T. E. Potok - University of Tennessee


Software process improvement l.jpg

Software Process Improvement

T. E. Potok - University of Tennessee


History l.jpg
History

  • Deming is legendary for advising the Japanese to focus on process to revolutionize their post-war manufacturing.

  • Japanese products out performed American products mainly due to quality and ability to meet customer needs

  • This approach was adopted by a variety of industries, and was seen as a way to revolutionize software development as well.

  • You define how you do something (a process),

    • Next, you repeat this process for every project that you develop

    • Then you measure and analyze the process,

    • Finally make any improvements necessary.

  • This should eventually improve the quality of the software produced and increasing the productivity of your programming teams.

T. E. Potok - University of Tennessee


Why process l.jpg
Why Process?

  • Management wants a forecast of how many widgets will be produced

  • How can this be accurately done without:

    • Knowing the steps required to make a widget

    • The machine capacity needed

    • The skills needed

    • The material needed

  • It can not be, therefore any forecast is little more than a random number

T. E. Potok - University of Tennessee


Maximize output l.jpg
Maximize output?

  • Once a process is understood, then what

    • Maximize process output? No

    • Maximize process consistency!

  • Is is better to consistently produce a widget in 8-16 days, or 5-20 days.

  • This consistency provides for greater control over the process.

T. E. Potok - University of Tennessee


Variance reduction l.jpg
Variance Reduction

What curve do you want your team to follow?

T. E. Potok - University of Tennessee


Sei capability maturity matrix l.jpg
SEI Capability Maturity Matrix

  • Broadly agree to define how a software organization matures and improves

  • Based on manufacturing process improvement and “best practices” from software engineering

  • Some dramatic successes...

T. E. Potok - University of Tennessee


Capability maturity matrix l.jpg
Capability Maturity Matrix

  • Developed by the Software Engineering Institute (SEI) by Watts Humphry and Mark Paulk.

  • Five levels of maturity for an organization

    • Level 1 - Initial;

    • Level 2 - Repeatable;

    • Level 3 - Defined;

    • Level 4 - Managed;

    • Level 5 - Optimizing.

T. E. Potok - University of Tennessee


Initial l.jpg
Initial

  • Poorly defined procedures and controls

  • No management mechanism to to ensure they are followed

  • Heroic efforts by one or two people saves the day.

  • Projects are late, crisis to crisis

T. E. Potok - University of Tennessee


Repeatable l.jpg
Repeatable

  • Basic project controls

  • Quality problems

  • No framework for orderly improvement

  • Fault data is being collected

T. E. Potok - University of Tennessee


Defined l.jpg
Defined

  • Commitment to software process evaluation and improvement

  • Appropriate software engineering standards and methods are in place

  • Strong qualitative understanding of the process

T. E. Potok - University of Tennessee


Managed l.jpg
Managed

  • Process is quantified

  • Quality and productivity measured for each key task

  • Wide dissemination of process related information

  • Errors can be predicted with acceptable accuracy

T. E. Potok - University of Tennessee


Optimizing l.jpg
Optimizing

  • Process improvement feed-back and feed-forward controls

  • Rigorous defect causal analysis and defect prevention

  • Proactive management

T. E. Potok - University of Tennessee


More on cmm l.jpg
More on CMM

  • There are 18 key process areas defined by CMM, including

    • Requirements Management,

    • Software Configuration Management

    • Process Change Management

    • Defect Prevention

  • Each key process area has five common features:

    • 1) goals to be achieved;

    • 2) ability to perform;

    • 3) activities performed;

    • 4) measurement and analysis;

    • 5) verification

T. E. Potok - University of Tennessee


Level of an organization l.jpg
Level of an organization

  • Levels are determined by audit.

  • Like ISO 9000, the program can be of great value, or can be done to merely reach a level.

T. E. Potok - University of Tennessee


Requirement analysis l.jpg

Requirement Analysis

T. E. Potok - University of Tennessee


Three basic types of requirements l.jpg
Three basic types of requirements

  • Requirements against an existing product

    • Make a change or modification to an existing product

  • A new project with requirements directly from a customer

    • Building a project for a specific customer

  • Market requirements for a new product

    • Building a new product that the market may need

T. E. Potok - University of Tennessee


Requirements against an existing product l.jpg
Requirements against an existing product

  • A very structured environment

  • Requirements are usually clearly understood

  • Determining the priority of the requirements is the challenge.

    • Not implementing a much needed requirements can could a loss of market share

    • Implementing trivial requirements may result is a wasted investment

    • Assessing priorities will be covered later in the course

T. E. Potok - University of Tennessee


New project requirements l.jpg
New project requirements

  • Customer need special software built for his or her need

  • This need is typically described informally to the programming team

  • The programming team then attempts to transform the requirements into running code

T. E. Potok - University of Tennessee


How to gather and record requirements l.jpg
How to gather and record requirements

  • Traditional approach is the JAD (Joint Application Development) session

  • Domain experts are taught rudimentary data modeling and data flow diagramming techniques, then lead by an expert into developing a design

  • A beginning design can be developed in a few days

T. E. Potok - University of Tennessee


Jad sessions l.jpg
JAD Sessions

  • Entity relationship modeling is used to capture the data requirements

    • These ER models are then translated into a database definition

  • Data flow diagrams are used to capture the functions that are needed by the system

    • These DFDs are then translated into functional designs

T. E. Potok - University of Tennessee


Entity relationship modeling l.jpg
Entity Relationship Modeling

Enrolls

Name

Number

Description

Department

Credit hours

Student limit

5,m

1,m

Student

Class

Grade

1,m

Name

ID number

Classification

Major

Teaches

1,1

Teacher

Name

Department

T. E. Potok - University of Tennessee


Dataflow diagrams l.jpg
Dataflow Diagrams

Student

Enrolls

Class list

Class

Enrollment Flag

Teacher

Assign

Class

T. E. Potok - University of Tennessee


Oo approach l.jpg
OO approach

  • Another methods is the use of scenarios, or use cases to gather requirements

  • The customer deals in his or her domain describing what the computer system should do.

  • The programmer needs to understand the basics of the domain, and work through inconsistencies or problems in the scenarios.

T. E. Potok - University of Tennessee


Use cases l.jpg
Use Cases

  • Use cases can be derived from a requirements document, or with the help of the customer

  • The use cases stress

    • Inputs and outputs

    • What the computer does

    • How use cases relate to each other

T. E. Potok - University of Tennessee


Example l.jpg
Example

  • Register

  • Starts: When a student want to register

  • Ends: When a student registers for a class

  • Actors: Student

  • Scenario:

    • Enter the registration system (separate use case)

    • Select register

    • Enter student number

    • select department the class is taught by

    • select the specific class to register for

    • receive confirmation of registration

  • Teach

  • Starts: When class begins

  • Ends: When class ends

  • Actors: Teachers and student

  • Scenario:

    • Link to course server

    • Adjust live video

    • view the class

    • disconnect from server

T. E. Potok - University of Tennessee


New product l.jpg
New product

  • Survey the market to understand what is needed and how much it will sell for

  • Survey the competition, what are their strengths and weaknesses

  • Develop the product based on what is learned from this analysis

T. E. Potok - University of Tennessee


Common problems l.jpg
Common Problems

  • The customers does not know what they really want

  • The customers know what they want, but it is impossible, or impractical to achieve

  • The customers change what they want after development has started

  • The programmer do not understand the requirements

T. E. Potok - University of Tennessee


The customers does not know what they really want l.jpg
The customers does not know what they really want

  • Often business problems shift in importance or scale

  • A critical problem two months ago, may be uninteresting today

  • There may not be enough of an understanding of the problem to know what a good solution would be

T. E. Potok - University of Tennessee


The customers know what they want but l.jpg
The customers know what they want, but...

  • Many customers are not very familiar with software

  • Having a computer understand a paragraph of text does not seem too difficult

  • Or to have a computer learn over time

T. E. Potok - University of Tennessee


How to figure out what the customer wants l.jpg
How to figure out what the customer wants

  • Interviews

  • Surveys

  • Market research

  • Prototypes

T. E. Potok - University of Tennessee


Summary60 l.jpg
Summary

  • Software is probably most like engineering, but it is not an exact fit

  • Productivity demands of software development keeps increasing

  • CMM is a way of assessing and improving the way that software is developed

  • Requirements are essential to building effective software

T. E. Potok - University of Tennessee


ad