CS 3141: Team Software Project

1
CS 3141Team Software Project Introduction to
Software Engineering

• Ali Ebnenasir
• Department of Computer Science
• Michigan Technological University

2
Acknowledgement

• Evelyn Stiller
• Cathie LeBlanc
• Betty H.C. Cheng

3
What is Software Engineering?

• Systematic approach for developing software
• Methods and techniques to develop and maintain
  quality software to solve problems.
• (Software Engineering Methods and Management,
  Pfleeger, 1990)
• Study of the principles and methodologies for
  developing and maintaining software systems.
• (Perspectives on Software Engineering,''
  Zelkowitz, 1978)

4
What is Software Engineering?

• Practical application of scientific knowledge in
  the design and construction of computer programs
  and the associated documentation required to
  develop, operate, and maintain them.
• (Software Engineering,'' Boehm, 1976)
• Deals with establishment of sound engineering
  principles and methods in order to economically
  obtain software that is reliable and works on
  real machines.
• (Software Engineering,'' Bauer, 1972)

5
Why Engineer Software?

• Air traffic control case study
• 2.3 Billion spent without any usable deliverable
• Enormous social cost of NOT engineering software
• Too many large-scale software development
  failures for too many decades
• Software development initiatives fail for many
  different reasons, most of which are addressed by
  good software engineering practices

6
Sources of Complexity in Software Development

• Technical staff lacks expertise in the complex
  application domain
• Difficulty in interpersonal communications
• Ambiguity of natural language, used to express
  user needs
• Difficulty of mentally grasping and coordinating
  the details of a large-scale development project

7
How Software Development Projects Fail

• No functioning software results
• The resulting software does not adequately
  address the need of the users
• Software contains incorrect computations
• The software is too difficult to use correctly
• The system response time is too slow to be used
  without frustration

8
Why Inter-personal Communication is Difficult

• Technical staff and end users have different
  background knowledge
• Technical staff often do not possess the
  vocabulary used in the application domain
• End users frequently do not understand how to
  effectively express their needs in terms that are
  clear to systems developers.
• Ambiguity of natural language

9
Maintaining Software Systems

• Maintenance is an inevitable aspect of software
  development
• It allows software to evolve with an organization
• Too often too many resources are directed to
  maintenance and away from new development
• Software requires excessive maintenance efforts
  if it is poorly structured
• It is better to invest in well-structured
  software up front than to invest excessively in
  maintenance later

10
Elements of a Software Development Paradigm

• Conceptualization
• What elements are instrumental in how the
  developers think about the software system?
• Representation
• Must convey what the software project is all
  about
• Most effectively done with a software modeling
  notation
• Implementation
• Addresses how the source code is structured

11
A Brief History of Software Engineering Techniques

• Structured Programming
• No gotos
• Functional Decomposition
• Top-down organization of subprograms
• Structured Analysis
• Recognition that analyzing the problem statement
  has critical influence on the success of the
  overall project
• Formal modeling of subprogram interaction with
  dataflow diagrams

12
More History of SE Techniques

• Data-centered analysis
• Uses techniques developed in structured analysis
• Data modeling occurs using entity relationship
  diagrams before functional modeling
• Object-oriented analysis
• No longer segregates the modeling of functions
  and data
• Objects aggregate data with functions that
  operate on the data

13
Sample Dataflow Diagram
Patron ID
Check for overdue books
Check-outbooks
True/false
Patron record or null
Book ID, out
Patron ID
Book ID
Read Patronrecord
Change bookstatus
Read book record
Book record
Book record
Write book record
14
Sample Entity Relationship Diagram
LibraryPatron
Address
Has-a
Checks out
Requests
Has-a
1M
1M
Book
Publisher
Has-a
15
Principles of the Object-Oriented Paradigm

• Abstraction
• Modularity
• Modeling
• Inheritance
• Encapsulation(covered later)
• Polymorphism(covered later)

Shared by other paradigms
16
Abstraction

• Expressing the user requirements in abstract
  terms, suppressing details so that a
  comprehensive portrayal can be made
