【软件工程导论】软件工程导论笔记

Overview

History of software technology

The raise of Software Engineering

The nature of software

what is software

include

1. program
2. document
3. data structure

Tradition programing

software = algorithm + data structure

OO Programing

software = object + message

Component orient Programing

Software = component + architecture

Modern view

1. instruction that when executed provide desired feature function and performance
2. data structure that enable programs manipulate information
3. documentation that describe the operation and use of the programs

The nature of software

Development

Hardware	Software
once built difficult to modify	routinely modify and upgraded
more people allowing accomplish more work	doesn’t hold true in software engineering
Concentrate in production	concentrate in design

Deteriorate

different failure rate curve

custom built

Hardware	Software
Component base	Custom built
typically employed many standardlized design component	continus to be custome built and may move to component based
One deliver	Software as a service

Complex

Cloud Computation

1. Cloud computing provides distribute data storage and processing resource to networked computing device
2. competing resources reside outside the cloud and have access to a variety of resources inside the cloud
3. Cloud computing require developing an architecture containgin both frontednd and backend inside the cloud
4. fronteend service include the client devicesand application software to allow access
5. backend servide include servers, data storage, and server-resident application
6. cloud architecture can be segmetnted to restrict access to private data

Concept of software engineering

Soft ware crisis & what happens

Software Process

A process degines who is doing what, when, and how to reach a certain goal.

Why we need software processes

Software lifecycle

Umbrella/Framework activities

1. software project tracking and control
2. risk management
3. software quality assurance
4. technicla rebiew
5. measurement
6. software configeration managemetn
7. reusability management
8. work product preparation and production

Software process structure

Process patterns

1. describes a process-related problem that is encounted during software engineering work
2. idetifying the environment in which the problem has been encountered
3. suggests one or more proven solutions to the problems

Stage patterns

defines a problem associated with a frame work activity for the process

2. Task patterns

define a problem associating with a software engineering action or work task relevant to successful software practice

Phase pattern

define the sequenceof framework activities that occure with the process,even hte overall flow is iterative in nature

CMMI(Capability Maturity Model Integration)

• A proposed by the SEI(Software Engineering Institution)
• CMMI is a collection of best practices that meet the needs of organization in different areas of intrests

CMMI stages

1. Initial
2. Management
3. Defined
4. Quantitatively managed
5. Optimized

Process Models

• process framework
• framework activity
• • work task
  • work products
  • milestones and deliveriables
  • QA checkpoints
• umbrella activities

prescriptive process model

The waterfall model& the V model

The waterfall model

Features

1. 从上一项活动中接受该项活动的工作成果，作为输入
2. 利用这一输入实施该项活动应完成的内容
3. 给出该项活动的工作成果，作为输出传给下一项
4. 对该项活动实施的工作进行评审，若其工作得到确认则继续进行下一项活动

Advantage

1. 强调开发的阶段性
2. 强调早起计划及需求调查
3. 强调产品测试

Disadvantage

1. 瀑布模型过于依赖早起进行的唯一一次需求调查，不能适应需求的变化
2. 瀑布模型是单一流程，开发中的经验教训不能反馈应用与本产品的过程

The V model

The Evolutionary model

prototyping

Why

1. business requirement often change
2. tight market deadline, only allow a limited version
3. only core requirement are defined

Prototype

软件原型是软件的最初版本，以最少的费用、最短的时间开发出的、反映最后软件特征的系统

Feature

1. 是一个可实际运行的系统
2. 没有固定的生存期，可能被扔掉或作为最终产品的一部分
3. 从需求分析到最终产品都可作为原型，即可为不同目标作原型
4. 必须是快速、廉价
5. 他是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可

Catagory

1. 探索性：其目的是要弄清系统的要求，确定所希望的特性，并探讨多种方案的可行性
2. 实验型：其目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠
3. 演化性其目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统、

advantage

1. 一开始就能弄清楚所有产品的需求，或者至少可以帮助应导出高质量的产品需求。
2. 可在项目早期就获取项目的相关数据，尽早进行项目的风险管理和配置管理
3. 心理上：开发人员早日见到产品的雏形，是一种鼓舞
4. 使用户在新的一批功能开发测试后，立即参加验证，以提供非常有价值的反馈
5. 可使销售工作可能提前进行，因为可以在产品开发的中后期取得包含了主要功能的产品原型向客户展示和使用

disadvantage

