Software Process

1
Software Process
2
What is software process

• if I say ????, you should be able to guess what
  is roughly about
• In manufacturing
• process is important to guarantee product quality
• QC (Quality Control is a well known discipline in
  manufacturing)

3
Story

• You start a project, as a project leader
• You got 10 people to work on your project, you
  have a one-year schedule plan
• Some programmers comes and leaves
• Some programmers with talent, some do not
• You have them work as a team. Most of the time,
  you and they communicate via meeting and face to
  face

4

• You roughly plot the design
• You expect the programmers to work smartly, more
  importantly, you believe your programmers
  understand and remember your idea and hopefully
  they can smartly transfer your idea into
  programs.
• You think you just need to do the coordinating
  work, managing resources.

5
The hard time comes

• When programmers begin to merge and integrate
  their code.
• programmer A said Oh ! I dont know I need to
  write that part !, when did we have a deal?
• programmer B complains to others We have an
  agreement (in words) on the interface and
  specification, when did you change that?
• programmer C complains How come his module
  (procedures) is not tested? how can we do the
  integration testing?
• programmer D complains Why Fs module can do
  different things when called several times?
• programmer E is in charge of debugging and he
  complains How come programmer X can write such
  a lousy program that I cannot even read?
• Programmer F complains How come during
  integration, there are so many bugs and isolate
  the bugs are difficult?

6

• Programmers G complains how come the design is
  wrong and does not work in the beginning?
• Programmer H complains How come the product
  manager keep enforce us to change specification
  in the middle of development?

7
The story continues

• You went through all the troubles
• You got controlled by the superman
• You got controlled by the poor programmers (you
  know his leave can hurt your project)
• You really got hurt by the programmers who leave
  in the middle of projects

8
Final result

• A poor quality product is produced. Bug number is
  beyond reasonable level
• Your product is difficult to maintain.
  Maintenance tasks are left to rookie programmers
  because the original developer knows the truth!
• Your project delayed
• Your project exceeds budge limits
• Customer is unhappy
• Programmers are sad and ask for transfering to
  other teams

9

• Now, you are again in charge of another project.
• 20 people again is under your supervision
• What will you do to avoid the mess of last
  project?

10
The answer

• programmer A said Oh ! I dont know I need to
  write that part !, when did we have a deal?
• You want programmers to write down their
  communications as formal documents or in a
  software which can traced back to every decisions
  and action items made along the process
• programmer B complains to others We have an
  agreement (in words) on the interface and
  specification, when did you change that?
• Solution 1 A elite design team is formed
  (includes experienced programmers, software
  architect, project managers) to plot the design
  and module interface. Detailed descriptions
  should be included in the document so that
  programmers can begin their work simply by
  reading the documents. A formal meeting is
  called to dispatch the work to programmers
• Solution 2 In the design stage, you want to
  initiate a series of formal meeting called work
  breaking and module interface design meeting. In
  the meeting, you want programmers to participate
  and discuss how to break their work and write
  down their module interface. In this way,
  programmers can participate the design. After the
  meeting, someone good at writing documents should
  write the meeting minutes into a design document
  which again solidify the idea and communication
  in the meeting. The document should be detailed
  enough so that programmers can program solely by
  the documents.

11

• programmer C complains How come his module
  (procedures) is not tested? how can we do the
  integration testing?
• Solution 1You lay down a rule. Before
  integration testing, each programmer should fully
  test their module. A test report should be
  released by the programmer to show how much they
  have tested their module Introduce the idea of
  module testing.
• Solution 2 QA is trained to use tool like
  visual test to do white box testing over
  module. A report is generated by the QA team
  before integration testing.
• programmer D complains Why Fs module can do
  different things when called several times?
• In the middle of development, a code review
  meeting is initiated to have everyone review
  code. You want to make sure every programmer does
  not do strange things for their programming
  convenience, such as using global variables
  excessively.
• The non-reentrance property is tested by QA team.

12

• programmer E is in charge of debugging and he
  complains How come programmer X can write such
  a lousy program that I cannot even read?
• A code quality assurance (CQA) team is formed.
  A rule of submitting source code to CQA is laid
  down .
• A code review meeting is called in the middle of
  development.
• Programmer F complains How come during
  integration, there are so many bugs and isolate
  the bugs are difficult?
• Improve the process in
• Introduce a better process to perform integration
  testing which allows to isolate bugs from
  different modules.

13

• Programmers G complains how come the design is
  wrong and does not work in the beginning?
