Main Contents
1. Activities of Software Development
2. Software Lifecycle and Process Models
3. Principles and Methodologies of Software Development
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 (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
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
3. Principles and Methodologies of Software Development
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!
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 end-
users Buggy software should be fixed first, delivered later