Chapter II configuration software

Chapter 2: software build processes and tools 2.1 software lifecycle and configuration management
2.1 software lifecycle and configuration management
framework
 software development life cycle (SDLC)  traditional software process models (waterfall, incremental, Vmodel, prototyping , spiral)  agile and extreme programming (XP)   collaborative software development software configuration management (SCM) Gitas SCM tool  summary
2.1 software life cycle and configuration management objective of this seminar
 general understanding of the software development process  understand the concept of traditional software process models, including linear and iterative model (waterfall, incremental, prototyping, spiral and V)  understanding and Implementing agile development  understand software configuration management (SCM)  Learn how to Git for everyday SCM tasks (basic commands personal development, collaborative development of advanced command)
software to build
a software development life cycle (SDLC)
part 2.1 of the software life cycle and configuration management software system
software user
community environmental
technology hardware environment
planning data file
business goals
2.1 software lifecycle and configuration management
software lifecycle
Member Development Life Cycle (the SDLC): from zero to a
2.1 software lifecycle and configuration management
software lifecycle
multiple versions of the software lifecycle : 1 n to the
initial release of
an updated version of an
obsolete version of the
updated version 2 ...
2.1 Software lifecycle and configuration management example 1: Microsoft Windows (1985-2016)
2.1 software lifecycle and configuration management
"software is alive?"
§ Of course you can! Any software has its own life. - Software "age": the production and use how long? - Software "vitality": to what extent welcomed by the market and its user at a specific time?  Expectations: at all times lasting and vibrant  However, - failure of software development (from zero to 1) - Software Aging / attenuation (less effective) - - fault / error occurs during execution of death Software
2.1 Software Life Cycle and configuration management software development life cycle (SDLC)
§ this will be studied in 'software processes and tools "(software Engineering 3rd year track) courses
1 Introduction
3 project management.
2 Software Process Model
4 UML
5 project request.
6 7 test analysis and design and quality
8 Maintenance
9 SCM
software build
2 traditional software process model
2.1 software lifecycle and configuration management traditional software process model
are two basic types : - Linear - iteration  existing models: - Waterfall (Linear , non-iterative) - incremental (non-iterative) - V model (for verification and validation) - prototype (iteration) - spiral (iteration)  critical mass considerations: - user participation (to adapt to change) - development efficiency, project management complexity - software quality Falls (sequential, non-iterative)
§ the idea, startup, analysis, design, build, test, implementation and maintenance stages, progress is seen as flowing steadily downwards (like water).  Easy to use, but extremely high cost of change afterwards.  defined by Winston W. Royce in 1970.
2.1 Software configuration management lifecycle and incremental (non-iterative)
 product design, implementation and testing is increasing (every time you add a little) until the product is completed.  It gradually applied waterfall model. - The system is decomposed into a number of small-scale development projects. - Construction of the system to generate a final system. - first solve the highest priority requirements. - Once the increase is partially developed, the requirements of Part is frozen.
2.1 Software configuration management lifecycle and incremental (non-iterative)
2.1 software lifecycle and configuration management model V (for verification and validation)
V model representation can be seen as extensions of the waterfall model of development process. - are not moved downward in a linear fashion, but is bent upwardly after the encoding stage of the process steps to form a typical V-shaped. - to show the relationship between each stage of the development life cycle associated with the testing phase. - the horizontal axis represents time and the vertical axis or respectively project integrity (left to right) and a level of abstraction (coarsest thickest abstract).
2.1 software lifecycle and configuration management
prototype (iteration)
§ software prototyping is to create a software application prototyping activities, incomplete version of the software program that is being developed. - Several aspects of the prototype is usually simulate the final product, and may be completely different from the final product.  process: - determine the basic requirements: determine the basic requirements including the required input and output information. Details can usually be ignored. - Developinitialprototype: the development of the initial prototype only includes the user interface. - Audit: Customer (including end users) to check prototypes and provide feedback about the added or changed. - Reviseandenhancetheprototype: Use feedback can improve the specifications and prototypes. If you introduce change, you may need to repeat steps # 3 and # 4.
2.1 software lifecycle and configuration management
prototype (iteration)
 Advantages: - software designers and implementers can get valuable feedback from users early in the project. - client matches comparing the produced software and software specifications, constructed in accordance with a software program of the software specification. - It also allows software engineers to understand the accuracy of the initial project estimate, as well as deadlines and milestones can successfully meet the proposal.