• Introduce a design review meeting
• introduce a new position called software
  architects who is capable of review design or
  write good design documents.
• Programmer H complains How come the product
  manager keep enforce us to change specification
  in the middle of development?
• Introduce a strict specification change process
  after coding begins
• After coding begins, a specification change
  meeting is called to evaluate the impact of a
  specification, requirement, and design change.
  The meeting minutes should be well-described and
  released to programmers. To the best, a
  documentation system is setup and confirm each
  programmer to read these documents.
• A specification freezing process is laid down.
  Change made to specification and design beyond a
  certain point should be approved by several
  levels of management agreement. It is simply to
  make change difficult if the product managers
  wants to do so.

14
Presumably

• Your new project should proceeds much smoothly
• Your schedule planning make more sense by
  controlling and suppress possible ???? in the
  development as much as possible. These ???? can
  cause schedule delay and exceed budget limits.

15
This is the Software Process
16
What is a process?

• A process is like how to prepare a meal
• Cook always describe the process in a recipe
• Small difference in recipe or secrete can cook
  two different meal, although the material are the
  same

17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
Software Processes

• DEFINITIONCoherent sets of activities for
  specifying, designing, implementing and testing
  software systems
• Software processes are hard to apply in general.
• You need to modify your process to suit your
  needs concerning
• Your type of software
• ??????????????
• ????????????????
• ????release ???????????????
• Your type of programmers
• Your interval of job switch
• Your company organization

22
Software process ??

• No process
• Chaos
• Project success depends on personal skill and
  talent of programmers.
• Yes, your project may still succeed.
• Heavy process
• CMMI,RUP
• Suitable for OEM software company
• Drawbacks can easily become do process for
  process and forget that process is used to help
  software development. It is not the major body of
  software process

23
In reality

• Programmers hate process because process can
  limit their creativity and constrain their way of
  programming
• Some of them believe the process only write
  non-sense documents to satisfy management
  bureaucracy
• Many programmers believe SE documents are
  non-sense
• Programmers like to ???? and play fake.

24
Why ?

• Programmers in school are not educated well. No
  GOOD software engineering course or tutors
• There are software engineering courses, but the
  whole class seems to talk abstract ideas and
  methods.
• School course focus on techniques such as
  algorithms, networking, and etc.
• Companies do not establish SE cultures in the
  beginning.

25
It is true

• Too much nonsense process can decrease the
  productivity
• Too little process brings chaos
• Effective process make project progress slow in
  the beginning but speed up project progress in
  the end

process
process
Real work
Real work
Bad process example
Ideal process
26
The suggestion

• Choose and develop your own process with minimum
  efforts but maximum benefits to your projects.
• Educate programmers to follow these processes
  strictly.
• Modify, improve, and evaluate process and tools
  once a product cycle is ended.

27
Process Improvement

• Process ????????????WOT(waste of time)
  ????development???
• ???????????????????????care?????????????????,????
  ???????????????

28
Summary

• Process needs improvement
• Process needs enforcing discipline on
  programmers (you need to believe it first then to
  enjoy it do you believe in god?)
• Face with process with honesty. When it is a WOT,
  it should be open discussed.

29
Standard software process activities

• Requirement analysis
• The process to understand what customer needs and
  what features you wanna build
• Determine what to build
• Specification (Specs)
• The process to write requirement and system
  features into a formal documents.
• The documents can be used as contract and the
  guidelines for programmers. It is the document
  for testers to decide if a program behaves
  correctly.
• Specifications should be written in a way that is
  implementation independent

30
Standard software process activities

• Analysis and Design
• The process to decide how to build the system
  described by the specs.
• Decide what kind of software/hardware technology
  is used
• Architecture design
• Module interface design
• e.g., Object-oriented analysis and design (OOAD)
  decide how the program should be implemented by
  classes. The cooperation of class behaviors
  constitutes the program eventually.

31
Standard software process activities

• Implementation
• Also known as coding debugging
• Validation and Verification
• The process to assure the quality of code
• Maintainability (how program structure react to
  requirement changes)
• Completeness (how program, specification, or
  design meet user needs)
• total correctness (how program react to total
  inputs)
• Readability (how program react to program
  tracing)