• The abstract representation must then be
  connected to more detailed expressions, so that
  no information is lost in modeling the system
• This allows us to reason about the breadth of
  functionality of the developing system

17
Modularity

• Breaking a complex software system into smaller
  modules allows reduces its overall complexity
• Modules should aggregate some coherent aspect of
  the system
• Modules should present a simple interface
• Classes, functions, and abstract data types are
  examples of modules.

18
Abstract Data Type Example
Interface
STACK
POP() PUSH(item) ISEMPTY()
Accesses
13
98
12 24 98 33 13
24
Implementation Option Array
Implementation Option Linked list
19
Modeling

• Modeling is the process of use a graphic notation
  to express requirements and properties of the
  software system
• Models express how the system is built out of
  modules and how these modules interact
• One objective of modeling is to express
  characteristics of the software system in an
  unambiguous manner, which is very difficult!

20
Inheritance

• A property distinguishing classes from abstract
  data types
• Allows characteristics from one class to be
  passed on its subclasses
• Subclasses may override inherited characteristics

21
Cost of not Engineering Software

• Need to restructure code
• High maintenance costs
• Software is unacceptable to end users
• Unreliable code
• Need to rewrite code
• Difficulty integrating system modules
• Difficult project management
• Budget and time overruns

22
Why Software Engineering is not Universal

• Understanding software development as programming
  only without recognition of importance of
  analysis and design
• Short-sighted technical management
• Pressure of deadlines
• Poor project estimation, thus unreasonable
  deadlines

23

• Software Engineering Phases and Process Models

24
Software Engineering Phases

• Definition What?
• Development How?
• Maintenance Managing change
• Umbrella Activities Throughout lifecycle

25
Definition

• Requirements definition and analysis
• Developer must understand
• Application domain
• Required functionality
• Required performance
• User interface

26
Definition (cont.)

• Project planning
• Allocate resources
• Estimate costs
• Define work tasks
• Define schedule

• System analysis
• Allocate system resources to
• Hardware
• Software
• Users

27
Development

• Software design
• User interface design
• High-level design
• Define modular components
• Define major data structures
• Detailed design
• Define algorithms and procedural detail

28
Development (cont.)

• Coding
• Develop code for each module
• Unit testing

• Integration
• Combine modules
• System testing

29
Maintenance

• Correction - Fix software defects
• Adaptation - Accommodate changes
• New hardware
• New company policies
• Enhancement - Add functionality
• Prevention - make more maintainable

30
Umbrella Activities

• Reviews - assure quality
• Documentation - improve maintainability
• Version control - track changes
• Configuration management - integrity of
  collection of components

31
Development Process

• Step-by-step procedure to develop software
• Typically involves the major phases
• analysis
• design
• coding
• testing

32
Process Model / Methodology

• Set of activities, notations, tools, in defined
  sequence
• Goal Order, predicitability, quality, cost
  control
• Follows requirementsgtdesigngtcoding, etc.
  sequence (usually)
• Usually defines phases or steps
• Often has notations
• Sometimes has tools

33
Waterfall Process Model
Requirements
Design
Coding
Testing
Maintenance
34
Prototyping Process Model
Requirements
Quick Design
Prototype
Evaluate
Design
35
When to use prototyping?

• Help the customer pin down the requirements
• Concrete model to test out
• Often done via the user interface
• Explore alternative solutions to a troublesome
  component
• e.g., determine if an approach gives acceptable
  performance
• Improve morale
• Partially running system provides visibility into
  a project
• Never press down a prototype to final product!

36
Spiral Process Model
Planning
Risk Analysis
Customer Evaluation
Engineering
37
Process Models

• Idealized view of the development process
• Different models are often used for different
  subprocesses
• may use spiral model for overall development
• prototyping for a particularly complex component
• waterfall model for other components

38
CMM Capability Maturity Model

• Level 1 Initial
• ad hoc
• success depends on people
• Level 2 Repeatable
• track cost, schedule, functionality
• Level 3 Defined
• use standardized processes

• Level 4 Managed
• collect detailed metrics
• Level 5 Optimizing
• continuous process improvement
• built-in process improvement

