Software Engineering The Software Process

1
Software Engineering The Software Process

• PRESCRIPTIVE MODELS
• Every software engineering organization should
  describe a unique set of framework activities for
  the software process(es) it adopts.
• It should populate each framework activity with a
  set of software engineering actions, and define
  ach action in terms of a task set that identifies
  the work (and work products) to be accomplished
  to meet the development goals.
• It should then ADAPT the resultant process model
  to accommodate the specific nature of each
  project, the people who will do the work, the
  environment.
• Regardless of the model, all models contain the
  following components
• communication
• planning
• modeling
• construction
• deployment
• Which of these phases do you think is most
  difficult and in what situations?

2
Software Engineering The Software Process

• PROCESS MODELS
• What do you think the most popular process model
  is?
• Waterfall
• Incremental
• Evolutionary
• Component Based
• Formal

3
Software Engineering The Software Process

• PROCESS MODELS
• What do you think the most popular process model
  is?
• I would say that the no process model is the
  most popular.

4
Software Engineering The Software Process

• PROCESS MODELS WATERFALL
• The Classic Life Cycle, The Textbook Cycle
• A systematic, sequential approach with the
  following steps
• Customer Specification of Requirements
  (Communication)
• Planning (Estimating, Scheduling, Tracking)
• Modeling (Analysis and Design)
• Construction (Code and Test)
• Deployment (Delivery, Support, and Feedback)
• The book calls the first phase communication. I
  do not like this definition as communication must
  occur at all stages.

5
Software Engineering The Software Process

• PROCESS MODELS WATERFALL
• When is the waterfall process model appropriate?
• In a purest sense, probably never. I have never
  worked on a project that follows a completely
  linear progression.
• However, the waterfall process is appropriate if
  followed in spirit if not the letter of the model
  in some situations
• Well defined projects
• Projects with no technology risks
• Well defined domains
• Stable requirements

6
Software Engineering The Software Process

• PROCESS MODELS WATERFALL
• Why is it difficult to follow?
• Hard to follow a strictly sequential path.
• Customers have difficulty stating ALL the
  requirements explicitly
• Customers business model changes during the
  course of developing the application
• Customers are required to have patience, since a
  working program is not available until very late
  in the process.

7
Software Engineering The Software Process

• PROCESS MODELS INCREMENTAL PROCESS MODEL
• Even with well defined projects, a linear
  approach is often difficult.
• Additionally, sometimes a portion of the software
  needs to be delivered early.
• The incremental model combines elements of the
  waterfall model applied in an iterative fashion.
• Incremental model delivers an operational product
  with each increment.
• Works well for project resource management
  (staffing).

8
Software Engineering The Software Process

• PROCESS MODELS INCREMENTAL PROCESS MODEL

9
Software Engineering The Software Process

• PROCESS MODELS RAD MODEL
• RAPID APPLICATION DEVELOPMENT (RAD)
• Incremental software process that emphasizes a
  short development cycle.
• Highly efficient waterfall model in which rapid
  development is achieved by using component based
  construction.
• Requires well understood project scope.
• Same framework as waterfall
• Customer Specification of Requirements
  (Communication)