2.1 software lifecycle and configuration management
helix (iteration)
§ spiral model for software project is risk-driven process model generator. - based on a given project's unique risk model, the spiral model guidance team uses elements of one or more process models, such as incremental, waterfall or evolutionary prototype.  First described by Barry Boehm in 1986.
2.1 software lifecycle and configuration management
helix (iteration)
software to build
3 Agile
2.1 software life cycle and configuration management,
agile development
 It advocates adaptive planning, evolutionary development, early delivery and continuous improvement, and to encourage changes to make fast and flexible response. Agile Manifesto in 2001, created by 17 famous "programmer." - the interaction between the individual and the processes and tools • self-organization and motivation are important, like hosting and knot is also important for such interactive programming. - more popular with comprehensive documentation and work through software • Working software over documentation provided to the customer at the meeting. - contract negotiations • Customer collaboration demands can not be completely collected at the beginning of the software development cycle, so ongoing customer or stakeholder participation is very important. - Key response instead of the planned change • Agile methods followed in rapid response to changes and sustainable development.
 two basic types: - Linear - Iterative  existing model: - Falls (linear, non-iterative) - delta (non-iterative) - V model (for authentication and verification) - Prototype (iteration) - helix (iteration)  critical mass considerations: - user participation (to adapt to change) - development efficiency, project management complexity - agile software quality: quick delivery
2.1 software lifecycle and configuration management,
agile development
 extreme user participation  extreme V & V minimum iteration 
2.1 software life cycle and configuration management
waterfall and Agile
2.1 software life cycle and configuration management Extreme Programming (XP)
Continuousdelivery
unit testing Continuous Integration
acceptance tests
pair programming
publish
user stories and acceptance test criteria value iteration plan
simple design CRC cards
spike solution prototype
reconstruction
software project incremental speed calculation
increments the number of users
test-driven development. (TDD)
Pairprogramming
continuous integration
reconstructed
building automation
prototype
iterations
2.1 software life cycle and configuration management
Pairing
2.1 software life cycle and configuration management tasks plate and progress monitoring
software building
4 collaborative software development
2.1 software life cycle and configuration management
open source
Richard Matthew Stallman (1953-) to the free software movement, GNU, Emacs, GCC, GPL , FSF famous
2.1 software life cycle and configuration management open source development model of
software builds
5 software configuration management (SCM) and version control systems (the VCS)
2.1 software lifecycle and configuration management software configuration management. (SCM)
SCM tracking and control software is changing mission.  supply chain management practices including revision control and establish baselines.
2.1 software lifecycle and configuration management configuration items (CI) of the life cycle of
any part  software (source code, data, documents, hardware, environmental) may be updated along with the software life cycle time.  software configuration item (SCI): basic structural unit of the SCM.
1.1 1.2 1.3 1.0
File 3File 2File 1Version Labels
final version of
Beta 1
1.0 1.1 1.2 1.3
1.0 1.1 1.2
1.0 1.1 1.2 1.3 1.4
2.1 software life cycle and configuration management configuration item (SCI) and baseline
 baseline at some point in time the product attribute agreed describes as the basis for the definition of change.
2.1 software lifecycle and configuration management CMDB and check-in / check-out audits
2.1 software lifecycle configuration management and
version
 software version control is the only state in the process to assign a unique version name or version number unique to the computer software. - the version number in the given category (primary, secondary) of these numbers are usually assigned in ascending order, and corresponding to the development of new software. - at the granular level, version control is often used for different versions of the track increment electronic information, regardless of whether the information is computer software.
2.1 software lifecycle and configuration management you're already using version control system
2.1 software lifecycle and configuration management why the need for personal version control
 to restore past versions  compare two different versions  push the version history to another location   merged version of the history back to the position from which is why the earlier version of the same branch require version control - teamwork
 communicate and share / merger between multiple developers work
 record a personalized work of different developers for auditing
2.1 software life cycle and configuration management branch and evolution diagram (SCI or system)
2.1 software lifecycle and configuration management
branch
 sometimes, part of the development you can continue to use abranch, which is a field parallel code, such as a new test features.  Other developers do not want to introduce new functionality prior to completion, even during this period to create multiple versions of coordination.  even a single developer to create branches will feel useful, because with Alice initially using the same cloud servers, although work alone.  In general, with many exchange programs for the state share would be useful. Positions may exist a plurality of branches, each branch positions shared by multiple programmers. With the right setting, any programmer can be pulled or pushed from any location to any location, creating a great deal of flexibility for cooperation.