1. 若缺乏管理的话，这个生命周期模型很可能退化成”试-错-改“的循环模式
2. 心理上，可能产生一种影响尽最大努力的想法，认为可能不能完成全部功能，但还是造出了有部分功能的产品。
3. 如果不加控制地让用户接触开发中尚未测试稳定的功能，很可能对开发人和用户造成负面影响

The spiral

1. Using the spiral model, software is developed in a series of evolutionary releaes
   • the early release might be a paper model or a protortype
   • the latter release can be more complete version
2. unlike other model that end when software is delivered, the spiral model can be adapted to apply throughout the life of the software
3. 在螺旋模型中，维护只是螺旋模型的另一个周期，在维护和开发之间并没有本质上的区别，从而解决做太多测试和未做足够测试所带来的风险

advantage

1. 强调严格的全过程风险管理
2. 强调各阶段开发质量
3. 提供机会检讨项目是否有价值继续下去

disadvantage

1. 必须映入非常严格的风险识别，风险分析和风险控制
2. 对风险管理技能水平高要求
3. 需要大量的人员、资金、时间投入

diagram

Concurrent

diagram

features

1. Concurrent development model (Concurrent Engineering)
2. It defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks.

features

1. modern computer software is characterized by continual change, by very tight timelines, and by an emphatic need for customer/use satisfaction
2. the intend of evolutionary models is to develop high-quality software in an interactive or incremental manner
3. it’s possible to use an evolutionary process to emphasis flexibility, extensibility, and speed of development

The increment models

1. definition

1. 增量模型又称产品改进模型
2. 从给定需求开始，通过构造一系列中间版本来实施开发活动，依次类推，直到系统完成。
3. 每一个中间版本都是需求分析、设计、编码和测试的过程。
4. 某些中间版本的开发可以并行进行。

diagram

features

1. 融合了线性顺序模型的基本成分和原型的迭代特征。
2. 是随着日程时间的进展而交错的线性序列。
3. 与原型不一样的地方是强调每个增量均发布一个可操作产品。
4. 最典型的应用是同一个产品的不同项目(合同、用户)版本

advantage(适用于)

1. 需求经常变化的软件开发
2. 市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发
3. 增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术

Other process Models

catagory

1. Component based development—the process to apply when reuse is a development objective
2. Formal methods—emphasizes the mathematical specification of requirements
3. AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects
4. The Unified Process (UP)

The unified Process

process

1. 初始阶段(Inception)为系统建立业务案例并确定项目的边界。
2. 细化阶段(Elaboration)分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。
3. 构造阶段(Construction)所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。
4. 交付阶段(Transition)确保软件对最终用户是可用的。

diagram

Agile development

Manifesto for agile software development

values

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Agility and the cost of change

An agile process

1. Is driven by customer descriptions of what is required (scenarios)
2. Recognizes that plans are short-lived
3. Develops software iteratively with a heavy emphasis on construction activities
4. Delivers multiple ‘software increments’
5. Adapts as changes occur

Agility priciples

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

Extreme programming/Scrum?Kanbam

Extreme programming

main activities

1. XP planning
2. XP design
3. XP coding
4. XP testing

diagram

Extreme planning

1. Begins with the creation of user stories
2. Agile team assesses each story and assigns a cost
3. Stories are grouped to for a deliverable increment
4. A commitment is made on delivery date
5. After the first increment project velocity (速度) is used to help define subsequent delivery dates for other increments

Extreme Design

1. Follows the KIS principle(Keep It Simple)
2. Encourage the use of CRC cards
3. For difficult design problems, suggests the creation of spike solutions — a design prototype
4. Encourages refactoring — an iterative refinement of the internal program design

extreme coding

1. Recommends the construction of a unit test for a story before coding commences (测试驱动编程)
2. Encourages pair programming(结对编程)

extreme testing

1. All unit tests are executed daily(强调Daily Building，冒烟测试)
2. Acceptance tests are defined by the customer and executed to assess customer visible functionality(强调验收测试，回归测试)

Scrum

distinguishing features

1. Development work is partitioned into “packets”
2. Testing and documentation are on-going as the product is constructed
3. Work occurs in “sprints” and is derived from a “backlog” of existing requirements
4. Meetings are very short and sometimes conducted without chairs
5. “demos” are delivered to the customer with the time-box allocated

diagram

团队模型

Scrum Master

1. 保证Scrum团队可以遵守；Scrum的价值，实践和规范
2. 帮助Scrum团队和组织采用Scrum模式进行项目流程组织；
3. 指导并带领团队变得更加高效，实现更高质量；
4. 保护团队不要受到外界因素的干扰；
5. 保证各个不同角色之间的良好写作，消除障碍；
6. 帮助PO更好地利用团队的能力；
7. 不要管理团队。

