软件工程 实践者的研究方法 第29章答案
Problem:
Why is the First Law of System Engineering true? Provide specific examples for each of the four fundamental reasons for change.
Answer:
The first law of system engineering is true. That shows that no matter where we are in the system life cycle the system / software will change, and the desire to change it will persist throughout the life cycle.
While dealing with this change, software configuration management system represents a major management challenge. In place of SCM (software configuration management).
It will ease the management of these changes to the requirements of the products that will occur. And an SCM allows the easy identification of feature sets and group that requirements satisfied by that version of the product
Examples of fundamental reasons for change:-
Change in business requirements
Change in staff requirements
Change in technical requirements
Changes in user requirements.
Problem:
What are the four elements that exist when an effective SCM system is implemented? Discuss each briefly.
Answer:
Four elements of an effective SCM system:
While developing a software configuration management system we may identifies the four important elements, that are
1) Component elements
2) Process elements
3) Construction elements
4) Human elements.
Description of each:
1) Component elements:
A set of tools combined with in a file management system and that enable access to and management of each software configuration item.
Ex: database.
2) Process elements:
That means a collection of procedures and tasks that are defined for an effective approach to change management process elements are used for all constituencies involved in the management, engineering and use of computer software.
3) Construction elements:
These elements are a set of tool. That automate the construction of software by ensuring that the proper set of validated components has been assembled.
4) Human elements:
These elements are used to implement the effective SCM, the software team uses to a set of tools and process features.
Problem:
Discuss the reasons for baselines in your own words.
Answer:
Reason for baseline:-
To overcome the modifications, occurs from customers requirements, developer’s
technique approach, manger’s project strategy, we use the baseline concept.
Baseline is one of the concept of SCM.
This helps to control the change without seriously impeding justifiable change.
Base line is A set of software items formally designated and fixed at a specific time
during the software life cycle
Baseline tem is used to refer a patellar version of a software item. And in other
case. It can only be changed through formal change control procedures.
Baseline represents the current approved configuration.
In base line,
The functional baseline corresponds to the reviewed system requirements.
The allocated baseline corresponds to the reviewed software requirements
specifications and software interface requirements specifications.
The developmental baseline represents the evolving software configuration at
selected times during the software life cycle.
The product base line corresponds to the completed software product delivered for
system integration.
Basically, baselines to the used for a given project, along with their associated levels
of authority needed for change approval.
Problem:
Assume that you’re the manager of a small project. What baselines would you define for the project and how would you control them?
Answer:
A small project might combine analysis and design modeling into a "Development Specification" that would serve as the first SCI.
The source would be the second. It is unlikely that a formal Test Specification would be created, but the suite of test cases would be the third SCI.
A User's manual would likely be the fourth SCI and executable versions of the software would be the fifth. Any change to these baseline SCIs might generate the following questions:
What are the effort and cost required?
How complex is the change and what is the technological risk?
Is the software that is to be changed heavily coupled to other system components?
Are the modules to be changed cohesive?
What is likely to happen if the change is not implemented properly?
What is the relative importance of this change as compared to other requested changes?
Who will make the change?
How can we be sure that the change is implemented properly?
These all requirements are considered as technique approach. These modifications are done through developers / project manager and
If need to modify the “project strategy” it is done by the project manager.
Flow structure of total project and if need to modify the requirements based on user point of view, than project manager follow the base lines.
Here SCIs means software configurations items.
Problem:
Design a project database (repository) system that would enable a software engineer to store, cross-reference, trace, update, change, and so forth all important software configuration items. How would the database handle different versions of the same program? Would source code be handled differently than documentation? How will two developers be precluded from making different changes to the same SCI at the same time?
Answer:
Project database system:-
SCIS are maintained in a project database or responsibility. The word repository as ‘any thing or person though of as a center of accumulation or storage.
To use repository store, cross – reference, trace, update, and change all important function, but in addition, the repository performs or participates some other functions also.
Data integrity
Information sharing
Tool integration
Data integration
Methodology enforcement
Document standardization
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 major capabilities.
(i) A project database (repository) that store, all relevant configuration objects
(ii) A version management capabi8lity that stores all versions of a configuration object
(iii) A make facility that enables the software engineer to collect all relevant configuration objects and construct a specific version of the software.
A member of version control systems establish a change set – A collection of all changes that are required to create a specific version of a software.
Problem:
Research an existing SCM tool and describe how it implements control for versions, variants, and configuration objects in general.
Answer: Problem:
The relations and represent simple relationships between configuration objects. Describe five additional relationships that might be useful in the context of an SCM repository.
Answer:
The possible five other relationships between different configuration objects that can be useful in terms of an SCM repository are given below:
• Data model Design Specification
Once the design specifications are clearly defined, the data model can be accordingly constructed or derived using the design specifications.
• Interface description interface design
The interface design is worked upon in the design specifications. This can be followed by describing the interface design so that it is well understood and easily available to others.
• Source code test cases
The code is tested after designing the test plan and by using test cases to uncover errors.
• Test Specification ComponentN
Any changes in test specification would also bring about changes in ComponentN.
• Test Specification Design Specification
The test specification would attempt to find all errors in the design specification thus making it less prone to failures.
Thus, different additional relationships that can be used in context of an SCM repository are , , , and .
Problem:
Research an existing SCM tool and describe how it implements the mechanics of version control. Alternatively, read two or three papers on SCM and describe the different data structures and referencing mechanisms that are used for version control.
Answer:
Concurrent Version System :-
CVS, which requires RCS, extends RCS to control concurrent editing of sources by several users working on releases built from a hierarchical set of directions.
Different versions may exist at the same time. One version is available via the internet for end users, another version may be in the final stages of testing prior to deployment.
A third version is in development and represents a major update in content, interface aesthetics and functionalities.
Configuration objects must be clearly defined so that each can associated with the appropriate version.
Problem:
Develop a checklist for use during configuration audits.
Answer:
Checklist for use during configuration audits:-
Basically configuration audits are done in two types.
Functional configuration
Physical configuration
Functional configuration audit checks whether the existing code is related to specification or not and testing may expected through actual results. Physical configuration audit compare the physical components like requirements Vs design and design Vs code and to make sure that they reflect each other.
Check list for configuration audit:-
(1) Functional configuration audit:-
Below example of FCA check list is possible objective evidence gathering techniques for each item.
1) Check whether the code implements all and only the documented software / system requirements ?
2) Check whether the software requirement be traced for word into tests and verify that requirements.
3) Is software testing complete, including functional testing interface testing and testing of required quality attributes
4) Review the sample set of approved test anomaly report records for evidence of adequate resolution. Then review the test result data.
5) Check whether the deliverable documentation consistent with the requirements and as – built system / software?
Physical configuration:-
Physical configuration auditing typically held either in conjunction with the FCA.
Below example check list illustrates the physical configuration audit.
1) Review the FCA audit report associated corrective actions, and follow up the verification records to evaluate adequacy of actions.
2) Take the set of configuration items and evaluate them against configuration status,
3) Check all the configuration items meet work man ship standards or not.
4) Check whether the software been built from the correct components and in accordance with the specification.
5) Check whether the deliverable documentation be set complete.
6) Check the deliverables for shipment match the list of required deliverables.
7) Check whether the 3rd party licensing requirements been met or not.
Problem:
What is the difference between an SCM audit and a technical review? Can their function be folded into one review? What are the pros and cons?
Answer:
Difference between SCM – audit and formal technical review:-
Configuration audit ensures that the correct CI’s being incorporated into specific build and all documentation is up – to – data and it may consistent with the version that has been built.
SCM audit is conducted separately by the quality assonance group and it complements the formal technical review by addressing the below questions.
1) Has the change specified in the ECO been made? Have any additional modifications been in corporate?
2) Has a formal technical review been conducted to assess technical correctness?
3) Has the s/w process been followed ? house s/w engineering standards been properly applied?
4) Has the change been highlighted in the SCI? have change data and change author been specified? Do the attributes of the configuration object reflect the change?
5) Have SCM procedures for nothing the change, recording it and any reporting it been followed?
6) Have all related SCIS been properly updated?
Where as in formal technical reviews,
Mainly this focuses on the technical correctness of the configuration object been modified.
Formal technical reviews access the CIs to determine consistency with other CIs, omissions, or potential side effects.
Problem:
Briefly describe the differences between SCM for conventional software and SCM for Web or MobileApps.
Answer:
Difference between SCM for conventional software and SCM for web Apps:-
A conventional software application that relies on the web / uses the web
infrastructure for execution.
Where as
Web Application develivered over the web that combines characteristics of both web
by per media and web software application.
Conventional software can be developed using several programming languages
running on a specific platform. It can also use in communications technology to
connect to and use a database system.
Where as
In web applications means that developers can build a full spectrum of applications
from a static simple web applications using HTML to full fledged distributed
applications.
Conventional software applications are generally developed for a know user group
mocking the explicit identification of target users an easier task, where as
Web applications are aimed at wide range group of users.
Other than these, we may compare the conventional software and web apps by
following terms.
Application characteristics:
Web applications use a hypermedia paradigm where content is structured and
presented using hyperlinks.
Conventional software applications can be developed using a wide variety of
components that is generally developed using in conventional programming language
like C++.
Primary technologies used:
Web applications are developed using devisers technologies such as Java, HTML.
Where as
Conventional software applications is represented by object oriented methods.
Availability of the applications:
Users who use the web applications to be operational thought the whole year
(24/7/365)
Where as
In conventional software applications, do not expect these applications to be
available 24/7/365.
Problem:
What is content management? Use the Web to research the features of a content management tool and provide a brief summary.
Answer:
Content management:-
Content management establishes a process that acquires existing content, structures it to be presented to an end-user, and provides for display, to the client-side environment.
Content management manages the content as incorporated to web Apps. For maintaining this, content management is uses the set of processes and technologies that support the evolutionary life cycle in formation.
It is an computer application used to create, edit mange, search and various kinds of digital media and electronic text.
It is used for storing, controlling, versioning and publishing industry – specific documentation.
Features of content management:-
CMS checks about the users and their content management roles.
It checks the ability to assign roles and responsibilities to different content categories or types.
CMS define the work flow tasks for collaborative creation.
CMS may a bile to track and manage multiple versions of single instance of content.
Using this content management, we may organize the content into packets and the can be displayed effectively on the client – side.
Solution : Chapter 29 : SOFTWARE CONFIGURATION MANAGEMENT
29.1 Because change is a fact of life, it is necessary to recognize that iteration occurs in all paradigms for software engineering. The biggest danger is to assume that the software engineering process will flow sequentially from start to finish with no changes. This just is not realistic!
29.2 Component elements – set of tools coupled within a file management system to enable access to and management of each SCI
Process elements – collection of procedures that define and effective approach to change management for all stakeholders
Construction elements – set of tolls that automate the construction of software by ensure a set of validated components is assembled
Human elements – team uses a set of tools and process features encompassing other CM elements
29.3 We have to establish a point at which we "cut the chord." That is, we must define a point beyond which we will not change something without careful (even formal) evaluation and approval.
29.4 A small project might combine analysis and design modeling into a "Development Specification" that would serve as the first SCI. The source would be the second. It is unlikely that a formal Test Specification would be created, but the suite of test cases would be the third SCI. A User's manual would likely be the fourth SCI and executable versions of the software would be the fifth. Any change to these baseline SCIs might generate the following questions:
1. What are the effort and cost required?
2. How complex is the change and what is the technological risk?
3. Is the software that is to be changed heavily coupled to other system components?
4. Are the modules to be changed cohesive?
5. What is likely to happen if the change is not implemented properly?
6. What is the relative importance of this change as compared to other requested changes?
7. Who will make the change?
8. How can we be sure that the change is implemented properly?
29.5 Any book on database design would provide pointers here.
29.6 Answers will vary
29.7 Other relationships:
<mapped from>
<describes>
<derived from>
<uses>
<model of>
<created using>
<identified as>
29.8 Answers will vary
29.9 There is a checklist on the SEPA website
29.10 An SCM audit focuses on compliance with software engineering standards while an FTR concentrates on uncovering errors associated with function, performance or constraints. The audit has a less technological feel.
29.11 The “code and go” philosophy dominates App development. So SCM for Apps must be an agile process. Documentation and review of changes is done on an as needed basis depending on the risk associated with the work products being changed.
29.12 Content management establishes a process that acquires existing content, structures it to be presented to an end-user, and provides for display, to the client-side environment
