software configuration management...
TRANSCRIPT
Software Configuration Management & Project Management
• 교과목명: 소프트웨어공학
• 해당 주차: 15
• 소속 / 작성자: 조영석
이 문서는 나눔글꼴로 작성되었습니다. 설치하기
Software Configuration Management
3
Acknowledgments
This chapter is partly indebted to the contents of following references with modifications: Pressman, R., Software Engineering: A Practitioner’s Approach, 7th ed.,
McGraw Hill, 2010 Sommerville, I., Software Engineering, 8th ed., Addison-Wesley, 2007 Kendall, P. A., Introduction to Systems Analysis and Design: A
Structured Approach, 3rd ed., Irwin, 1996 Wikipedia
All diagrams included in this material are redrawn with modifications. For more detailed explanation of the topics discussed, refer to the references
listed above.
4
Configuration Management
Version Control Content Management
4
5
Version Control Version control combines procedures and tools to manage different
versions of configuration objects that are created during the software process
A version control system implements or is directly integrated with four major capabilities: a project database (repository) that stores all relevant
configuration objects a version management capability that stores all versions of a
configuration object (or enables any version to be constructed using differences from past versions);
a make facility that enables the software engineer to collect all relevant configuration objects and construct a specific version of the software.
an issues tracking (also called bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object.
5
6
Content Management
The collection subsystem encompasses all actions required to create and/or acquire content, and the technical functions that are necessary to convert content into a form that can be represented by a
mark-up language (e.g., HTML, XML) organize content into packets that can be displayed
effectively on the client-side.
6
7
Content Management (cont’d)
The management subsystem implements a repository that encompasses the following elements: Content database—the information structure that has been
established to store all content objects Database capabilities—functions that enable the CMS to
search for specific content objects (or categories of objects), store and retrieve objects, and manage the file structure that has been established for the content
Configuration management functions—the functional elements and associated workflow that support content object identification, version control, change management, change auditing, and reporting.
7
8
Content Management (cont’d)
The publishing subsystem extracts from the repository, converts it to a form that is amenable to publication, and formats it so that it can be transmitted to client-side browsers. The publishing subsystem accomplishes these tasks using a series of templates.
8
9
Content Management (cont’d)
Each template is a function that builds a publication using one of three different components [BOI02]:
Static elements—text, graphics, media, and scripts that require no further processing are transmitted directly to the client-side
Publication services—function calls to specific retrieval and formatting services that personalize content (using predefined rules), perform data conversion, and build appropriate navigation links.
External services—provide access to external corporate information infrastructure such as enterprise data or “back-room” applications.
9
11
Acknowledgments
This chapter is partly indebted to the contents of following references with modifications: Pressman, R., Software Engineering: A Practitioner’s Approach, 7th ed.,
McGraw Hill, 2010 Sommerville, I., Software Engineering, 8th ed., Addison-Wesley, 2007 Kendall, P. A., Introduction to Systems Analysis and Design: A
Structured Approach, 3rd ed., Irwin, 1996 Wikipedia
All diagrams included in this material are redrawn with modifications. For more detailed explanation of the topics discussed, refer to the references
listed above.
12
Project Management Managing People Software Cost Estimation Quality Management Process Improvement
12
13
Managing People
Selecting staff Motivating people Managing groups The people capability maturity model
13
14
People management factors
Consistency Team members should all be treated in a comparable way
without favourites or discrimination. Respect Different team members have different skills and these differences
should be respected. Inclusion Involve all team members and make sure that people’s views are
considered. Honesty You should always be honest about what is going well and what
is going badly in a project.
14
15
Selecting staff
An important project management task is team selection. Information on selection comes from: Information provided by the candidates. Information gained by interviewing and talking with
candidates. Recommendations and comments from other people who
know or who have worked with the candidates.
15
16
Motivating people
An important role of a manager is to motivate the people working on a project.
Motivation is a complex issue but it appears that their are different types of motivation based on: Basic needs (e.g. food, sleep, etc.); Personal needs (e.g. respect, self-esteem); Social needs (e.g. to be accepted as part of a group).
16
17
Managing groups
Most software engineering is a group activity The development schedule for most non-trivial software
projects is such that they cannot be completed by one person working alone.
Group interaction is a key determinant of group performance. Flexibility in group composition is limited Managers must do the best they can with available people.
17
18
Factors influencing group working
Group composition Group cohesiveness Group communications Group organization
18
19
Group composition
Group composed of members who share the same motivation can be problematic Task-oriented - everyone wants to do their own thing; Self-oriented - everyone wants to be the boss; Interaction-oriented - too much chatting, not enough
work. An effective group has a balance of all types. This can be difficult to achieve software engineers are often
task-oriented. Interaction-oriented people are very important as they can
detect and defuse tensions that arise.
19
20
Group communications
Good communications are essential for effective group working.
Information must be exchanged on the status of work, design decisions and changes to previous decisions.
Good communications also strengthens group cohesion as it promotes understanding.
20
21
Group communications (cont’d) Group size The larger the group, the harder it is for people to
communicate with other group members. Group structure Communication is better in informally structured groups
than in hierarchically structured groups. Group composition Communication is better when there are different
personality types in a group and when groups are mixed rather than single sex.
The physical work environment Good workplace organisation can help encourage
communications. 21
22
Group organization
Small software engineering groups are usually organised informally without a rigid structure.
For large projects, there may be a hierarchical structure where different groups are responsible for different sub-projects.
22
23
People Capability Maturity Model
Intended as a framework for managing the development of people involved in software development.
23
24
P-CMM Objectives
To improve organisational capability by improving workforce capability.
To ensure that software development capability is not reliant on a small number of individuals.
To align the motivation of individuals with that of the organisation.
To help retain people with critical knowledge and skills.
24
25
P-CMM levels
Five stage model Initial. Ad-hoc people management Repeatable. Policies developed for capability improvement Defined. Standardised people management across the
organisation Managed. Quantitative goals for people management in
place Optimizing. Continuous focus on improving individual
competence and workforce motivation
25
26
Management of Object-Oriented Software Projects
Common Process Framework for OO Object-Oriented Project Metrics and Estimation OO Estimating and Scheduling Approach Progress for an OO Project
26
27
Measures, Metrics and Indicators
A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process
The IEEE glossary defines a metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.”
An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself
27
28
Measurement Principles
The objectives of measurement should be established before data collection begins;
Each technical metric should be defined in an unambiguous manner;
Metrics should be derived based on a theory that is valid for the domain of application (e.g., metrics for design should draw upon basic design concepts and principles and attempt to provide an indication of the presence of an attribute that is deemed desirable);
Metrics should be tailored to best accommodate specific products and processes.
28
29
Measurement Process
Formulation. The derivation of software measures and metrics appropriate for the representation of the software that is being considered.
Collection. The mechanism used to accumulate data required to derive the formulated metrics.
Analysis. The computation of metrics and the application of mathematical tools.
Interpretation. The evaluation of metrics results in an effort to gain insight into the quality of the representation.
Feedback. Recommendations derived from the interpretation of product metrics transmitted to the software team.
29
30
Metrics Attributes
simple and computable. It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or time
empirically and intuitively persuasive. The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration
consistent and objective. The metric should always yield results that are unambiguous.
consistent in its use of units and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations of unit.
programming language independent. Metrics should be based on the analysis model, the design model, or the structure of the program itself.
an effective mechanism for quality feedback. That is, the metric should provide a software engineer with information that can lead to a higher quality end product
30
31
Analysis Metrics
Function-based metrics: use the function point as a normalizing factor or as a measure of the “size” of the specification
Specification metrics: used as an indication of quality by measuring number of requirements by type
31
32
Function-Based Metrics
The function point metric (FP), first proposed by Albrecht [ALB79], can be used effectively as a means for measuring the functionality delivered by a system.
Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity
Information domain values are defined in the following manner: number of external inputs (EIs) number of external outputs (EOs) number of external inquiries (EQs) number of internal logical files (ILFs) Number of external interface files (EIFs)
32
33
Architectural Design Metrics
Architectural design metrics Structural complexity = g(fan-out) Data complexity = f(input & output variables, fan-out) System complexity = h(structural & data complexity)
HK metric: architectural complexity as a function of fan-in and fan-out
Morphology metrics: a function of the number of modules and the number of interfaces between modules
33
34
Metrics for OO Design Whitmire describes nine distinct and measurable characteristics of an
OO design: Size Size is defined in terms of four views: population, volume, length,
and functionality Population: Static count of OO entities, such as classes,
operations Volume: ≃ population, but collected dynamically at a given
instant of time Length: a chain of interconnected design elements such as the
depth of an inheritance hierarchy Functionality: value delivered to the customer by an OO
application Complexity How classes of an OO design are interrelated to one another
Coupling The physical connections between elements of the OO design
34
35
Metrics for OO Design (cont’d)
Sufficiency “the degree to which an abstraction possesses the features
required of it, or the degree to which a design component possesses features in its abstraction, from the point of view of the current application.”
Completeness An indirect implication about the degree to which the
abstraction or design component can be reused Cohesion The degree to which all operations working together to
achieve a single, well-defined purpose
35
36
Metrics for OO Design (cont’d)
Primitiveness Applied to both operations and classes, the degree to which
an operation is atomic Similarity The degree to which two or more classes are similar in
terms of their structure, function, behavior, or purpose Volatility Measures the likelihood that a change will occur
36
37
Component-Level Design Metrics
Cohesion metrics: a function of data objects and the locus of their definition
Coupling metrics: a function of input and output parameters, global variables, and modules called
Complexity metrics: hundreds have been proposed (e.g., cyclomatic complexity)
37
38
Code Metrics
Halstead’s Software Science(1977): a comprehensive collection of metrics all predicated on the number (count and occurrence) of operators and operands within a component or program It should be noted that Halstead’s “laws” have generated
substantial controversy, and many believe that the underlying theory has flaws. However, experimental verification for selected programming languages has been performed.
38
39
Metrics for Testing
Testing effort can also be estimated using metrics derived from Halstead measures
Binder suggests a broad array of design metrics that have a direct influence on the “testability” of an OO system. Lack of cohesion in methods (LCOM). Percent public and protected (PAP). Public access to data members (PAD). Number of root classes (NOR). Fan-in (FIN). Number of children (NOC) and depth of the inheritance
tree (DIT).
39