Product Owner

1. PO 是一个人并只能由一个人来担任；
2. 负责管理产品待办事项表（Product Backlog）并保证其对于客户和团队保持透明度；
3. 对产品代办事项表进行优先级排序；
4. 与团队一起来进行工作量估算；
5. 对于项目的成功负责并保证投资回报率 （ROI）。

团队

1. 最佳团队大小：5-9 人；
2. 多功能团队：程序员，测试人员，设计师，数据库管理员和架构师；
3. 保证团队成员全职参与开发
4. 自我管理，没有头衔之分，不组建子团队；
5. 成员更替只能在迭代之间进行，最佳方式是在发布之间进行。

Scrum 三种工件

产品Backlog

1. 产品需求变动的唯一来源
2. 动态，永不完整, 持续更新
3. 有序，排序越高越清晰具体; 排序越低， 细节越少
4. 每个产品一个, 与团队数量无关
5. 产品负责人负责管理其内容, 可用性和排序

Sprint Backlog

1. 包含产品待办事项列表中当前 Sprint 的子集
2. 包含完成 Sprint 目标所需的任务细节
3. 开发团队可视情况增加或移除任务

产品增量

1. 当前 Sprint 完成的产品待办事项列表, 以及之前所产生增量的总和
2. 必须达到"完成"的标准
3. 无论是否发布, 必须是可用的

Scrum 过程模型 （5个活动+1个合约）

kanbam

基于产品研发等不同视角的价值流，看板可以划分为多层视图，更好的管理产品的价值的流动。

category

1. 产品级看板：基于产品视角看到的研发价值流，这是每个项目开展精益看板时，首先要分析和建立的看板系统。管理产品特性的流动。
2. 团队级看板：基于设计团队、开发团队、SIT测试团队的价值流视图，这是团队开展和改进的视图。精细化管理需求在设计阶段、Story开发、需求测试的流动。

Human Aspects of software engineering

no important

Understanding requirements

System engineering

1. 通过处理信息来完成某些预定义目标而组织在一起的元素的组合
2. 对于用户而言有意义的事可以达到预期目标的系统而不是单一的软件
3. 组成基于计算机的系统有：软件、硬件、人员、数据库、文档、规程

Requirements engineering

Process

Inception

Definition

A set of question that establish

1. basic understanding of problem
2. the people who want a solution
3. the nature of the solution that is design
4. the effectness of preliminary communication and collaboration between the customer and the developer

process

1. identify stakeholder

2. recognize multiple point of view

3. work toward collaboraton

4. the first question

   1. who is behind tehe request for this work
   2. who will use the solutiohn
   3. what will be the economic benefit of successful solution
   4. is there any sorce for the solutrion tath you need

Elicitation

definition

elicit requirement from all skaeholder

priniciple

1. meeting are coducted and attended by both software engineering and customer
2. rules for preparation and participatation are established
3. an agenda is suggested
4. a facilitator controlsthe meeting
5. a “definition mechanism” (can be work sheets, flip charts, or wall stckers or an electronic bulletin board,caht room or virtual forum) is used

The goal

1. to identify the problem
2. propose elements of the solution
3. negotiate different approaches
4. apecify a preliminaryu set of solution requirement

work products

1. a statement of need adn feasibility
2. a bounded statement of scope for the system or the product
3. a list of customers, users, adn other stakeholders who participated in requirement elicitation
4. a desvription of the system’s technical environment
5. a list of requirement adn the domain constains taht apply to each
6. an prototype developed to better define requirements

Elaboration

creat a analysis model that identifies data, function and behavioral requirement

Negotiation

definition

agree on a feliverable system that is realistic for developer and customer

process

1. identify the key stakeholder: theser are the prople who will be involved in the negotiation
2. determine each of the stakeholders “win condition”: win condition are not always obvious
3. negotiate: work toward a set of requirements taht lead to “win-win”

Specification

definition

can be any one of the followering

1. a written document
2. a set of models
3. a formal mathematical
4. a collection of user scenarios
5. a prototype

relation

content

1. 引言：陈述目标软件，在基于计算机的系统语境内进行描述
2. 信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流、结构
3. 行为描述：描述作为外部事件和内部产生的控制特征的软件操作
4. 检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，测到什么样的结果，就表示系统已经成功实现了，他是“确认测试”的基础。
5. 参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献及标准
6. 附录：包含了规约的补充信息，表格数据，算法的详细描述，图表以及其他材料

