Computing and SE II
Chapter 3: Software Development Activities
Er-Yu Ding
Software Institute, NJU
Main Contents
1.
2.
3.
Activities of Software Development
Software Lifecycle and Process Models
Principles and Methodologies of Software
Development
1. Software Development Activities

What we intend
Problems
Solution( Software)
1. Software Development Activities

Problems/Solutions
Real world
analysis
Problem
Methods
Techniques
Languages
Tools
…
design
Installing Solution machine
maintaining
Expected world
Solution
General machine
1. Software Development Activities
Requirements
Analysis
Design
Implementation
Testing
Installing and Maintenance
1. Software Development Activities

Requirements Analysis Requirements Engineering

目的：



需求工程的困难之处：







（1）不存在描述明确的E；
（2）不存在确定的针对S的评估标准R；
（3） E, R  S 是一个创造性的过程。
需求工程的主要工作


描述明确的问题域特性E; 定义良好的系统行为S ; 预期的需求R
需求工程的目的就是根据E，构建S，使得 E, S  R
研究问题背景，描述问题域特性E
需求开发,确定 R
构建解系统，描述解系统行为S，使得
理解现实为第一目的，保证S的质量为第二目的 E, S  R
Mainly Result : SRS (Software Requirements Specification)
“What the product is supposed to do”
1. Software Development Activities

Design
 Aim: establishing software structures based on software entities,
that is a model of the whole system to be developed
 Tasks of Design

Architecture Design


Detail (System) Design




Making interfaces usability
Design decisions dramatically impact system quality


System is decomposed in components
Definition of component functionalities
Definition of component interfaces
HCI Design


The definition of the global architecture of the system
Alternatives, tradeoff
Mainly Result

Model


architecture model, System model
Specification

Architecture specification, system component specification, HIC
documents
“How the product does it”
1. Software Development Activities

Implementation


Aim: implementation of individual components in a
programming language
It starts from the component specifications developed
during design


Interfaces defined in the design should be respected by the
implementation of the component
Tasks

Program design




Code should be well documented and easy to read, flexible,
correct and reliable
Programming
Debug
Result should be an executable program
1. Software Development Activities

Testing
 Aim: validating and verifying the qualities of software products
 Tasks





Testing does not necessarily follow the implementation phase



Testing design
Unit testing: verification of component implementations against their
interfaces
Integration testing: verification of component integration against
system architecture
System testing: validation of the extent to which the requirements
specification is fulfilled
Testing and implementation may run in parallel
Testing may even affect the requirements analysis phase, where
test cases may be derived directly from the requirements
specification
Testing result: errors and faults
1. Software Development Activities

Installing and Maintenance
 Aim: keeping the system operational after delivery to the
customer





Tasks


Corrective : identification and removal of faults
Adaptive: modifications needed to achieve interoperability with other
systems
Perfective: incorporation of new features, improved performance and
other modifications to increase customer satisfaction
Preventive: modifications to mitigate possible degradation of usability,
maintainability, etc.
Installing, training, maintenance
The maintenance phase needs to be considered part of the
development process

Even though the activities within maintenance are requirements
analysis, design, implementation and testing
1. Software Development Activities ---Members of Development Team
Software development steps
Developer
Requirement Analysis
Analyst
Architecture Design
Architect
Detail (system) Design
HCI Design
Designer
Program design
Program implementation
Programmer
Unit testing
Testing design
Integration testing
Tester
System (accept) testing
Installing (System deliver)
Maintenance
Trainer and
Supporter
1. Software Development Activities
--Cost of Activities (1)
Software Development Activities
--Cost of Activities (2)
Software Development Activities
--Cost of Activities (3)
1. Software Development Activities
--Cost of Activities (4)
Requirements &
Analysis – 18%
Development – 25%
Integration –
29%
Design – 19%
Post-Delivery
Maintenance – 75%
Implementation/
Coding – 34%
Total Product Costs
Breakout of
Development Costs
2. Software Lifecycle and Process Models

Life cycle




Software systems evolve as the environment around
them evolves
The development process then becomes cyclic: the
software lifecycle
Life cycle describing the actual steps performed on a
specific product
Life-cycle model


The steps (phases) to follow when building software
A theoretical description of what should be done
2. Software Lifecycle and Process Models

Software Process Models

A development process is described in a process
model




Structured set of activities required to develop a
software system
Activities vary depending on organization and type of
system being developed
Must be modeled in order to be managed
There are many process models described in the
literature

There are many ways of organizing development
2. Software Lifecycle and Process Models



Build-and-fix model
Waterfall model
Iterative Models


Incremental model
Evolutionary
2. Software Lifecycle and Process Models

Build and Fix Model
 Properties



Advantage


No planning or analysis
The working program is
the only work product
Appropriate for small
programs written by one
person
Disadvantage



Understandability and
maintainability decrease
rapidly with increasing
program size
Totally unsatisfactory
Need a life-cycle model
2. Software Lifecycle and Process Models

Waterfall Model

Characterized by




Advantages


Documentation and clearly defined phases
Disadvantages





