Introduction to Software Engineering - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Introduction to Software Engineering

Description:

Introduction to Software Engineering Definition and properties A system is a collection of interrelated components that work together to achieve some objective ... – PowerPoint PPT presentation

Number of Views:752
Avg rating:3.0/5.0
Slides: 55
Provided by: BongO
Learn more at: http://curry.ateneo.net
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Introduction to Software Engineering


1
Introduction toSoftware Engineering
2
Definition and properties
  • A system is a collection of interrelated
    components that work together to achieve some
    objective
  • Properties
  • Complex interrelationship among the parts
  • Reliability
  • Usability

3
System its environment
  • We create a system to modify/adapt to the
    environment
  • There are internal external relationships
    between the system and its environment

4
Procurement
  • To buy
  • To design from scratch
  • Large systems mix of bought and designed
    systems
  • Others really start from scratch using a
    development tool.

5
System customer
Principal contractor
Subcontractor 1
Subcontractor 1
Subcontractor 1
6
Software Engineering
  • The profession concerned with creating and
    maintaining software applications by applying
    computer science, project management, domain
    knowledge and other skills and technologies
  • SE technologies and practices (databases,
    libraries, patterns, platforms, processes, etc.)
    help developers by improving productivity and
    quality

7
SE Pressman
  • An outgrowth of hardware and systems
    engineering. It encompasses a set of three key
    elements methods, tools, and procedures -- that
    enable the manager to control the process of
    software development and provide the practitioner
    with a foundation for building high-quality
    software in a productive manner.

8
The classic life cycle
  • Systems Engineering (requirements gathering)
  • Analysis
  • Design
  • Code
  • Testing
  • Maintenance

9
The system engineering process
  • Requirements definition
  • Systems Design
  • Sub-system development
  • System Integration
  • System installation
  • System evolution
  • System decommissioning

10
System requirements definition
  • Determine
  • Coarse grain functional requirements (what are
    the basic functions of the system)
  • System properties (availability, performance,
    safety, security)
  • What it should not exhibit

11
System design
  • Partition requirements
  • Identify sub-systems
  • assign requirements to sub-systems
  • Specify sub-system functionality
  • Define sub-system interfaces

12
Sub-system developmemt
  • Development of the sub-systems
  • Programming

13
System integration
  • Putting together independently development
    sub-systems into one coherent system

14
System Installation
  • Problems
  • Different environment in which the system is to
    be installed (OS, development software version)
  • Human resistance
  • Co-existence with an old system
  • Physical installation problems

15
Final stages
  • System operation
  • training, changing the normal work process
  • System evolution
  • feedback and changes in the environment
  • change is costly
  • System decommissioning
  • Putting the system out of service

16
Software Lifecycles
17
Definition
  • Software Lifecycle refers to the progression of
    the software system from development through
    maintenance and eventually replacement.
  • Involves the activities in the production of a
    software system.

18
Phases In General
  • Requirements analysis and specification
  • Design
  • Preliminary Design
  • Detailed Design
  • Implementation
  • Testing
  • Unit testing
  • Integration Testing
  • System Testing
  • Installation and Acceptance Testing
  • Maintenance

19
Examples of Software Lifecycles
  • Waterfall model
  • Modified Waterfall Model
  • Prototyping
  • Boehms Spiral model
  • Object-Oriented Analysis

20
Waterfall Model
  • Derived from other engineering processes in the
    70s
  • Offered a means of making the development process
    more structured
  • Expresses the interaction between subsequent
    phases
  • Each phase cascades into the next
  • Original WM
  • A strict sequence was implied
  • Did not provide feedback

21
Modified Waterfall Model
  • Need to provide for overlap and feedback between
    phases
  • It is iterative compared to the linear model of
    the original WM
  • Verification and validation are added
  • Verification checks that the system is correct
  • Validation checks that the system meets the users
    desires

22
Comments on WM
  • Inflexible in the partitioning of the project in
    distinct phases
  • Reflect common engineering practices
  • Emphasis
  • Discerning the users needs and requirements prior
    to the system being built
  • Agreement bet. User and developer with respect to
    the requirements

23
Comments on WM
  • Exclusively document-driven models
  • Some facts
  • 50 of the design effort occurs during the actual
    design phase
  • 1/3 of the design effort done in the coding
    activity
  • 16 of the design effort occurs after the system
    is supposed to be completed
  • People using this type of model are
    opportunistic. There is a need for strictness and
    signoffs in terms of documentation

24
Prototyping
  • Aims to enhance the accuracy of the designers
    perception of the users requirements
  • Develop an initial system for user feedback and
    then refine by developing a lot of versions until
    a satisfactory system emerges
  • Rapid development is the key

25
Types
  • Exploratory
  • Start with parts which are understood and then
    evolves as the user proposed new features
  • Throw Away
  • Focus is more on poorly understood concepts

26
Comments
  • Took 40 less time and 45 less code
  • Produced code which is not as robust and more
    difficult to maintain
  • Less documentation is present

27
Boehms Spiral Model
  • An improved model where all generic models have
    been considered
  • Boehm proposed a spiral model where each round of
    the spiral
  • Identifies the subproblem which has the highest
    risk associated with it
  • Finds a solution to that problem

28
Object Oriented Analysis
  • Activities
  • Object-oriented analysis
  • Object-oriented design
  • Object-oriented programming
  • Main difference between the other models
    Modeling of the system components using
    object-oriented concepts and techniques in
    programming.