Validation

definition

a review mechanism that look for

1. errors in content or interpretation
2. areas where clarification may be required
3. missing information
4. inconsistencies
5. Conflicting or unrealistic requirement

process

1. is each requirement sonsistent with the overall objective for the system/product
2. have all requiremtnt been specified at the proper level of abstraction? that is , do some requirements provide a level technical detail taht is inappropriate at this stage
3. is the requiremetn really necessary or does it represent an add-on feature that may not be essential to the objective of teh system
4. is each requirement bounded and unambiguous
5. does each requirement have attibution: taht is, is a source noted for each requirement
6. do any requirement conflict with other requirement
7. is wach requirement achieveable in the technical rnvironment that will house the system or product
8. is each requirement testable, once implemented
9. does the requirements model proprely reflect the information, funciton and behavior of the system to be built
10. has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system
11. have requirement patterns been used to simmplify teh requiremens model. habe all patterns been properly balidated: are all patterns consistent withe customer requirement

Requirement management

requiremetn monition

1. distributed debugged: uncover errors and determines their cause
2. run-time verfication: determines whether software meets user goal
3. runtime validation: assesses whether evolving software meets their goal
4. business activity monitoring: evaluate wheterh a system satisfies goals
5. evolution and co-design: provide information to stakeholders as the system evolves

Non-functional requirements

Diagrams

Requirement modeling

Domain Analysis

目标

1. 描述客户需要什么
2. 为软件设计奠定基础
3. 定义在软件完成后可以被确认的一组需求

Scenario-based modeling

use case

1. scenario that describe a “thread of usage” for a system
2. actors represent roles perple or devices play as teh system function
3. users can play a number of different roles for a given scenario

activity diagram even swimming lane diagrams

Class-based modeling

Content

nouns and verbs

1. classes are determined by noun or nouns phrase

Menifestation of analysis classes

1. external entities
2. things
3. occurences or events
4. roles
5. organization units
6. places
7. structures

potentcial classes

1. retaineed information
2. needed serbices
3. multiple attribure
4. common attribute
5. common operations
6. essential requirements

attriburtes and operation

attribute

attribure describe a class that has been selected for inclusion in the analysis model

operation

source

1. do a grammatical parse of a processing narrative and look at the verbs

catagory

1. manipulate data
2. perform a computation
3. inquire about the state of an object
4. monitor an object for the occurence of controlling event

Class Responsibility Collaborator(CRC) models

usage

provides a simple means for identifying and organizing the classes that are relevant to system or production requirements

modeling

1. A CRC model is really a collection of standard index cards that represent classes
2. the cards are divided into three sections: class name, responsibility, collaborator

example

Behavioral modeling

mainly include state diagram and sequence diagram

Design concepts

design and qauality

goal

1. teh design must implement all of the explicit requirement
2. the design mustt be readable, understandable guide
3. the design should provide a complete picture of software

quality guide line

1. design should exhibit an architecture that
   1. has been created using recognizable architectureal styles or patterns
   2. is composed of components that exhibit good design characteristics
   3. can be implement in an evolutionary fashion
2. A desin should be modular
3. a design should contain distinct representation
4. a design should lead to data structure that are appropriate for the classes to be implemented and are drawn from recognizable data patterns
5. a design should lead to components that exhibit independent functional characteristics
6. a design should lead to interfaces that reduce the complexity of connections between components and with the external ecvironment
7. a design should be derived using a repeatable method that is derived by information obrtained during software requirements analysis
8. a design should be represented usingt a notation that effectively communicated its meaning

design principle

lazy

Fundamental concept

1. abstraction: data procedure, control
2. architecture: the overall structure of the software
3. patterns: convey the essence of a proven design solution
4. separation of concerns: any complex problem can be more easily
5. modularity: compartmentalization of data and function
6. hiding: controlled interfaces
7. functional independence: single minded function and low coupling
8. refinement: elaboration of detail for all abstraction
9. aspects: a mechanism for understanding how global requirements affect design
10. refactoring: a reorganization technique that simplifies the desin
11. OO desing concepts:
12. desing classes: provide design detail that will enable analysis classes to be implemented

design model

OO Concepts

design classes

1. entity classes : refined from analysis class
2. boundary classes: developed during desing to create the interface
3. controller classes:are desing to manage
   1. the creation or update of entity objects
   2. the instantiation of boundary objects as they obtain information from entity objects
   3. complex communication between set of objects
   4. validation of data communicated between objects or between the user adn teh appplication