Sequential steps (phases)
Feedback loops (between two phases in
development)
Documentation-driven
Complete and frozen specification document upfront often not feasible in practice
Customer involvement in the first phase only
Sequential and complete execution of phases
often not desirable
The product becomes available very late in the
process
Applicability

Only appropriate when the requirements are wellunderstood
2. Software Lifecycle and Process Models

Iterative Models


Build software in multiple iterations
Two flavors

Incremental



Incremental Delivery
RAD
Evolutionary






Evolutionary development
Prototyping
Spiral Model
Transformation Model
RUP
Agile
2. Software Lifecycle and Process Models

Incremental Delivery



User requirements are prioritized and the highest priority
requirements are included in early increments
Each release adds more functionality, i.e., a new increment
The waterfall model is employed in each phase
2. Software Lifecycle and Process Models

Incremental Delivery

Advantages




Operational quality portion of product within weeks
Smaller capital outlay, rapid return on investment
Comprehensive spec up front can be used as a contract
Disadvantage

May be hard to create a comprehensive requirements
spec up front if a domain not well understood
2. Software Lifecycle and Process Models

Rapid Application Development (RAD)

Key characteristics:







Iterative approach
User involvement
Prototyping
Sophisticated tools
Small development teams, and
Time boxing: fixed time frame in which activities are carried
out
A cycle of four phases




Joint Requirements Planning (JRP)
Joint Application Design (JAD)
Construction
Cutover
<3 months
2. Software Lifecycle and Process Models

Rapid Application Development (RAD)

JRP Workshop: objective is to get the requirements right
the first time



JAD Workshop(s): user and SWAT (Skilled With Advanced
Tools) team involvement
Construction with SWAT team



this requires end-user participation
Highly skilled personnel, use advanced tools, reuse as much
as possible (COTS, etc.)
Dedicated, they are in control (multi-skills, very effective)
Cutover: testing, training and preparing the next cycle
2. Software Lifecycle and Process Models

Evolution Development

New versions implement new (increments) and
evolving requirements
2. Software Lifecycle and Process Models

Evolution Development
 Advantages






Early increments act as a prototype to help elicit requirements for
later increments
Constant customer involvement and validation
Allows for good risk management - lower risk of overall project failure
Project can be continued as long as each increment delivers value
Agile software development methods use the evolutionary model
Disadvantages

Build-and-fix danger


Can use agile development practices (unit test, increment planning, etc.)
to avert this danger
Not appropriate when a larger part of a system needs to be
commissioned from a supplier

Need a comprehensive requirements spec as a contract up front
2. Software Lifecycle and Process Models

Prototyping

Motivation: Requirements elicitation is difficult



Advantages



Software is developed because the present situation is
unsatisfactory
However, the desirable new situation is as yet unknown
User needs are better accommodated
Problems are detected earlier
Disadvantages


Prototyping risk
The design is of less quality
2. Software Lifecycle and Process Models

The Spiral Model
2. Software Lifecycle and Process Models

The Spiral Model

Waterfall model plus risk analysis and prototyping
preceding each phase and evaluation following each phase




Inner cycles denoting early system analysis and prototyping
Outer cycles denoting the rest of the classic waterfall
If all risks cannot be resolved, the project is immediately
terminated
Appropriate only for big projects (high management
overhead)

First proposed by Boehm in 1987
2. Software Lifecycle and Process Models

Transformation models


Many variations of process models have been
proposed, and appear in the proceedings of the
international software process workshops
Include fully interconnected life cycle models that
accommodate transitions between any two
phases subject to satisfaction of their pre- and
post-conditions, as well as compound variations
on the traditional life cycle and continuous
transformation models.
2. Software Lifecycle and Process Models

RUP: There are three central elements that define
RUP

1. An underlying set of principles for successful software
development.


2. A framework of reusable method content and process
building blocks.


These principles are the foundation on which the RUP has
been developed.
A family of method plug-ins defines a method framework from
which you create your own method configurations and tailored
processes.
3. The underlying method and process definition language.

A unified method architecture meta-model that provides a
language for describing method content and processes.
2. Software Lifecycle and Process Models

RUP Components




Six best practices
Four phases
Static structure of the process
Nine workflows


Core process workflows
Core supporting workflows
2. Software Lifecycle and Process Models

Agile: Agile proponents believe

Current software development processes are too
heavyweight or cumbersome


Current software development is too rigid



Too many things are done that are not directly
related to software product being produced
Difficulty with incomplete or changing requirements
Short development cycles (Internet applications)
More active customer involvement needed

CMM focuses on process
2. Software Lifecycle and Process Models

Agile

Agile methods are considered



Several agile methods




Lightweight
People-based rather than Plan-based
No single agile method
XP most popular
No single definition
Agile Manifesto closest to a definition


Set of principles
Developed by Agile Alliance
2. Software Lifecycle and Process Models

Use of the Models in Practice
3. Principles and Methodologies of
Software Development

From Principles to Tools
TOOLS
METHODOLOGIES
METHODS AND
TECHNIQUES
PRINCIPLES
3. Principles and Methodologies of
Software Development

Methodologies

Notation



Technology




Approach to solve problem of modeling, composite of many technologies
For example, OOA
Methodology