2.1 software lifecycle configuration management and version control system (the VCS)
§ local VCS centralized VCS distributed the VCS
2.1 software lifecycle configuration management and version control system (the VCS)
§ local VCS centralized VCS distributed the VCS
2.1 software life cycle configuration management and version control system (the VCS)
§ local VCS centralized VCS distributed the VCS
2.1 software lifecycle configuration management and version control terminology
 repository: We project versions stored locally or remotely  working copy: We can handle local projects  an editable copy of the file: a single file of our project Versionorrevision: recording the content of our project at some point  Changeordiff:  the first difference between the two versions: the current version
features 2.1 software lifecycle configuration management and version control systems
 it should allow multiple people to work together: - merge: combined with general different from the previous version - tracking responsibilities: who made the change, who touched the line of code? - working in parallel: allows a programmer to work for some time (do not give up version control) - work in progress: allows multiple programmers to share unfinished work (without damaging other programmers, do not give up version control)
software to build
5 Git as an example of SCM tools
2.1 software lifecycle and configuration management
What is Git?
 Initial release: 2005 Initial Author: LinusTorvalds for the development of the Linux kernel.
Linus Torvalds (1969-)
change 2.1 software lifecycle management and configuration management software in the evolution
2.1 software life cycle and configuration management
Git repository
Git repository has three parts: - .git directory (storage stores all versioned data library) - the working directory (local file system) - the staging area (in memory)  each file belongs to one of three states: - modified files (in the working directory and git repository files differ, but not in the staging area) - subparagraph (file has been modified and added to the staging area) - was submitted (file remains in the working directory and git the same) directory)
2.1 software lifecycle and configuration management
object graph in Git
 We use Git perform all operations - add, commit, push, record, merge, ... - the operation of storage for all files Graphic version of the data structure, and a description of all log entries variations of these files. Git object graph stored in the repository in .git directory.
 copy git project from another machine / server means copying the entire object graph. - git clone object graph is what?
 object graph is Git project history, is a directed acyclic graph (DAG).
2.1 software lifecycle and configuration management
 Every time we submit is a snapshot of the entire project, Git with atreenode representative. For any reasonably sized project, most of the files will not change in any given revision. A redundant copy of files stored would be a waste, so Git will not do.  Instead, each to store a single version of FIG fileonce Git objects and allows multiple submissions to share a copy.  Each submission as well as log data - when and short log messages.
Submission: Object nodes in the graph
2.1 software lifecycle and configuration management management in Git change
 tradition the VCS:
 In Git:
2.1 software life cycle and configuration management to submit: node object graph
2.1 software life cycle and configuration management using git commit added to the object in FIG.
2.1 software lifecycle and configuration management using git push and git pull transmission and reception of the object graph
2.1 software lifecycle and configuration management Git support branch and the Merge
§ branch was revised object under the control of the repetition, so that modifications may be occur in parallel on the two branches.  The two branches merged together.
2.1 software lifecycle and configuration management branch
2.1 software lifecycle and configuration management to create and merge branches in Git
Checkout -b iss53 the commit git git
git git Checkout Checkout Master -b Hotfix the commit git
git git Merge Hotfix Checkout Master
2.1 software life cycle and configuration management to create and merge in Git branch
git git Branch -d Hotfix Checkout iss53 the commit git
git Checkout Master Merge iss53 git
2.1 software life cycle and configuration management Git support collaboration
 local repository and remote repositories
2.1 software life cycle and configuration management support collaborative Git
2.1 software life cycle and configuration management support collaborative Git
2.1 software life cycle and configuration management
GitHub : Git server-based Web hosting and Internet services. - It provides all distributed version control and SCM function Git, as well as add their own features. - It provides access control for each project and a number of collaboration features, such as bug tracking, feature requests, task management, and wiki. - private and free repository (for open source projects)  2016 years and it has over 14 million users, more than 35 million repository.
GitHub on
2.1 software life cycle and configuration management GitHub workflow
 basic process: submission, branching and merging  collaborative processes: fork and pull requests
2.1 software lifecycle and configuration management GitHub workflow
2.1 software life cycle and configuration management issue tracking and requests
software builds
6 Summary
2.1 software life cycle and configuration management
summary
 general-purpose software development life cycle (SDLC)  traditional software process model - waterfall, incremental, prototyping, iterative agile development    collaborative software development software configuration management (SCM) Git as SCM tools

Guess you like

Origin blog.csdn.net/t03010/article/details/93405469