• Planning (Estimating, Scheduling, Tracking)
• Modeling (Analysis and Design)
• Construction (Code and Test)
• Deployment (Integration, Delivery, Support, and
  Feedback
• Key difference is parallel development during
  Modeling and Construction.
• Also added to Deployment is an INTEGRATION phase.

10
Software Engineering The Software Process

• PROCESS MODELS RAD MODEL

11
Software Engineering The Software Process

• PROCESS MODELS RAD MODEL
• Usual development time is less than three months.
• Drawbacks
• Large scalable projects, requires sufficient
  human resources
• Everyone must buy in to short term delivery
• Some systems can not be modularized easily
• Difficult when there are high technology risks
• Integration Risk (Not in the book, to me this is
  the largest concern.)

12
Software Engineering The Software Process

• PROCESS MODELS EVOLUTIONARY PROCESS MODEL -
  PROTOTYPING
• Customers define general objectives , but does
  not identify the details.
• Often, the customer doesnt know what they want
  the system to look like.
• Can be a stand alone process or integrated into
  other models.
• I prefer it to be integrated.
• A repeating cycle of the following steps include
• Communication
• Quick Plan
• Modeling Quick Design
• Construction of Prototype
• Deployment Feedback

13
Software Engineering The Software Process

• PROCESS MODELS EVOLUTIONARY PROCESS MODEL -
  PROTOTYPING
• Depending upon the complexity I recommend a first
  pass with Paper Prototypes.
• Paper can be virtual with mockups of the
  application being developed in either a
  development environment like Visual Studio or
  even HTML.
• Second pass could be a semi functional
  application with no data connectivity.
• Third pass for the developers to try any unknown
  technical issues.
• Often good for these prototypes to be used for
  requirements gathering and to reduce technology
  risks. Best if the prototype is a throw-away. One
  good reason to develop your prototype in a
  different language/system than the final project

14
Software Engineering The Software Process

• PROCESS MODELS EVOLUTIONARY PROCESS MODEL -
  PROTOTYPING
• Drawbacks
• Customers like the prototype and want to place
  it in production.
• Developers forget the design decisions and their
  mistakes leak into the production system.

15
Software Engineering The Software Process

• PROCESS MODELS EVOLUTIONARY PROCESS MODEL
  SPRIAL MODEL
• An evolutionary software model that couples the
  iterative nature of prototyping with the
  controlled and systematic aspects of the
  waterfall model.
• This is true, but with one addition risk
  analysis.
• At each cycle through the spiral, milestones are
  achieved and risk is reevaluated.

16
Software Engineering The Software Process

• PROCESS MODELS EVOLUTIONARY PROCESS MODEL
  SPRIAL MODEL

17
Software Engineering The Software Process

• PROCESS MODELS EVOLUTIONARY PROCESS MODEL
• Most developers lean towards evolutionary process
  models.
• They have inherent problems
• Prototyping and similar evolutionary models are
  hard to plan, thus hard to estimate, thus hard to
  contract. How many cycles will there be?
• Speed of evolution is difficult to dictate
• Software processes should be focused on
  flexibility and extensibility rather than on high
  quality.
• Is the third statement true? Why is this a goal?

18
Software Engineering The Software Process

• PROCESS MODELS EVOLUTIONARY PROCESS MODEL
• Most developers lean towards evolutionary process
  models.
• They have inherent problems
• Prototyping and similar evolutionary models are
  hard to plan, thus hard to estimate, thus hard to
  contract. How many cycles will there be?
• Speed of evolution is difficult to dictate
• Software processes should be focused on
  flexibility and extensibility rather than on high
  quality.
• Is the third statement true? Why is this a goal?
• The concept behind it is that if software is
  late, the opportunity of it is lost.

19
Software Engineering The Software Process

• PROCESS MODELS SPECIALIZED PROCESS MODEL
• COMPONENT-BASED DEVELOPMENT
• Commercial off-the-shelf software components, can
  be used when software is built.
• Process includes
• Identification of candidate components
• Either object-oriented or procedural
• Consider integration issues
• Design a software architecture
• Integrate components
• Comprehensive testing
• Does anyone do this as a pure process model?
  More likely as part of another model.
• We all use pre-built components. i.e. Borland
  text editor, advanced data grid, Date/Time
  pickers, etc

20
Software Engineering The Software Process

• PROCESS MODELS SPECIALIZED PROCESS MODEL
• FORMAL METHODS MODEL
• The Formal Methods Model encompasses a set of
  activities that leads to formal mathematical
  specification of computer software.
• In theory, the following is reduced when using
  formal methods
• Ambiguity
• Incompleteness
• Inconsistency
• Do you agree?

21
Software Engineering The Software Process

• PROCESS MODELS SPECIALIZED PROCESS MODEL
• FORMAL METHODS MODEL
• Drawbacks
• The development of formal models is currently
  quite time consuming and expensive
• Few software developers have the background,
  thus extensive training is required. (is training
  viable? COBOL -gt OOP)
• Difficult to use formal model to communicate
  with a non-technical customer.
• Forest and Trees.
• Useful for safety critical application or
  anywhere failure is highly costly.