• evolvability (how program react to new
  requirements

32

• Testing
• The process to assure correctness of program s
  runtime behaviors (similar to validation)
• Maintenance and software evolution
• The process to modify program to answer
  requirement change

33
Software process model

• Now you know the standard activities in the
  software development.
• Suppose you are in charge of a project.
• How do you plan to build your systems?
• Lets see some metaphor

34
1st choice Ad hoc approach????

• ??????
• ??????
• ?????,????,????

35
2nd choice ????

• ?????????
• ????,????
• Incremental approach
• Pros ??????????,?????????????????,?????????
• Cons ???????????,??????????????????,?????????????
  ???? requirement change ????

36
3rd Choice ????

• ?????????,?????????????
• A plan is laid out to construct many subsystems.
  Let each subsystem grows and form a whole system
• Suitable for system with subsystems which barely
  communicate and interact between each other.
• Suitable for system whose requirement and
  specification are not well known in the beginning
• Pros Only simple planning is needed.
• Cons ??????????????,?????,????????????,??????????
  ?????????

37
4th choice mimic building construction

• The project is carefully planned
• Blue print is produced analysis and design
  documents
• Suitable for large-scale project and technical
  risks are not high.
• Suitable for systems with clear requirement and
  specification
• Pros the project can be carefully planned
• Cons lack of flexibility to requirement change
  in the middle of development.

38
Software process model

• What is software process model?
• an abstract representation of a process. It
  presents a description of a process from some
  particular perspective
• ?? - ???????????(generic software process model)
• ?????????????????????????????????????????????????
  ??????????????????

39
Well known software process model waterfall

• Waterfall model
• First software process model in human history

40

• Waterfall model
• No one use exactly in industry now
• Too heavy and inflexible for software
• Hard to deal software whose specification and
  requirement are not clearly identified.
• The drawback of the waterfall model is the
  difficulty of accommodating change after the
  process is underway

41

• Inflexible partitioning of the project into
  distinct stages
• This makes it difficult to respond to changing
  customer requirements
• Therefore, this model is only appropriate when
  the requirements are well-understood

42
Well known software process model evolutionary
development

• Exploratory development
• Objective is to work with customers and to evolve
  a final system from an initial outline
  specification. Should start with well-understood
  requirements
• Throw-away prototyping
• Objective is to understand the system
  requirements. Should start with poorly understood
  requirements

43

• Problems
• Lack of process visibility
• Systems are often poorly structured
• Special skills (e.g. in languages for rapid
  prototyping) may be required
• Applicability
• For small or medium-size interactive systems
• For parts of large systems (e.g. the user
  interface)
• For short-lifetime systems

44
Incremental development

• Rather than deliver the system as a single
  delivery, the development and delivery is broken
  down into increments with each increment
  delivering part of the required functionality
• User requirements are prioritised and the highest
  priority requirements are included in early
  increments
• Once the development of an increment is started,
  the requirements are frozen though requirements
  for later increments can continue to evolve

45
Incremental development
46
Incremental development advantages

• Customer value can be delivered with each
  increment so system functionality is available
  earlier
• Early increments act as a prototype to help
  elicit requirements for later increments
• Lower risk of overall project failure
• The highest priority system services tend to
  receive the most testing

47
Extreme programming (?? programming)

• One hot process in recent years.
• New approach to development based on the
  development and delivery of very small increments
  of functionality
• Relies on constant code improvement, user
  involvement in the development team and pairwise
  programming
• extreme programming believes ????????????????????,
  ??????????????????????

48
Spiral development

• Process is represented as a spiral rather than as
  a sequence of activities with backtracking
• Each loop in the spiral represents a phase in the
  process.
• No fixed phases such as specification or design -
  loops in the spiral are chosen depending on what
  is required
• Risks are explicitly assessed and resolved
  throughout the process

49
Spiral model of the software process
50
Spiral model sectors

• Objective setting
• Specific objectives for the phase are identified
• Risk assessment and reduction
• Risks are assessed and activities put in place to
  reduce the key risks
• Development and validation
• A development model for the system is chosen
  which can be any of the generic models
• Planning
• The project is reviewed and the next phase of the
  spiral is planned

51
Software specification

• The process of establishing what services are
  required and the constraints on the systems
  operation and development
• Requirements engineering process
• Feasibility study
• Requirements elicitation and analysis
• Requirements specification
• Requirements validation

52
Formal systems development(??????)

• Based on the transformation of a mathematical
  specification through different representations
  to an executable program
• Transformations are correctness-preserving so
  it is straightforward to show that the program
  conforms to its specification
• Embodied in the Cleanroom approach to software
  development

53
Formal methods

• suitable for systems which require high
  reliability.
• The problems
• Formal specification is difficult to use in
  practice.
• Too many software features cannot be described
  and defined in mathematical specification
• writing formal specification requires high skills