Modeling things using notations
For example, Object modeling
Method


Graphic mapping of one or many technique models
For example, UML
A world view to do different work
For example object-oriented methodology
Tool


Software system which support at least one notation or technology
For example, Rational Rose
3. Principles and Methodologies of
Software Development

Methodologies

Structural Methodologies

Object- Oriented Methodologies
3. Principles and Methodologies of
Software Development

现实世界的复杂模型


复杂总是简单部分的组合
简单部分又是更简单部分的组合




简单组成复杂的过程存在层次性
每个最小简单部分独立负责完成一系列相关任务
相比较而言，每个组合内部各部分的关系比其内部
与外部的关系都更紧密
各个部分通过一致的接口进行组合，即一个部分对
其它部分的所知仅仅是接口
3. Principles and Methodologies of
Software Development


结构化
 复杂世界－>复杂处理过程（事情的发生发展）
 简单－>过程（可表达的“函数”）
 简单－>复杂（函数调用）
面向对象
 任何系统都是能够完成一系列相关目标和任务的对象
 对象完成一个任务时会请求一系列其他对象帮助其完成一些子目标
 其他对象为了完成其任务又会请求将子目标更细分为子子目标，并
请求其他对象帮助完成
 子目标的分解和责任分担一直进行直到最后产生的子部分可以映射
到计算实体
 计算实体：对象
 层次关系：聚合（组合）、继承
 组合接口：一个对象暴露的接口
3. Principles and Methodologies of Software Development
－－Core Software Engineering Principles

Provide value to the customer and the user



KIS—keep it simple!






User-centric
Value-based
Engineering perspective: Cost-Benefit Effective
Maintain the product and project “vision”
What you produce, others will consume
Be open to the future
Plan ahead for reuse
Think!
3. Principles and Methodologies of Software Development
－－

Communication Practices
Principles










Listen
Prepare before you communicate
Facilitate the communication
Face-to-face is best
Take notes and document decisions
Collaborate with the customer
Stay focused
Draw pictures when things are unclear
Move on …
Negotiation works best when both parties win.
3. Principles and Methodologies of Software Development
－－

Planning Practices
Principles










Understand the project scope
Involve the customer (and other stakeholders)
Recognize that planning is iterative
Estimate based on what you know
Consider risk
Be realistic
Adjust granularity as you plan
Define how quality will be achieved
Define how you’ll accommodate changes
Track what you’ve planned
3. Principles and Methodologies of Software Development
－－



Modeling Practices
We create models to gain a better understanding of
the actual entity to be built
Analysis models represent the customer
requirements by depicting the software in three
different domains: the information domain, the
functional domain, and the behavioral domain.
Design models represent characteristics of the
software that help practitioners to construct it
effectively: the architecture, the user interface, and
component-level detail.
3. Principles and Methodologies of Software Development
－－

Analysis Modeling Practices
Analysis modeling principles





Represent the information domain
Represent software functions
Represent software behavior
Partition these representations
Move from essence toward implementation
3. Principles and Methodologies of Software Development
－－

Design Modeling Practices
Principles








Design must be traceable to the analysis model
Always consider architecture
Focus on the design of data
Interfaces (both user and internal) must be designed
Components should exhibit functional independence
Components should be loosely coupled
Design representation should be easily understood
The design model should be developed iteratively
3. Principles and Methodologies of Software Development
－－

Construction Practices
Preparation principles: Before you write one
line of code, be sure you:





Understand of the problem you’re trying to solve (see
communication and modeling)
Understand basic design principles and concepts.
Pick a programming language that meets the needs of
the software to be built and the environment in which it
will operate.
Select a programming environment that provides tools
that will make your work easier.
Create a set of unit tests that will be applied once the
component you code is completed.
3. Principles and Methodologies of Software Development
－－

Construction Practices
Coding principles: As you begin writing code, be sure you:








Constrain your algorithms by following structured programming
[BOH00] practice.
Select data structures that will meet the needs of the design.
Understand the software architecture and create interfaces that are
consistent with it.
Keep conditional logic as simple as possible.
Create nested loops in a way that makes them easily testable.
Select meaningful variable names and follow other local coding
standards.
Write code that is self-documenting.
Create a visual layout (e.g., indentation and blank lines) that aids
understanding.
3. Principles and Methodologies of Software Development
－－

Construction Practices
Validation Principles: After you’ve completed
your first coding pass, be sure you:



Conduct a code walkthrough when appropriate.
Perform unit tests and correct errors you’ve uncovered.
Refactor the code.
3. Principles and Methodologies of Software Development
－－

Construction Practices
Testing Principles





All tests should be traceable to requirements
Tests should be planned
The Pareto Principle applies to testing
Testing begins “in the small” and moves toward
“in the large”
Exhaustive testing is not possible
3. Principles and Methodologies of Software Development
－－

Deployment Practices
Principles





Manage customer expectations for each increment
A complete delivery package should be assembled
and tested
A support regime should be established
Instructional materials must be provided to endusers
Buggy software should be fixed first, delivered later
The End

Recommend paper


《Process Models in Software Engineering》
Next Lecture

Requirements Engineering