29
Planning and Cost Estimation
30
Planning
  • All software development should be planned,
    including analysis and assessment
  • Provides a means for effective management of a
    software project -- identifies problems and
    possible solutions
  • Involves
  • Delivery date
  • Available Staff
  • Budget
  • Staff Expense

31
Estimates
  • Project Structure
  • Project Size
  • Functions and their hierarchical relationships

32
Project Plan
  • Indicates available resources, work breakdown and
    a schedule for completion

33
Documentation
  • Introduction
  • Describe objectives and constraints
  • Organization
  • Team organization, team roles, team members
  • Risk Analysis
  • Describe possible risks and solutions
  • Resource requirements
  • Hardware and Software

34
Documentation
  • Work Breakdown
  • Composed of activities, milestones, tasks and
    deliverables
  • Milestones ending point for a SW activity
  • Milestones are composed of tasks
  • Deliverables To be given to the customer
  • Schedule
  • Reporting Mechanisms
  • Management reports required and their due dates

35
Project Scheduling
  • Difficult and dependent on the experience of the
    project manager
  • Initially optimistic
  • Do not only estimate time, but also resources
    like people and equipment

36
Cost Estimation
  • Like Project scheduling, is also dependent on the
    PMs experience
  • A lot of cost estimation techniques and a lot of
    companies have their own charts in estimating
    cost and what consists of costs

37
Types of estimation
  • Algorithmic Cost modeling
  • Uses historical cost which relates software size
    to cost
  • Expert judgement
  • Experts estimate how much the proj. will cost and
    then it is discussed
  • Estimation by analogy
  • Uses other similar projects as basis

38
Types of estimation
  • Parkinsons Law
  • Work expands to fill the time available
  • Cost is determined by available resources rather
    than by objective assessment
  • 12 mo x 5 people 60 person-months
  • Pricing to Win
  • Based on the customers budget

39
COCOMO Model
  • Algorithmic approach
  • Well documented and one of more widely used
    cost-estimation models
  • Based on the model
  • Effort C PM s M
  • C is complexity of the project, PM is some
    product metric (usually of lines) M is a
    multiplier and s indicates the increasing effort
    for large proj. (lt 1)

40
The formula
  • Basic
  • Well understood application developed by small
    teams.
  • PM 2.4(KDSI)1.05 M
  • Moderate
  • More complex projects whose team members have
    limited experience
  • PM 3.0(KDSI)1.12M

41
The formula
  • Embedded
  • Complex proj. where the software is part of the a
    strongly integrated set of HW, SW, regulations
    and procedures
  • PM3.6(KDSi)1.20M

42
Requirements Analysis Specification
43
Notes
  • The WHAT phase rather than a HOW phase
  • WHAT are the users needs, WHAT is the current
    system, WHAT are the constraints on the current
    and future system
  • Both FUNCTIONAL (describing function or service)
    and non-functional (time, money, OS platform)

44
Document
  • Output Requirement Specification Document
  • Idea Reflects a mutual understanding between
    client and developer of the work to be completed
  • Provides the basis for acceptance testing (did we
    create the right system?)

45
Characteristics
  • Unambiguous
  • Complete
  • Verifiable
  • Consistent
  • Modifiable
  • Traceable
  • Useable

46
Stages
  • Feasibility Study
  • Requirements Analysis
  • Requirements Definition
  • Requirements Specification

47
Feasibility Study
  • Evaluates the ability to satisfy user needs using
    current software and hardware technologies and
    the constraints of the users organization (like
    manpower, budgetary constraints)

48
Requirements Analysis
  • Provides a statement of the requirements of the
    problem
  • Analyzes the current situation
  • States the goals of the system being developed
    (cut costs, reduce errors, etc.)
  • Answers are acquired via interviews,
    observations,
  • Read by client managers, end users, client
    engineers, contractors, development architects

49
Q in RA
  • Who is involved and what are their background
  • What is the current system (equipment
    constraints)
  • What functions will be incorporated?
  • When must the system be completed? (schedule)
  • What is the impact on personnel, training, etc.
  • Why is the new system being developed?
  • What are the constraints in terms of cost?

50
Requirements Specification
  • Details what the system will do
  • Determines what the operational constriants are
  • It should
  • Completely specify technical requirements
  • Specify constraints and functions
  • Specify what should be done in exceptional cases
  • Specify performance requirements

51
RS Document
  • Objective
  • Should state all functions to be performed
  • State all the constraints that affect the system
  • Provide testable criteria for acceptance
  • List qualities of the desired system
  • State default conditions
  • State error conditions and their resolutions
  • States only external system behavior (WHAT the
    system does)

52
Contents of the paper
  • Introduction including general goals
  • Documentation of the current system
  • Current physical system
  • Current logical system
  • Data dictionary of current system
  • File structure for the current system

53
Contents of the system
  • Documentation of the proposed system
  • Proposed physical system
  • Proposed logical system
  • Functional specifications (services to be
    provided)
  • Data dictionary for the proposed system
  • File structure for the proposed system
  • Non-functional requirements (constraints)
  • Feasibility includes estimates of time, money and
    personnel
  • System evolution assumptions (changes and their
    resolutions)

54
Contents of the system
  • Glossary
  • Sign Off
  • Preliminary user manual (primarily screens)
About PowerShow.com