inheritance

all responsibilities of a superclass is immediately inherited by all subclasses

Messages

stimulate some behavior to occur in the receiving object

Polumorphism

a characteristic that greatly reduces the effort required to extend the design

Design methods

Architecture Design

What is architecture

the software architecrure of a program or comprting system is the sruucture or structures of teh system, which comprise the software components, teh externally visible properties of those components, and the relationships among them

Architecture style

Encompass

1. a set of components that perform a funciton required by a ssytem
2. a set of connector that enablecommunication coordination and cooperation among components
3. constraints that define how components can be integrated to form the system
4. semantic models that enable a desiner to understand teh overall properties of a system by analyzing the known properties of its constituent parts

catagory

1. data-centered ar5chitectures
2. data flow architecture
3. call and return architecture
4. object oriented architecture
5. layered architecture

Architecture design

1. the software myst be placed into context
2. a set of architectureal archetypes should be identified
3. the designer specifies the structure of the system by defining and refining software

Agility and architecture

1. to avoid rework, user stories are used to create and evolve an architecrural model before coding
2. hubrid models which alow sogtware arhchitects contributing users stories to the evolving storyboard
3. well run agil projects include delivery of work products during each spring
4. review code emerging from the sprint can be a useful form of architecrural review

Component level design

What is a component

1. OO view: a set of collaborating classes
2. process logic, the internal data structure and an interface

Basic design pricinple

The open-closed principle

open for extension and clossed for modification

The Liskov subsititution principle

subclasses should be substitudable for their base classes

Dependency inversion principle

depend on abastaction rather than concretion

The interface segregation principle

many client-specific interfaces are better than one general purpose interface

Cohesion and Coupling

Cohesion

definition

cohesion implies that a component or class encapsulate only attribures and operations that are closely related to one another and to the class or component itself

level of cohesion

1. functional
2. layer
3. communicational
4. sequential
5. procedural
6. temporal
7. utility

Coupling

definition

a qualitative measure of the degree to which classes are conneted to one another

level of coupling

1. content
2. common
3. control
4. stamp
5. data
6. routine call
7. type use
8. inclusion or import
9. external

Component-based software engineering

principle

1. a library of components must be avaialbe
2. components should hava a consistent structure

activity

1. component qualification
2. component adaptation
3. component composition
4. componoent update

User interface design

Golden rules for UI design

User intgerface design process

interface analysis

Design evaluation cycle

Software quality

What is quality

1. an effective sotwware process applie in a manner that cteates a userful product that provides measurable valuse for those who produce it and those who use it

McCall’s triangle of quality

The cost of quality

Achieving software quality

achieving

1. sotware quality is the result of good project management and solid engineering practice
2. to build high quality software you must understand the proble to be solved and be capable of creating a quality design the conforms to the problem requirement
3. eliminating architectural flaws during desing can improve quality

assurance

1. project management: project plan includes explicit techniques for quality and change management
2. quality control: series of inspections, reviews, and tests used to ensure conformance fo a work product ro its specification
3. quality assurance: consists of the auditing and reporting procedures used to provide management with data needed to make proactive decisions

Testing strategy and techniques

Testing concepts

1. verification: refer to the set of tasks that ensure thath software correctly implements a specific function
2. validation: refer to a different set fof tasks that ensure that the software that has been built is traceable to customer reuqirement

V model and V&V

the v model

the v&v model

Testing Strategies

diagram

strategy

conventional software

1. teh module is our initial focus
2. integration of modules follows

for oo software

our focus when “testing in small” changes form an individual module to an OO class that encompass attributes and operations and implies commnunication and collaboration

time line

Testing techniques

testing steps

1. before developing a test, we should identifu the foals of the test
2. decide how to carry out a relevant test. We have to decide which test is teh most suitable and what sort of test items need to be used
3. develop teh test case
4. determine the expected results of the test
5. execute the test cases
6. ccompare teh test results to the expected result

driver

provide

1. setting input parameters, and the environment
2. executing the unit
3. reading the output parameters

typical behavior

1. suply a constant input or a random input
2. supply a ‘canned’ input
3. record interim results and traces

stub

provide

1. the unit under test may depend on another component that may not have been completed yet or would introduce undesirable into the test. Stub simulate part of the program called by the unit

typical behavior

1. exit immediately

2. return a constant ouput or a random output

3. return a value from the user

4. print ‘module x entered’

bottom-up strategy

sandwich testing

