BMC CMDB模型介绍
CMDB2.0_CDM_Diagram
COMMON DATA MODEL
BMC ?
Atrium
?
Subclasses inherit attributes and relationships of all superclasses.
COMPONENT RELATIONSHIP
MEMBER OF RELATIONSHIP DEPENDENCY RELATIONSHIP
ELEMENT LOCATION RELATIONSHIP
BASE LEVEL FIRST LEVEL SECOND LEVEL THIRD LEVEL
FOURTH LEVEL FIFTH LEVEL
SUPERCLASS SUBCLASS
CLASS 1 (source)
CLASS 2 (destination)
Relationship_Name
REGULAR CLASS
ABSTRACT CLASS
CATEGORIZATION CLASS
CMDB
*Use the Name attribute of BMC_BaseRelationship to further categorize relationships according to the Relationship Normalization Table in the PDF version of this diagram.
? 2006 BMC Software, Inc.
last modified: 05.11.2006BMC_Component BMC_MemberOfCollection
B M
C _E l e m e n t L o c a t i o n
BMC_AccountOnSystem
BMC_HostedAccessPoint
BMC_HostedService BMC_HostedSystemComponents
BMC_ApplicationSystemServices BMC_SegmentsInCollection BMC_LNsInCollection B M C _I n S e g m e n t
BMC_InIPSubnet
BMC_IPSubnetsInCollection
BMC_Dependency BMC_BaseRelationship
ActiveMaximumTransmissionUnit, AutoSense, FullDuplex,
LinkTechnology, MaxSpeed, NetworkAddresses PermanentAddress, PhysicalDescription, PortType, Speed,
SupportedMaximumTransmissionUnit
BMC_NetworkPort
AvailableCPs, AvailableIFAs, AvailableIFCs, AvailableIFLs, GridLocation, InstalledCPs, InstalledCPUs, InstalledDASD, NumberChannels, NumberOfLPARS, PhysicalMemory
BMC_Mainframe
AveragePagesPerMinute, HorizontalResolution, MarkingTechnology, PaperSizesSupported, PortName,
PrinterCapabilities, PrinterLanguageList, VerticalResolution
BMC_Printer
Email, Fax, FirstName, LastName, MiddleName, MobilePhone, OfficePhone, PagerEmail,
PagerParams1, PagerParams2,
PagerPhoneNumber,PagerPINNumber, PagerProvider, PagerSoftware,
PagerType, PersonAdditionalDetails, PersonDepartment, PersonRegion, SecondaryEmail, Title, WebPage
BMC_Person
Author,
DocumentAttachment, DocumentDate, DocumentStatus, DocumentType, FileName, Keywords, Locale
BMC_Document
SystemClassId, SystemName
BMC_AccessPoint
InterfaceType, Partitions, SCSIBus, SCSILogicalUnit, SCSIPort, SCSITargetID, SectorsPerTrack, Size,
TotalCylinders, TotalHeads, TotalSectors, TotalTracks, TracksPerCylinder
BMC_DiskDrive
NetworkNumber
BMC_IPXConnectivityNetwork
No Attributes
BMC_LNsCollection
resolutionDate
BMC_LAN
No Attributes
BMC_HardwarePackage
No Attributes
BMC_Product
No Attributes
BMC_SystemSoftware
No Attributes
BMC_Package
EnablerType
BMC_VirtualSystemEnabler
SourceLocation
BMC_BusinessProcess
Layout
BMC_Keyboard
No Attributes
BMC_FileSystem
Properties
BMC_SystemResource
AccessMask,
MaximumAllowed, Path
BMC_Share
SoftwareServerType
BMC_SoftwareServer
ApplicationInfrastructureType
BMC_ApplicationInfrastructure
ApplicationType
BMC_Application
No Attributes
BMC_Collection
No Attributes
BMC_LogicalEntity
PortNumber
BMC_CommunicationEndPoint
No Attributes
BMC_Card
Height, TypeOfRack
BMC_Rack
MaxComponentLength, TransferRate
BMC_CDROMDrive
No Attributes
BMC_FloppyDrive
No Attributes
BMC_TapeDrive
No Attributes
BMC_LocalFileSystem
No Attributes
BMC_RemoteFileSystem
BMC_Monitor
Bandwidth, DisplayType,
PixelsPerXLogicalInch, PixelsPerYLogicalInch,
ScreenHeight, ScreenWidth
BMC_DiskPartition
BlockSize, Bootable, NumberOfBlocks, PrimaryPartition
BMC_UPS
BatteryInstalled, InputVoltage,
IsSwitchingSupply, TimeOnBackup, TotalOutputPower,
TypeOfRangeSwitching, UPSPort
BMC_Media
Capabilities, CompressionMethod, DefaultBlockSize, MaxBlockSize, MaxMediaSize, MediaType, MinBlockSize,
NumberOfMediaSupported
BMC_WAN
count,
resolutionDate, WANType
BMC_DataBaseStorage
isSystemArea, LastBackupTime
BMC_Patch
ServicePackInEffect, SeverityRating
BMC_BIOSElement
BiosCharacteristics, PrimaryBIOS, PrimaryOS
BMC_PointingDevice
DeviceInterface, NumberOfButtons, PointingType
BMC_IPEndpoint
AddressType, PrefixLength, SubnetMask
BMC_IPConnectivitySubnet
AddressType, explorationDate, PrefixLength, SubnetMask, SubnetNumber
BMC_Processor
Level, MaxClockSpeed, ProcessorArchitecture,
ProcessorFamily, ProcessorStatus, ProcessorType, UpgradeMethod
BMC_Memory
Capacity, FormFactor,
HotSwappable, MemoryType, Removable, Replaceable, Speed
BMC_Chassis
ChassisType,
NumberOfPowerCords, RackMountable
BMC_Software
BuildNumber, BuildType, ConfigurationBasicNumber, ContractID, LicensesAvailable, LicenseType, PatchNumber, ServicePack
BMC_ConnectivitySegment
ConnectivityType, count, fixed, NetworkID,
OtherTypeDescription
BMC_LANEndpoint
AliasAddresses, GroupAddresses, LANID,
MACAddress
BMC_NTDomain
ClientSiteName, DcSiteName, DnsForestName,
DomainControllerAddress,
DomainControllerAddressType, DomainControllerName, DomainGuid, DomainName,
DSDirectoryServiceFlag, DSDnsControllerFlag, DSDnsDomainFlag, DSDnsForestFlag,
DSGlobalCatalogFlag,
DSKerberosDistributionCenterFlag, DSPrimaryDomainControllerFlag, DSTimeServiceFlag, DSWritableFlag
BMC_SystemComponent
SystemClassId SystemName
BMC_SystemService
SystemClassId SystemName
No Attributes
BMC_Equipment
ElementLocation
( many-many )
BMC_ElementLocation
No Attributes
BMC_Component No Attributes
BMC_Dependency
No Attributes
BMC_MemberOfCollection
Address, ProtocolType
BMC_ProtocolEndPoint
CommonName
BMC_Role
Count, SPOC
BMC_UserCommunity
ConnectivityStatus
BMC_ConnectivityCollection
No Attributes
BMC_BusinessService
No Attributes
BMC_Database
No Attributes
BMC_Account
ActivityType
BMC_Activity
No Attributes
BMC_LogicalSystemComponent
PathName
BMC_ApplicationService
No Attributes
BMC_AdminDomain
BMC_Organization
BusinessCategory, Email, URI
BMC_PhysicalLocation
Address, AddressAdditionalInfo, Altitude, City, CoordinateFormat, Country, FaxNumber, Latitude, Longitude,
MailStop, PhoneNumber, PhysicalPosition,
PostalCode, StateOrProvince, WebPage
BMC_ApplicationSystem
BuildNumber, PatchNumber, ServicePack
BMC_Cluster
ClusterType, Interconnect,
InterconnectAddress, MaxNumberOfNodes, Types
PNPDeviceID,
PowerManagementCapabilities, PowerManagementSupported, SystemAvailability
BMC_HardwareSystemComponent
BMC_ComputerSystem AdminPasswordStatus, BootROMSupported, CapabilityList,
ChassisBootupState, ConfigurationOptions, DataRate, DHCPUse, Dimensions, Domain,
EnvironmentSpecification, Expansion,
ExpansionInterface, firmware_version,
FlashMemory, Frequency, HostName, InputCurrent, InputVoltage,
MaxConsumption, MediaSupported,
NumberOfSlots, PortsPerSlot, PrimaryCapability,
ResetCapability, ResetCount, ResetLimit, SystemType, ThermalState,
TotalPhysicalMemory, Workgroup
AccountID, AssignedTo, AttributeDataSourceList, Availability, Category, ClassId, CMDBRowLevelSecurity, CMDBWriteSecurity, CompareActionCode, Confidentiality, CreateDate, DatasetId, deleted, DeleteInstanceTrigger, Description, FailedAutomaticIdentification, History, InstanceId, Integrity, Item, LastModifiedBy,
LastREJobrunId, LastScanDate, ManufacturerName, MarkAsDeleted, Model, ModifiedDate, Name, NameFormat, Notes, OpIdWeakReference, OwnerContact,
OwnerName, Priority, ReconciliationIdentity, ReferenceInstance, RelLeadClassId, RelLeadInstanceId, RequestId, SerialNumber, ShortDescription, Status, Submitter, Supported, TmpOpOriginationForm, TokenFormat, TokenId, Type, VersionNumber
BMC_BaseElement
AccountID, AssignedTo, AttributeDataSourceList, ClassId, CMDBRowLevelSecurity, CMDBWriteSecurity,
CompareActionCode, CreateDate, DatasetId, deleted, DeleteInstanceTrigger, Destination.ClassId, Destination.DatasetId, Destination.InstanceId, Destination.ReconciliationIdentity, FailedAutomaticIdentification, InstanceId, LastModifiedBy, LastREJobrunId, MarkAsDeleted, ModifiedDate, Name*, OpIdWeakReference, ReconciliationIdentity, ReferenceInstance, RelLeadClassId, RelLeadInstanceId, RequestId, ShortDescription, Source.ClassId, Source.DatasetId, Source.InstanceId, Source.ReconciliationIdentity, Status, Submitter
BMC_BaseRelationship
No Attributes
BMC_ApplicationSystemServices No Attributes
BMC_HostedSystemComponents No Attributes
BMC_HostedService No Attributes
BMC_HostedAccessPoint AccountType
BMC_AccountOnSystem No Attributes
BMC_InSegment
BMC_SegmentsInCollection No Attributes
BMC_IPSubnetsInCollection No Attributes
BMC_InIPSubnet
No Attributes
BMC_LNsInCollection
CountryCode,
MaxNumberOfProcesses, MaxProcessMemorySize, Organization, OSLanguage, OSProductSuite, OSType, PAEEnabled, ProductType, SuiteMask, SystemDirectory
BMC_OperatingSystem
No Attributes
BMC_System
( many-many )
( many-many )
( many-many )
( many-many )
( one - many )
( weak, one - many )
( weak, one - many )
( many-many )
( one-one )
( weak, one - many )
( one-one )
( one-one )
( one-many ) ( one-many )
No Attributes
BMC_VirtualSystem
TotalMemory,
VirtualSystemType
软件开发模型介绍与对比分析
常用的软件开发模型 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。 1. 瀑布模型-最早出现的软件开发模型 1970年温斯顿?罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。（采用瀑布模型的软件过程如图所示）
能力素质模型简介
1973年，麦克里兰博士在《美国心理学家》杂志上发表一篇文章：“Testing for Competency Rather Than Intelligence”。文中，他引用大量的研究发现，说明滥用智力测验来判断个人能力的不合理性。并进一步说明人们主观上认为能够决定工作成绩的一些人格、智力、价值观等方面因素，在现实中并没有表现出预期的效果。因此，他强调要离开被实践证明无法成立的理论假设和主观判断，回归现实，从第一手材料入手，直接发掘那些能真正影响工作业绩的个人条件和行为特征。他把这种发现的，直接影响工作业绩的个人条件和行为特征称为能力素质。这篇文章的发表，标志着能力素质运动的开端。 以麦克里兰教授为首的研究小组，经过大量深入研究发现，传统的学术能力和知识技能测评并不能预示工作绩效的高低和个人生涯的成功。同时，他们发现从根本上影响个人绩效的是诸如“成就动机”、“人际理解”、“团队领导”、“影响能力”等一些可称为能力素质的东西。小组又进一步将其明确定义为：“能区分在特定的工作岗位和组织环境中杰出绩效水平和一般绩效水平的个人特征。”三个主要特点是反映特定环境、和业绩挂钩、可客观衡量。
能力素质包括哪些东西？ 麦可利兰把能力素质划分为五个层次： 1、知识（Knowledge）：指个人在某一特定领域拥有的事实型与经验型信息 2、技能（Skill）：指结构化地运用知识完成某项具体工作的能力,即对某一特定领域所需技术与知识的掌握情况
3、社会角色（Social Roles）：指一个人基于态度和价值观的行为方式与风格 4、自我概念（Self-Concept）：指一个人的态度、价值观和自我印象 5、特质（Traits）：指个性、身体特征对环境和各种信息所表现出来的持续反应。品质与动机可以预测个人在长期无人监督下的工作状态。 6、动机（Motives）：指在一个特定领域的自然而持续的想法和偏好（如成就、亲和、影响力），它们将驱动，引导和决定一个人的外在行动 麦可利兰认为，不同层次的能力素质在个体身上的表现形式不同。我们可以把人的能力素质形象地描述为漂浮在海面上的冰山（冰山理论），知识和技能属于海平面以上的浅层次的部分，而自我概念、特质、动机属于潜伏在海平面以下的深层次的部分，而研究表明，真正能够把优秀人员与一般人员区分开的是深层次的部分。因此，麦可利兰把不能区分优秀者与一般者的知识与技能部分，称为基准性素质（Threshold Competencies），也就是从事某项工作起码应该具备的素质；而把能够区分优秀者与一般者的自我概念、特质、动机称为鉴别性素质（Differentiation Competencies）。 能力素质到底是行为特征还是心理特征？ 从本质上来说，能力素质是由个人特定的内在稳定心理特点所表现出来的外在行为特征，这种特征能区分个人在具体文化和岗位上的绩效是否优秀。它同时具有行为特点和心理特点。 但是，能力素质作为一种人力资源的应用工具，是为人力资源的具体应用服务的。如果在应用中需要强调其行为特点，能力素质就是一种行为特征，例如绩效管理，企业文化建设、知识管理方面，我们不谈能力素质的心理特点；反之，如果在
软件工程复习题及答案
2006-2007-2软件工程复习 一、单项选择题（20选10） 1. 结构化分析的主要描述手段有( B )。 A. 系统流程图和模块图 B. ＤＦＤ图、数据词典、加工说明 C. 软件结构图、加工说明 D. 功能结构图、加工说明 2. 用于表示模块间的调用关系的图叫（ D ）。 A．PAD B．SC C．N-S D．HIPO 3. 在（ B ）模型中是采用用例驱动和架构优先的策略，使用迭代增量建造方法，软件“逐渐”被开发出来的。 A．快速原型 B. 统一过程 C．瀑布模型 D. 螺旋模型 4. 常用的软件开发方法有面向对象方法、面向( A )方法和面向数据方法。 A. 过程 B. 内容 C. 用户 D. 流程 5 从工程管理的角度来看，软件设计分两步完成( D )。 A. ①系统分析②模块设计 B. ①详细设计②概要设计 C. ①模块设计②详细设计 D. ①概要设计②详细设计 6. 程序的三种基本结构是（ B ）。 A. 过程、子程序、分程序 B．顺序、条件、循环 C．递归、堆栈、队列 D．调用、返回、转移 7. 程序的三种基本结构是（ B ）。 A. 过程、子程序、分程序 B．顺序、条件、循环 C．递归、堆栈、队列 D．调用、返回、转移 8. SD方法衡量模块结构质量的目标是（ C ）。 A. 模块间联系紧密，模块内联系紧密 B. 模块间联系紧密，模块内联系松散 C. 模块间联系松散，模块内联系紧密 D. 模块间联系松散，模块内联系松散 9．为提高软件测试的效率，应该（ C ）。 A．随机地选取测试数据 B．取一切可能的输入数据作为测试数据 C．在完成编码后制定软件测试计划 D．选择发现错误可能性大的数据作为测试数据 10．( D )测试用例发现错误的能力较大。 A.路径覆盖 B.条件覆盖 C.判断覆盖 D.条件组合覆盖 11．软件需求分析应确定的是用户对软件的( A )。 A. 功能需求和非功能需求 B. 性能需求 C. 非功能需求 D. 功能需求 12．下列各种图可用于动态建模的有（ C ）。 A．用例图 B. 类图 C. 序列图 D. 包图 13．软件过程模型有瀑布模型、( B )、增量模型等。 A. 概念模型 B. 原型模型 C. 逻辑模型 D. 物理模型 14．面向对象的分析方法主要是建立三类模型，即( D )。 A. 系统模型、ER模型、应用模型 B. 对象模型、动态模型、应用模型 C. Ｅ-Ｒ模型、对象模型、功能模型 D. 对象模型、动态模型、功能模型 15．测试的分析方法是通过分析程序（ B ）来设计测试用例的方法。 A．应用范围 B.内部逻辑 C.功能 D.输入数据 16. 软件工程是研究软件( B )的一门工程学科。 A. 数学 B. 开发与管理 C. 运筹学 D. 工具 17. 需求分析可以使用许多工具，但（ C ）是不适合使用的。 A．数据流图 B.判定表 C.PAD图 D.数据字典 18．划分模块时，一个模块内聚性最好的是( A )。 A. 功能内聚 B. 过程内聚 C. 信息内聚 D. 逻辑内聚 19．软件可移植性是用来衡量软件的（ D ）的重要尺度之一。 A．效率 B. 质量 C. 人机关系 D. 通用性 20．软件配置管理是在软件的整个生存周期内管理（ D ）的一组活动。 A．程序 B.文档 C.变更 D.数据 二、判定题（20选10） 1统一过程是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。（×） 2当模块中所有成分结合起来完成一项任务，该模块的内聚是偶然内聚。（×） 3SD方法衡量模块结构质量的目标是模块间联系松散，模块内联系紧密（√） 4当模块中所有成分结合起来完成一项任务，该模块的内聚是功能内聚。（√） 5在进行需求分析时，就应该同时考虑软件的可维护性问题。（√） 6需求分析可以使用许多工具，但数据流图是不适合使用的。（×）
常见的软件开发模型
常见的软件开发模型 软件开发模型是软件开发全部过程、活动和任务的结构框架。 1.软件开发模型是对软件过程的建模，即用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，好比工厂的流水线。 2.软件开发模型能清晰、直观地表达软件开发全部过程，明确规定要完成的主要活动和任务，它用来作为软件项目工作的基础。 3.软件开发模型应该是稳定和普遍适用的 软件开发模型的选择应根据： 1.项目和应用的特点 2.采用的方法和工具 3.需要控制和交付的特点 软件工程之软件开发模型类型 1.边做边改模型 2.瀑布模型 3.快速原型模型 4.增量模型 5.螺旋模型 6.喷泉模型 边做边改模型（Build-and-Fix Model） 国内许多软件公司都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改. 在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。 这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：（1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改； （2）忽略需求环节，给软件开发带来很大的风险； （3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
瀑布模型（Waterfall Model） 1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； （3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子. 快速原型模型（Rapid Prototype Model） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。 快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。 增量模型（Incremental Model） 又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各
罗兰贝格：素质模型及其应用
素质模型及其应用
以工作分析和素质模型为基础的人力资源管理模型展示了人力资源管理的主要研究领域 人力 资源战略规划 工作分析1.岗位描述2.岗位评估 3.岗位等级体系 绩效管理 1.绩效管理流程 2.关键绩效指标 薪酬福利 1.薪酬结构设计 2.福利体系设计 3.高管薪酬 素质模型 招聘与选拔 1.招聘流程设计 2.关键岗位甄选方法 培训与发展 1.培训管理体系 2.晋升渠道建立 3.中层人员能力评估 4.关键人员培训方案 人力资源部门设置 人力资源管理信息系统 公司战略规划 1 8 3 5 4 2 6 7 研究工
课程内容与目的 ?介绍素质模型的基本概念 ?介绍建立素质模型的方法 ?介绍素质模型在人力资源领域的应用?国内外其他企业素质模型介绍与分析
智慧始于新事物的定义. 苏格拉底
素质的定义 ?素质是一组可见的和能够应用的知识，技能，行为，以及特殊情况下个人个性特征的组合，这个组合能够最终为公司带来持续的竞争优势 ?素质强调的是员工如何创造价值，而不是员工已经做过什么 ?知识: 对具体领域的深刻理解，通常是通过正规的教育，职业培训以及工作渠道获得 ?技能: 进行某项体力或脑力劳动的能力或者熟练程度；一项技能通常通过针对性的学习获得并且通过测试之后应用 ?行为: 可观察的行动和表情 ?个性特征: 阻止或者导致事情发生的性格或持续不断的反应。这些性格或反应通常不能直接观察到或者被评估。正常情况下，这些特征也无法通过培训得到改进。
素质举例： ?知识–会计, 市场营销，工程 ?技能–机械操作, 制定预算, 制作文本文件，解决问题，谈判，沟通 ?行为–配合，同情心, 冒风险, 团队合作 ?性格特征–诚实，遵守道德, 自信, 自我调整
常用软件开发模型比较分析
常用软件开发模型比较分析 2007-09-26 20:21 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ① 以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ② 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。 ③ 以形式化开发方法为基础的变换模型（T ransformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。
图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下且呈线性图式的，因此瀑布模型存在严重的缺陷。 ① 由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样软件与用户见面的时间间隔较长，也增加了一定的风险。 ② 在软件开发前期末发现的错误传到后面的开发活动中时，可能会扩散，进而可能会造成整个软件项目开发失败。 ③ 在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。 1.2.2 螺旋模型螺旋模型将瀑布和演化模型（Evolution Model）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。这
软件开发模型的优缺点和适用范围
软件开发模型的优缺点和适用范围 软件开发模型大体上可以分为三种类型。第一种是以软件需求完全确定为前提的瀑布模型；第二种是在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如原型模型、 螺旋模型等；第三种是以形式化开发方法为基础的的变换模型。时间中经常将几种模型组合使用， 以便充分利用各种模型的优点。 1. 瀑布模型 瀑布模型也称软件生存周期模型。它在软件工程中占有重要地位，它提供了软件开发的基本框架，这比依靠“个人技艺”开发软件好得多。它有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。 瀑布模型的缺点：一是个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；二是由于开发模型是线性的用户只有等到整个过程的末期才能见到开发成果，从而卡增加了开发的风险；三是早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重后果。 2. 原型模型 原型模型的主要思想：先借用已有系统作为原型模型，通过“样品”不断改进， 使得最后的产品就是用户所需要的。原型模型通过向用户提供原型获取用户的反 馈，使开发出的软件能够真正反映用户的需求。 原型模型的特点：开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。缩短了开发周期，加快了工程进度。降低成本。 原型模型的缺点：当告诉用户，还必须重新生产该产品时，用户是很难接受的。 这往往给工程继续开展带来不利因素。不宜利用原型系统作为最终产品。 3. 螺旋模型 螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版 本。 螺旋模型的优点： 1）设计上的灵活性，可以在项目的各个阶段进行变更。 2）以小的分段来构建大型系统，使成本计算变得简单容易。 3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向及项目的可控性。 4）随着项目推进，客户始终掌握项目的最新信息，从而他或她能够和管理层有效地交互。 5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
能力素质模型超详细解析
能力素质模型超详细解析 业绩的评估和行为的管理是通过绩效考核的财务指标和过程性指标体现的。一个组织为了实现其战略目标、获得成功，对组织内个体所需具备的素质、技能和知识的综合要求，就是能力素质。在这样的定义下，能力素质像流程一样，都是服务于战略的。 如何建立平衡计分卡中的学习和发展指标呢？要回答这个问题，首先要解答下面的三个问题：销售人员需要很多能力吗？这些能力是什么？能够量化地分析销售人员的能力吗？我们通过开车的例子，来分析一位司机需要的能力。 司机首先要启动汽车，点火、踩刹车、挂档、踩油门，车启动了。然后从车库里开出来上路，靠右边行驶、通过油门和离合器的配合换档加速或者减速，遇到红灯时等待绿灯通行，然后左拐弯。行驶到了目的地，找到了一个两边贴的很紧的停车位，将车倒进去是一个技术活儿，来回很多次将车停了进去。 在这个过程中，司机承担了很大的责任，如果稍不小心，轻则刮蹭，重则出现严重的车祸。司机完成这个过程需要很多能力吗？其实司机只需要三项能力：交通知识和规则、路面行驶和出库入库。 通过这个例子，我们看到司机这个工作并不需要太多的能力，其实包括销售在内的任何工作都可以通过数量不多的能力来完成。 既然每个职位不需要太多的能力，那我们就可以将这些能力寻找出来，定义清楚，这样我们就为每个职位找到一系列的能力，通过规范员工行为表现，实现公司对员工的职责要求，确保员工的职业生涯和个人发展计划与公司的经营目标，与客户的需求保持高度的一致性，并有助于公司经营目标的实现和提高客户满意度。 为了能够更深入地覆盖中国市场，诺基亚招聘了大量的销售人员在各个手机店面销售自己的产品，委托我们定义销售团队的能力并进行培养。 我们仔细地观察了促销员的销售行为，发现在销售过程中存在不少问题：促销员与客户打招呼时没有统一的做法，往往不能成功的留住客户的脚步。还有很多销售人员不知道询问客户的需求，不停地介绍产品，往往又说不到点子上。 我们观察了最优秀的销售人员，他们的行为特征是：在客户刚出现时就立即向客户微笑和寒暄，使用开放性的提问，完整、清晰地挖掘客户需求；不仅介绍产品而且介绍对客户的益处，时刻留意购买信号，促成交易。 将这些行为特征总结出来就是销售人员需要的面对顾客销售的技巧。我们通过上百次的培训，并帮助诺基亚建立辅导体系。现在，这些最优秀销售人员的行为特征成为很多销售人员的工作习惯和组织的能力。当顾客采购手机的时候，销售人员可以按照高标准的水平进行销售了。 能力素质模型就是将这些能力素质按内容、按角色或是按岗位有机的组合在一起。能力素质模型广泛运用于人力资源管理的各项业务中，如：员工招聘、员工发展、工作调配，绩效评估以及员工晋升等。 能力素质模型包含知识、技能和素质三个大的类别。知识包含产品知识，公司背景知识，所在行业的知识，管理的基本知识等等，是最容易提高的。沟通、谈判、销售、演示和管理等都用一定的步骤和方法，将这些步骤和方法总结出来，就是技能。素质是几乎不能改变的，至少企业没有重要的责任，素质包括正直诚心、工作热情、有责任心等等。 由于每项素质、技能和知识都会有相关的行为描述，通过这些行为描述来体现对于某项品格、能力和知识的掌握程度，它还可以更广泛地应用于工作的各个方面。 能力和素质之间有很大的差别，为了更好地甄选员工并培养他们，我们必须将能力素质
常见软件开发模型
常见软件开发模型 模型优点缺点 瀑布模型文档驱动系统可能不满足客户的需求 快速原型模型关注满足客户需求可能导致系统设计差、效率低，难于 维护 增量模型开发早期反馈及时，易于维护需要开放式体系结构，可能会设计差、 效率低 螺旋模型风险驱动风险分析人员需要有经验且经过充分 训练 瀑布模型(Waterfall Model ) 1970年Winston Royce 提岀了著名的“瀑布模型“，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型中，如图所示，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、
软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如 同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，开发的风 从而增加了险； （3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 快速原型模型（Rapid Prototype Model ） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么； 第二步则在第一步的基础上开发客户满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。快速 原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真 正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速 建立原型，随之迅速修改原型，以反映客户的需求。
员工胜任素质模型与任职资格介绍
员工胜任素质模型与任职资格 1．1 胜任素质模型的基本内容 1．1．1 胜任素质简述 胜任素质（Competency）又称能力素质，在组织管理中，胜任素质是指驱动员工作出卓越绩效的一系列综合素质，是员工通过不同方式表现出来的知识、技能/能力、职业素养、自我认知、特质和动机等的素质集合。 哈佛大学教授麦克利兰是将胜任素质用于实践的第一人。20世纪70年代初，麦克利兰应美国政府邀请，为之设计了一种能够有效预测驻外联络官（FISO）绩效的方法。麦克利兰首先采用行为事件访谈法收集第一手材料，然后通过分析工作表现优秀的和一般的驻外联络官的具体行为特征及各项差异，最终提炼出了驻外联络官胜任工作且能作出优秀绩效所应具备的能力素质。 胜任素质模型自诞生之日起就被应用到了人力资源工作中的各个方面。实践证明，胜任素质模型可以提高企业的人力资源质量，提升组织的竞争力，还能推动企业发展战略的实现。 1．1．2 胜任素质识别 能否显著区分员工的工作绩效差异是判断某项胜任素质的唯一标准，即实际工作业绩卓越和业绩一般的员工在该项胜任素质上的行为表现是有明显差别的。识别员工的能力素质或岗位胜任特征可从以下三个层面进行。 1．知识 知识层面既包括员工在某一职业领域从事工作所必须具备的专业信息，如财务管理、人力资源管理、市场营销等学科的专业知识，也包括员工在某一组织中所必须掌握的相关信息，如公司知识、产品知识和客户信息等。 2．技能/能力 技能指掌握和运用某项专业知识完成具体工作的技术或能力，如计算机操作技能、财务分析能力等各项岗位专业技能。 能力指员工天生具备或在外部环境影响下不易改变的特质，如人际协调能力、问题分析
常用软件开发模型
常用软件开发模型比较分析 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ①以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ②在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。 ③以形式化开发方法为基础的变换模型（Transformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型 瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。 图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，
能力素质模型
精品文档 长春一汽富晟集团 员工岗位 胜任素质模型 人力资源部
目录 员工素质决定着企业的生 存和发展，是企业成败 的关键。 一汽富晟集团员工岗 位胜任素质模型是依据富 晟公司核心价值观和员工 岗位胜任要求，从职业素 养、专业知识、技能/能力 三个层面分别提取能力要 素，进行能力定义和行为 层级描述，进而构建具有 科学性、专业性、实用性 的能力素质模型。 导读 Part 1 胜任素质模型介绍 /1 胜任素质简述 2 胜任素质识别 2 胜任素质模型 3 Part 2 三层面素质定义 /5 职业素养定义及行为层级描述 6 专业知识定义及行为层级描述 8 技能/能力定义及行为层级描述 15 Part 3 各岗位胜任素质模型 /19 集团经营班子各岗位胜任素质模型 20 规划发展部各岗位胜任素质模型 22 人力资源部各岗位胜任素质模型 24 财务控制部各岗位胜任素质模型 28 信息化与企业管理部各岗位胜任素质模型 33 产品研销部各岗位胜任素质模型 35 审计监察室各岗位胜任素质模型 37 党群工作部各岗位胜任素质模型 38 综合管理部各岗位胜任素质模型 41
Part1 胜任素质模型介绍 胜任素质（Competency）又称能力素质， 在组织管理中是指驱动员工做出卓越绩 效的一系列综合素质。
胜任素质简述 Competency）又称能力素质，在组织管理中是指驱动员工做出卓越绩效的一系列综合素质，是员工通过不同方式表现出来的知识、技能或能力、职业素养、自我认知、特质等素质的集合。实践证明，运用胜任素质模型可以提高企业的人力资源质量，提升组织竞争力，从而推进企业发展战略目标的实现。 胜任素质识别 的惟一标准，即实际工作业绩卓越和业绩一般的员工在该项胜 任素质上的行为表现是有明显差别的。识别员工的能力素质或 岗位胜任特征可从以下三个层面进行。 知识 知识层面既包括员工从事某一职业领域工作所必须具备的专业信息，例如财务管理、人力资源管理、市场营销等学科 的专业知识，也包括员工在某一组织中工作所必须掌握的相关 信息，例如公司知识、产品知识和客户信息等。
常用软件开发模型比较分析
1.2 常用软件开发模型比较分析 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ① 以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ② 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（S piral Model）。 ③ 以形式化开发方法为基础的变换模型（Transformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型 瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。
空间维： 把MIS的实体（系统）划分为若干个子系统。按垂直方向如分解为战略决策与计划，管理控制和执行处理三个层次；再按水平方向分解，如划分为：生产管理，材料管理，财会管理等子系统。 常用方法： 把系统按空间维分成若干个子系统，分期开发子系统，子系统的开发再遵循时间维的分解，按开发工程分步骤开发。 1.2.2 螺旋模型 螺旋模型将瀑布和演化模型（Evolution Model）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如图1-4所示。 图1-4 采用螺旋模型的软件过程 螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。 螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，
胜任素质模型简介—起源及基本内容-6doc
胜任素质模型简介—起源及基本内容(2008-09-25 09:52:30) 胜任素质(能力)模型(Competency Model) 又叫素质模型COMPETENCY 即“素质、资质、才干”等，是指驱动员工产生优秀工作绩效的各种个性特征的集合，它反映的是可以通过不同方式表现出员工的知识、技能、个性与内驱力等，能力是判断一个人能否胜任某项工作的优点，是决定并区别绩效差异的个人特征。 烽火猎聘资深顾问在职业经理人中说到企业在选人、用人时应重在发现其优势，而不是去克服劣势。优势的核心是个性与天赋，一个人的能力内容正如一座冰山，我们看到和测量的是冰山以上的一小部，即一个人的表象行为、知识、技能或者是说应知、应会的内容，而冰山以下绝大部份潜在的不易察觉的，但却是决定我们业绩结果的深层次因素。 一、企业存在的核心问题： ◎选人、用人、育人时，所依据的标准不明确； ◎只关心员工能不能胜任而不关注员工适不适合做； ◎培训工作开展效果不明显，知识、方法、技巧培训了一次又一次，但业绩还是不明显； ◎存在“干一行，爱一行”的误区，不能做到发挥员工的优势； ◎不知道本企业运作所需要的核心能力有哪些； ◎有的人学历、知识、技能均很好，但不能产生高绩效。 ◎专业人员发展空间成为老大难问题； ◎优秀的专业人员看不到发展前途，人才流失； ◎提拔优秀的专业人员做管理工作，造成资源浪费。
二、解决思路： ◎明确核心能力，进行素质定义； ◎进行能力等级定位，选拔标杆式人员； ◎通过行为事件访谈和其他方法收集数据； ◎分析数据； ◎设计各职位类别的核心能力模型； ◎指导企业建立能力测评体系； ◎指导企业将能力模型通过“四维度透析法”面试技巧，运用到招聘过程中； ◎辅导企业将能力模型在人才选拔中作为核心要素进行评价； ◎辅导企业将能力模型运用于培训课程设计中； ◎辅导企业将能力模型运用在业绩管理中作业能力要素进行考核。◎辅导企业将素质模型与薪酬体系接轨。 三、通过我们的咨询，给企业带来的收益： ◎工作安排：根据企业业务发展的需求和员工的能力水平，灵活地对员工的工作进行合理安排，以保证“人”和“岗”的最佳匹配，从而使“以人为本”得到最大限度的体现。 ◎员工培训：根据核心能力模型的要求，评估现有职位员工目前的能力与理想能力之间的差距，以确保培训课程的设计针对性，提高员工能力； ◎业绩管理：对员工在工作过程中表现出来的能力进行牵引，根据员工的表现提出及时有效反馈，帮助员工提高绩效水平； ◎薪酬管理：根据员工所表现出来的能力水平，来确定员工的薪酬水
软件工程复习资料整理
第一章软件工程介绍 软件工程的概念 IEEE对软件工程的定义: （1）将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。 （2）在（1）中所述方法的研究。 过程、方法和工具 过程：为了获取高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 方法：各项任务的技术方法，回答“怎么做”的问题。 工具：为运用方法而提供的自动或半自动的软件工程支撑环境 软件工程层次图 软件危机与软件工程的关系、产生的原因及其表现 软件工程的提出： 软件工程主要是针对20世纪60年代的软件危机而提出的 软件危机定义：软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 产生软件危机的原因： 客观原因： 软件缺乏“可见性”，管理和控制其开发过程相对困难 软件大多规模庞大，而复杂性随规模以指数速度上升 主观原因： 错误的认识和做法 忽视软件需求分析的重要性—急于求成，仓促上阵 认为软件开发就是写程序—编程只占全部工作量的10%--20%，软件配置主要包括程序、文档和数据 轻视软件维护—维护费用占总费用的55%--70%
软件神话一些错误认识 管理神话： 我们已经有了一本写满软件开发标准和规程的宝典。它无所不包，囊括了我们可能问到的所有问题 如果我们未能按时完成计划，我们可以通过增加程序员人数而赶上进度 如果将一个软件外包给另一家公司，则我们可以完全放手不管。 用户神话： 有了对项目目标的大概了解，便足以开始编写程序，我们可以在之后的项目开发过程中逐步了解细节。 虽然项目需求不断变更，但是因为软件是弹性的，因此可以很容易地适应变化从业者神话： 当我们完成程序并将其交付使用之后，我们的任务就完成了。 直到程序开始运行，才能评估其质量 对于一个成功的软件项目，可执行程序是惟一可交付的成果。 软件工程将导致我们产生大量无用文档，并因此降低工作效率。 第二章过程模型 掌握五个最基本的框架活动： 将整个软件过程再进一步细分为各个相对独立的功能块，即过程框架。（以工作开展的时间为线索）。 五个最基本的框架活动： 沟通：与客户之间的交流与写作 策划：为后续的软件工程工作制定计划 建模：包括分析和设计 构建：编码和测试 部署：软件交付用户，用户对其进行评估并反馈意见。 了解典型的普适性活动 适用于任何一个框架活动： 软件项目跟踪和控制；风险管理；软件质量保证；正式技术评审；测量；软件配置管理；可复用管理；工作产品的准备和生产
素质模型与素质测评的理论简介
素质模型与素质测评的理论简介 人力资源部2004-06-15 素质模型与素质测评的理论简介 第一部分素质模型理论 一、素质的概念 素质（Competency），又称“能力”、“资质”、“才干”等，是驱动工作者产生优秀工作绩效的各种个性特征的集合，具体包括可以通过工作者外在的工作行为所表现出来的知识、技能、个性、态度、价值观、内驱力等。可以说，素质是判断一个人能否胜任某项工作的起点，也是决定并区别个人绩效优劣差异的关键。如何预测工作绩效的问题在过去的两百年中，一直是科学研究所关注的话题。早在1911年，泰勒认识到，优秀工人与较差工人在完成他们工作时的差异。他建议管理者用时间和动作分析方法，去界定工人的素质是由哪些成分构成的，同时采用系统的培训和发展活动去提高工人的素质，进而提高组织效能。随后，智商学说盛行，智力测试在人员甄选与评估中广泛使用。20世纪60年代后期，智商学说越来越受到质疑，人们迫切希望了解影响工人绩效的根本原因。以哈佛大学McClelland教授为首的研究小组，经过大量深入研究发现：学术测试和学校的考试分数“不能够预测工作绩效或者生活成功与否”，而另一些诸如“成就动机”、“人际理解”、“团队影响力”等因素却可以从根本上影响个人绩效，McClelland 将这些因素定义为“素质变量”，认为素质可以预测工作绩效，并且较少地受到其他因素影响而产生偏差。研究小组以后又进一步将其明确定义为：“能区分在特定的工作岗位和组织环境中绩效水平的个人特征。”1973年，McClelland教授发表
了题为《测量素质而非智力》（Testing for Competence Rather Than for Intelligence）的文章，论证行为品质和特征较之潜能测试能够更加有效地决定人们工作绩效的高低，他指出，应该改变过去那种对人的认知能力进行总体测试的方法，转而衡量那些对人在某一特定工作中的绩效表现有直接影响的特征。他把这些特征称作素质。McClelland建议测量一个人的特征来判断此人是否适合执行某项工作，而不是使用一种笼统的测量方法来判断其综合认知能力。 这篇论文为素质理论的诞生奠定了基础。其后，始于这篇论文的研究工作引发了数以百计的对于素质的研究。众多的国内外研究者都对素质进行了界定，在此基础上，企业的构建与应用素质模型的实践又不断地丰富着这一领域的理论。总结这些研究和实践，我们可以发现，从素质的本质来看，它具有两个方面的特点： 1、将高绩效者与一般或者低绩效任职者区分开来，因此可以将素质作为预测员工绩效的依据； 2、可观察、可测量。素质的内容可以包括很多因素，例如知识、技能、动机等，但其要素必须是可观察、可测量的。正是由于这一特点，当今的在素质研究和实践领域，人们越来越多的使用行为描述性的词语来界定素质，如建立战略方向、客户导向等。 围绕这两个特征，有关素质的研究主要回答这些问题：究竟是什么构成了绩效出众者和绩效平平者之间的差异？如何找到这些区分因素并且加以可操作化，从而对员工进行更好的评估和考核，并且帮助他们获得更好的工作绩效？ 二、素质的划分 从概念来看，素质是“能区分在特定的工作岗位和组织环境中绩效水平的个人特征”。可见，岗位工作中的高绩效水平决定于个人特征、工作岗位和组织环境
软件开发过程的相关规范
软件开发过程规范 版本 <1.0> 修订历史纪录
目录 1.前言2 1.1目的2 1.2对象2 1.3要求2 1.4适用范围2 1.5软件开发过程模型3 1.6开发过程划分3 2.技术过程规范部分3 2.1概述3 2.2业务建模阶段3 2.3需求阶段4 2.4分析设计阶段5 2.5实现阶段6 3.经管过程规范部分7 3.1概述7 3.2接受工程7 3.3重新评估工程范围和风险（对于较大工程）7 3.4制定开发计划8 3.5迭代开发经管8 3.6监控工程的实施8 3.7结束工程9 软件开发过程规范 1. 前言 1.1 目的 本规范的目的是使整个软件产品开发及工程工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及经管，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。 1.2 对象 本规范面向产品生命周期的所有相关人员，包括经管人员、开发人员、质管人员。 1.3 要求 具有软件开发经管职能的人员要求熟知工程开发的各阶段过程和各阶段过程相应的规范。 1.4 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范
和经管过程规范，分别适用于软件开发过程中的技术性活动和经管性活动。 1.5 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。 1.6 开发过程划分 开发过程包括多次迭代，每次迭代的目标和侧重点不同；较早的迭代侧重于业务建模和需求建模；而后的迭代则侧重于分析设计和编码。 2. 技术过程规范部分 2.1 概述 本规范中将软件开发的整个技术过程分为四个顺序实施的阶段，分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述，按阶段内部的活动和产物对四个阶段分别说明。 在本规范中对阶段内活动的说明，是按顺序性活动和持续性活动两类分别进行说明。对于顺序性活动是按该阶段中活动的总体顺序进行的描述，而在实际工作中，从各活动的具体实施的细节来看，各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。 规范中所提到的可选文档是指在其所属阶段，可根据具体情况灵活掌握，开发团队自主决定是否开发的文档产物。而提交文档则是指在工程开发过程中必须开发的文档产物，但可根据具体工程情况，在软件开发计划中明确规定是否要形成正式文档并提交。 规范中各阶段提到的技术评审，具体参见《评审规范》中所对应技术性评审的详细描述。 2.2 业务建模阶段 2.2.1 顺序性活动描述 1)开始初步调研，获取初始业务需求，进行问题定义，形成《业务概览》并建立《术语表》； 2)制定《调研记录表册》，实施详细的业务调研，建立初始的业务用例模型和《业务用例 规格》； 3)分析业务过程，取出可以实现自动化的用例，分析业务部门和实体对象，形成初始的业 务对象模型； 4)根据初始业务对象模型和初始业务用例模型，分析并提取与系统实现相关的用例和模 型，建立系统域模型； 5)精化域模型中的初始用例，详细描述业务流程，分析业务规则，建立精化的业务用例模 型，形成《业务规则》和《业务用例规格》； 6)精化域模型中的初始对象，进行详细的对象描述，分析对象职责和对象间关系，建立精 化的业务对象模型，形成《业务对象纵览》； 7)分析业务上的非功能性需求，形成《增补业务规格》； 8)应用业务对象，实现业务用例，制定《业务用例实现规格》，以验证业务对象与业务用 例的正确性，根据验证结果，修正业务对象、业务用例及相关文档； 9)汇总《业务规则》《业务用例规格》《业务对象纵览》《增补业务规格》和《业务用例 实现规格》形成《业务架构文档》。