Software Engineering Management - PowerPoint PPT Presentation

About This Presentation
Title:

Software Engineering Management

Description:

Software Engineering Management Lecture 1 The Software Process Software Process Risk Management The Software Process (Simplified) The Waterfall Model Requirements ... – PowerPoint PPT presentation

Number of Views:81
Avg rating:3.0/5.0
Slides: 28
Provided by: BarbaraH154
Category:

less

Transcript and Presenter's Notes

Title: Software Engineering Management


1
Software Engineering Management
Lecture 1 The Software Process
2
Software Process
Fundamental Assumption Good processes lead
to good software Good processes reduce risk
3
Risk Management
What can go wrong in a software project? How can
the risk be reduced?
4
The Software Process (Simplified)
Feasibility and Planning
Requirements
Design
Operation and Maintenance
Implementation
5
The Waterfall Model
Requirements Definition
System and Software design
Programming and Unit Testing
Integration and System Testing
Operation and Maintenance
6
Requirements Analysis and Definition
The system's services, constraints and goals are
established by consultation with system users.
They are then defined in a manner that is
understandable by both users and development
staff. This phase can be divided into ?
Feasibility study (often carried out separately)
? Requirements analysis ? Requirements
definition ? Requirements specification
7
System and Software Design
System design Partition the requirements to
hardware or software systems. Establishes an
overall system architecture Software design
Represent the software system functions in a form
that can be transformed into one or more
executable programs ? Unified Modeling Language
(UML)
8
Programming and Unit Testing
The software design is realized as a set of
programs or program units. (Written
specifically, acquired from elsewhere, or
modified.) Individual components are tested
against specifications.
9
Integration and System Testing
The individual program units are ? integrated
and tested as a complete system ? tested against
the requirements as specified ? delivered to the
client
10
Operation and Maintenance
? Operation The system is put into practical
use. ? Maintenance Errors and problems are
identified and fixed. ? Evolution The system
evolves over time as requirements change, to add
new functions or adapt the technical
environment. ? Phase out The system is
withdrawn from service.
11
Discussion of the Waterfall Model
Advantages ? Process visibility ? Dependence
on individuals ? Quality control ? Cost
control Disadvantages Each stage in the process
reveals new understanding of the previous stages,
that requires the earlier stages to be revised.
12
Feedback in the Waterfall Model
Requirements Definition
System and Software design
Programming and Unit Testing
Integration and System Testing
Operation and Maintenance
13
Iterative Refinement(Evolutionary Development)
Concept Initial implementation for user
comment, followed by refinement until system is
complete. ? Vaporware user interface mock-up ?
Throw-away software components ? Dummy
modules ? Rapid prototyping ? Successive
refinement
14
Iterative Refinement
Requirements
Evaluation
Implementation (prototype)
Design
15
Iterative Refinement
Concurrent Activities
Initial Version
Requirements
Outline Description
Intermediate Versions
Design
Implementation
Final Version
16
Iterative Refinement Software Process
Concurrent Activities
Outline Description
Requirements
Design
Implementation
Final Version
17
Observations about Software Processes
Completed projects should look like the Waterfall
Model but ... the development process is always
partly evolutionary. Risk is lowered by ?
Prototyping key components ? Dividing into
phases ? Following a visible software process ?
Making use of reusable components
18
Feasibility Study
Before beginning a project, a short, low-cost
study to identify Client Scope
Potential benefits Resources
needed staff, time, equipment, etc.
Potential obstacles Where are the risks? How can
they be minimized?
19
Feasibility Study
A feasibility study leads to a decision go
ahead do not go ahead think again In production
projects, the feasibility study often leads to a
budget request. In research, a feasibility study
is often in the form of a proposal.
20
Class Projects
What are you going to create and why?
21
The Client
In this class, you have two clients Your
fellow students in the class The professor
for the course Can you satisfy them both?
22
Project Scope
What are the boundaries of the team projects?
Must be completed in fifteen weeks Need a
prototype that demonstrates main features
23
Potential Benefits
  • Why are you doing this project?
  • Examples
  • Create a marketable product
  • Improve the efficiency of an organization
  • Control a system that is too complex to
    control manually
  • New or improved service
  • Safety or security
  • Get a good grade in this class

24
Resources
Examples Staff 3 to 5 students, with some
help. How many hours per week? What skills do
people have? Time Must be completed by end of
semester, including operational prototype,
documentation, presentation Equipment and
software What special needs are there? Client
Will the client be sufficiently available and
helpful?
25
Obstacles
Class Projects Start-up time. Creating a team,
scheduling meetings, acquiring software, learning
new systems, ... Business considerations.
Licenses, trade-secrets, ... Too ambitious.
Nothing to show at the end of the
semester. Changing circumstances. Team members
drop the class, ... What else?
26
How to Minimize Risk?
Class Projects Several target levels of
functionality required, desirable, optional
Visible software process intermediate
deliverables Good communication within team
and with the professor Good processes lead to
good software Good processes reduce risk
27
Project Topic Statement
  • A description of your groups project selection
  • Each group needs to pick a name. Hand in one
    sheet that lists the group name and its members.
  • Each group needs to submit a project topic.
    This is an informal write-up that describes what
    the team is going to build.
  • Short enough that everybody reads it
  • Long enough that no important details are
    skipped
Write a Comment
User Comments (0)
About PowerShow.com