regression testing

re-execution of some subset fo tests that have already been conducted to ensure that changes have not propagated unintended side effects

smoke testing

a common aproach for creating “daily builds” for product software

OO testing strategy

1. operation within the class are tested
2. the state behaviro of teh calss is examined
3. thread-base testing
4. use-based testing
5. cluster testing

Security engineering & SCM

Why security engineering

1. security is a perquisite to system integrity, availability, reliablity and safety
2. security provides teh mechanism that enable a system to protect its assets from attack
3. assets are system resources that have value to its stakeholders
4. attacks take advatage of bulnerability that allow unauthorized system access
5. it is different to make a system more secure by responding to buging reports, security must be designed in from the beginning testing appropriate

SCM concepts

Baselines

definition

a specification or product that has been formaly reviewed and agreed upon, that thereafter serves as teh vbasis for futher development, and that can be changed only through formal change control procedures

SCI

SCM process

diagram

Project managemetn concepts

4P

1. people: the most important element of a sucessful project
2. product: teh software to be beilt
3. process:teh set fo framework activities and software engineering tasks to get tehjob done
4. project: all work required to make teh product a reality

$W^{5}HH$

1. why is teh system being developed
2. what will be done
3. when will it be accomplished
4. who is responsible
5. where are they organizationlly located
6. how will teh job be done technically and managerially
7. how much of each resurce will be needed

Process and project metrics

Why do we measure

1. assess teh status of an ongoing project
2. track potential risks
3. uncober problem areas beform they go critial
4. adjust work flow or tasks
5. evaluate the project team’s ability to control quality of software work products

Process measurement and metrics

measurement

1. outcome

process metrics

1. quality related
2. productivity-related
3. statistical SQA data
4. defect remocal efficiency
5. reuse data

Project metrics

1. input:measures of teh resources required to do the work
2. output: meawsures of teh deliverable or work prodducts ctreated during teh softwre engineering proceess
3. results: measures that inducated teh effectiveness of the deliverable

typical of metrics

1. error per unit
2. defect per unit
3. pages of document per unit
4. errors per person-month
5. errors per review person-month

Project estimation & Scheduling

Scope

definition

scopes refer to all teh work involved in creating teh products of the project and teh processes used to cteated them

describe

the software socpe describes

1. the funcitons adn features that are to be delivered to end-users
2. the data that are intput adn output
3. the “content” that is presented to users as a consequence of using teh software
4. teh performance, constrains, interface, and reliablity that bound the system

mian techniques

1. a narrative description of software socpe is developed ager commnucation with all stakeholders
2. A set of use-case is developed by end-user

Work Breakdown Structure (WBS)

definition

a work breakdown structure is a deliverabl-oriented grouping of the work involved im a project that defines teh total scope of the project

int provides the basis for

1. planning and managing project schedules, costs, and changes
2. risk analysis
3. organizaitonal structure
4. measurement

Line Of Code(LOC)

advantage

1. simple to measure
2. easy to automate

disadvantage

1. only defined for code, not teh design
2. bad desing may cause excessive LOC
3. Language dependent
4. Does not account for functionality or complexity

Function Point (FP)

advantage

1. usable in teh earliest requirements phases
2. independent of programming language, product desing, or development style
3. user’s view rather than miplementation view
4. can be used to measure thenon-coding activities
5. There exists a large body of historical data
6. a well documented method

disadvantage

1. cannot directly count an existing product’s FP content
2. Hard to automate
3. FP do not reflect language, desing, or style differences
4. FP are desinged for estimating commercial data processing applications
5. subjective counting

Constuctive Cost Modeling (COCOMO) estimation

use experience to estimate

Scheduling steps

1. defining task sets
2. sequencing activities
3. drawing project network diagrams
4. crutical path analysis
5. using Gantt chats for scheduling
6. shcedule tracking

Task network

Gantt charts

Milestone

you know what is milstome right?

Risk analysis

Project risk

catagory

1. Project risk
2. technical risk
3. business risk
   1. marketing risk
   2. strtegic risk
   3. management risk
   4. budget risk

Reactive Risk Management

1. mitigation: plan for additional resources in anticipation of fire fighting
2. fix on failure: resource are found and applied when the risk strikes
3. crisis management: failure does not respond to applied resources and project is in jeopardy

Proacctive risk management

1. formal risk analyssi is performed
2. organization correct the root cause of risk
   1. TQM concepts and statistical SQA
   2. examining risk sources that lie beyond the bounds of the software
   3. developing the skill to manage change