Software Engineering Institute http//www.sei.cmu
.edu/cmm/
39
Why is software development so difficult?

• Project characteristics
• Novelty
• Changing requirements
• 5 x cost during development
• up to 100 x cost during maintenance
• Hardware/software configuration
• Real time requirements

• Communication
• Between customer and developer
• Poor problem definition is largest cause of
  failed software projects
• Within development team
• More people more communication
• New programmers need training

40
Why is software development difficult? (cont.)

• Personnel characteristics
• Ability
• Prior experience
• Communication skills
• Team cooperation
• Training
• Facilities and resources
• Identification
• Acquisition

• Management issues
• Realistic goals
• Cost estimation
• Scheduling
• Resource allocation
• Quality assurance
• Version control
• Contracts
• Crosscutting concerns
• Availability requirements
• Security requirements
• Reliability requirements
• Correctness/High assurance

41
Summary

• Software lifecycle consists of
• Definition (what)
• Development (how)
• Maintenance (change)
• Different process models concentrate on different
  aspects
• Waterfall model maintainability
• Prototype model clarifying requirements
• Spiral model identifying risk
• Maintenance costs much more than development

42
Bottom Line

• U.S. software is a major part of our societal
  infrastructure
• Costs upwards of 200 billion/year
• Need to
• Improve software quality
• Reduce software costs/risks

43
Impact of SE Research

• Impact of research is measured over time and
  utility
• Who do you think has had the most impact on the
  field of software engineering?
• Why?

44
People you should know

• David Parnas modularity, reuse, abstraction
• Edsger Dijkstra structured programming
• Harlan Mills clean room programming
• Mark Weiser ubiquitous computing

45

• Software vs. Hardware Engineering

46
Hardware and Hardware Engineering

• Characteristics
• Components are packaged as individual building
  blocks
• Standardized interfaces among components
• Large number of off-the-shelf components
• Performance, cost, and availability easily
  determined/measured
• Hardware configuration built from a hierarchy of
  "building blocks"

47
Hardware Engineering

• Phases to system engineering of hardware
• Development Planning and requirements analysis
• best classes of hardware for problem
• availability of hardware
• type of interface required
• identification of what needs to be designed and
  built
• Establish a Plan or "road map" for design
  implementation
• May involve a hardware specification
• Use Hardware Description Languages (HDL)
• Use CAE/CAD to develop a prototype (breadboard)
• Develop printed circuit (PC) boards
• Manufacturing of boards

48
Software and Software Engineering

• Function may be the implementation of a
  sequential procedure for data manipulation
• Performance may not be explicitly defined
  (exception in real-time systems)
• Software element of computer-based system
  consists of two classes of programs, data, and
  documentation
• Application Software
• implements the procedure that is required to
  accommodate information processing functions
• System Software
• implements control functions that enable
  application software to interface with other
  system elements

49
Three high-level phases ofSoftware Engineering

• Definition phase
• Software planning step ? Software Project Plan
• scope of project
• risk
• resource identification
• cost and schedule estimates
• Software Requirements Analysis ? Requirements
  Specification
• System element allocated to software is defined
  in detail
• Formal information domain analysis to establish
  models of information flow and structure (expand
  to produce specification)
• Prototype of software is built and evaluated by
  customer
• Performance requirements or resource limits
  defined in terms of software characteristics
• Definition and Requirements must be performed in
  cooperation

50
Development Phase

• Development Phase
• Translate set of requirements into an operational
  system element
• Design ? Design Specification
• Coding (appropriate programming language or CASE
  tool)
• Should be able to directly trace detail design
  descriptions from code. i.e., traceability
• Verification, release, and maintenance phase
• Testing software ? Testing Plan
• to find maximum number of errors before shipping
• Testing shows software has errors, it does not
  show the lack of errors!
• Prepare software for release ? Quality Assurance
• Maintain software throughout its lifetime

51
Working in Teams

• Be conscientious about due dates
• Meet regularly with your team
• Always create an agenda for every team meeting
• Rotate responsibility for chairing team meetings