Computing and SE II Chapter 3: Software Development Activities Er-Yu Ding Software Institute, NJU.

Computing and SE II

Chapter 3: Software Development Activities

Er-Yu Ding

Software Institute, NJU

Main Contents

1. Activities of Software Development

2. Software Lifecycle and Process Models

3. Principles and Methodologies of Software Development

1. Software Development Activities

Problems

Solution( Software)

What we intend

Expected world

1. Software Development Activities Problems/Solutions

Real world analysis Problem design Solution

General machineSolution machine

Implementatio

n

, Test

Installingmaintaining

MethodsTechniquesLanguages

Tools…

1. Software Development Activities

RequirementsAnalysis

Implementation

Design

Testing

Installing and Maintenance

1. Software Development Activities Requirements Analysis Requirements Engineering

目的：描述明确的问题域特性 E; 定义良好的系统行为 S ; 预期的需求 R 需求工程的目的就是根据 E ，构建 S ，使得

需求工程的困难之处：（ 1 ）不存在描述明确的 E ；（ 2 ）不存在确定的针对 S 的评估标准 R ；（ 3 ）是一个创造性的过程。

需求工程的主要工作研究问题背景，描述问题域特性 E 需求开发 , 确定 R 构建解系统，描述解系统行为 S ，使得

理解现实为第一目的，保证 S 的质量为第二目的 Mainly Result : SRS (Software Requirements Specification)

RSE ,

SRE ,

RSE ,

“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

The definition of the global architecture of the system Detail (System) Design

System is decomposed in components Definition of component functionalities Definition of component interfaces

HCI Design Making interfaces usability

Design decisions dramatically impact system quality 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 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 does not necessarily follow the implementation phase

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 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. Tasks

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 TeamSoftware development steps Developer

Requirement Analysis Analyst

Architecture Design Architect

Detail (system) DesignDesigner

HCI Design

Program design

ProgrammerProgram implementation

Unit testing

Testing design

Tester Integration testing

System (accept) testing

Installing (System deliver) Trainer and SupporterMaintenance

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)

Development – 25%

Post-Delivery Maintenance – 75%

Total Product CostsBreakout of

Development Costs

Integration – 29%

Implementation/Coding – 34%

Design – 19%

Requirements &Analysis – 18%

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 No planning or analysis The working program is

the only work product Advantage

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 Sequential steps (phases) Feedback loops (between two phases in

development) Documentation-driven

Advantages Documentation and clearly defined phases

Disadvantages Complete and frozen specification document up-

front 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 well-understood

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 this requires end-user participation

JAD Workshop(s): user and SWAT (Skilled With Advanced Tools) team involvement

Construction with SWAT team 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 Software is developed because the present situation is

unsatisfactory However, the desirable new situation is as yet unknown

Advantages 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. These principles are the foundation on which the RUP has

been developed. 2. A framework of reusable method content and process

building blocks. 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 Too many things are done that are not directly

related to software product being produced Current software development is too rigid

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 Lightweight People-based rather than Plan-based

Several agile methods 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


From Principles to Tools

PRINCIPLES

METHODS ANDTECHNIQUES

METHODOLOGIES

TOOLS

3. Principles and Methodologies of Software Development Methodologies

Notation Graphic mapping of one or many technique models For example, UML

Technology Modeling things using notations For example, Object modeling

Method Approach to solve problem of modeling, composite of many technologies For example, OOA

Methodology 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

User-centric Value-based

KIS—keep it simple! 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!


－－ 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.


－－ 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


－－ 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.


－－ Analysis Modeling Practices Analysis modeling principles

Represent the information domain Represent software functions Represent software behavior Partition these representations Move from essence toward implementation


－－ 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


－－ 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.


－－ 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.


－－ 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.


－－ 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


－－ 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 end-

users Buggy software should be fixed first, delivered later

The End

Recommend paper 《 Process Models in Software Engineering 》

Next Lecture Requirements Engineering

Computing and SE II Chapter 3: Software Development Activities Er-Yu Ding Software Institute, NJU.

Documents

Transcript of Computing and SE II Chapter 3: Software Development Activities Er-Yu Ding Software Institute, NJU.