Part 1: Understanding the software process
1 Introduction
Software Process is a collection of all technical activities and management activities throughout the process of establishing, maintaining and evolving software products. At present, software process technology is a very active research area, attracting a large number of experts and scholars from academia and industrial communities. Software Process International Seminar (ISPW) has been held in 1994, and the International Conference (ICSP) of Software Process (ICSP) will be held since 1991. Each country has almost its own software process improved the network (SPN). There are three main directions of software process technology research:
(1) Software process analysis and modeling. Software process modeling method is the starting point of software process technology, in which form half form molding methods have rules based, process procedures, etc.. Process analysis and process modeling have an important role in ensuring the quality of process definitions, and has an important role in building a comprehensive and flexible process system.
(2) Software process support. Software process support mainly refers to the CASE tool for research and development of software process activities, and process support tools can be well supported, managed, and standardized software processes as a technology infrastructure. Software process support tools mainly include software process process tools, process stationary tools, review tools and personnel management tools.
(3) Software process assessment and improvement. The software process improvement has been recognized by more and more software development organizations for producing high quality software products and improving software productivity. Software Ability Maturity Model (SW-CMM) proposed by the US Carnemy Mellon University Software Engineering Institute (CMU / SEI) In addition to software process assessment, software organizations provide guidance to software process management and software Process improvement framework.
Rational Unified Process (RUP) is a software process product of Rational Software, which is evolved by the Objectory process. The initial version is 5.0, and it has experienced 5.1, 5.1.1, 5.5, etc. The version until the latest Rational Unified Process 2000 version. RUP is unified to project management, commercial modeling, analysis and design, and run through the entire development process. RUP uses Internet technology to enhance team development efficiency, and provide the best software implementation for all members, which makes unity of each developer's insights and ideas, making the communication team members easier, and This is a key factor in any project to succeed; it can enhance developers's predictiveness of software, and the ultimate benefit is to improve software quality and effectively shorten the software from developing to the market. The RUP process provides software development to provide normative guides, templates, and examples, which can be used to develop all types of applications.
2 Software process based on RUP
The software process in the RUP is decomposed into four order phases, respectively, which is the initial phase, refinement phase, a construction phase (construction), and transition. A technical review is scheduled to determine if the goal of this phase is satisfied. If the results of the review are satisfactory, the project can be allowed to enter the next stage.
RUP-based software process is an iterative process. Through the initial, refinement, constructing, and submission of four stages is a development cycle, one generation of software will be generated each time it passes through these four phases. Unless the product is retired, the product will evolve into the next generation of products by repeating the same four stages, but each side focus will be placed on a different stage. These subsequent processes are called evolution.
Changes in user needs, changes in operational environments, changes in basic technologies, etc., will cause evolution processes. Normally, the initial phase and refinement phase of the evolutionary process are relatively simple, as basic product definitions and architectures have been decided in the previous development process. But there are also exceptions, such as the modification process for redefining software architecture (Software Architecture). 2.1 Initial stage
The initial phase task is to establish a business model for the system and determine the boundaries of the project. In the initial phase, all external entities that interact with the system must be identified, defining the characteristics of the system and external entity interaction. It is concerned about the main risks of the business and demand of the entire project in this stage. For development projects based on the original system, the initial phase may be short.
(1) Clear project size
Establish a software scale and boundary condition of the project, including acceptance standards; understand the environment and important needs and constraints, identify key use cases of the system (USE Case).
(2) Evaluation project risk
The software process is mainly concerned about the known aspects of software development, only accurate description, planning, allocation, and reviews that already know what will be done. Risk management is mainly concerned about unknown. Many decisions are determined by risks during RUP-based iterative software. To achieve this, developers need to learn more about the risks faced by the project and have a clear strategy for how to reduce or handle risks.
(3) Develop a project plan
It is estimated that the overall cost, progress and personnel of the entire project are equipped. Comprehensively consider an alternative architecture, assessing the design and self-made / outlook / reuse of programs, thereby estimating cost, progress, and resources. In this process, the feasibility is demonstrated by confirming some concepts, which can be used in analog-to-demand model or an initial prototype for exploring high-risk zones. Prototype design work in the initial phase should be limited to the confident solution, and the specific implementation is left to the refinement phase and the construction phase.
(4) stage technical review
At the end of the initial phase, it is necessary to perform a technical review, check whether the target of the initial phase is completed, and decide to continue the project or cancel the project. In the process of review, it is necessary to consider the size definition of the project, cost and progress estimation is not moderate, and estimated whether it is reliable? Whether the demand is correct, the developer and the user agree whether the understanding of the software needs is uniform? Whether all risks have been determined, and there are problems such as avoiding policies for each risk.
2.2 Refining Stage
The task of the refining phase is to analyze the problem area, establish a sound system structure basis, phase out the highest risk of the project. In the refinement phase, it is necessary to make decisions on the architecture, including non-functional requirements such as performance, such as performance, etc., including non-functional needs such as performance, such as performance.
(1) Determining the architecture
Ensure that the architecture, demand and plan are sufficiently stable, fully reducing risks, and can be predictive to determine the cost and development schedule required for development. Establish an architecture that determined baselines by processing an architecture important scene (Scene). It is proven to establish a baseline architecture to properly support system requirements at a reasonable cost.
(2) Develop a construction stage plan
Develop a detailed process plan for the construction phase and establish baselines.
(3) Establish a support environment
Establish support environments, including development environments, development processes, and support tools and automation / semi-automated support required to build teams.
(4) Select component
Evaluate existing (component libraries) and potential components, fully understand the self-made / outlook / reuse decisions, in order to be grasped to determine the cost and progress in the construction phase. Integrate selected components and assess them as main scenarios.
(5) stage technical review
When reviewing, you need to test detailed system objectives and scope, architectural choice, and solutions for major risks. In technical reviews, the issues that need to be considered are:
(1) Is the product demand stable, is the architecture stable? (2) If the prototype does it indicate that the main risk elements have been found and properly solved?
(3) Whether the iterative plan in the construction phase is sufficiently detailed and true, is there a reliable estimation support? Can you guarantee your work continues?
(4) All unanimous people related to the project is consistent, if the current plan is executed in the current architecture environment, the current needs can be implemented?
(5) Does the actual resource cost compared to whether there is a deviation compared to the cost of the plan, is the deviation acceptable?
2.3 Construction Stage
In the construction phase, all remaining components and application functions are developed, integrating these components as products and perform detailed tests. In a sense, the construction phase is a manufacturing process, focusing on managing resources and control operations to optimize cost, progress, and quality.
The main task of the construction phase is to minimize development costs by optimizing resources and avoid unnecessary scrap and rework; complete analysis, development and testing of all required functions, fast completion of available versions; determining whether software, venues and users Already prepared for deployment software.
In the component phase, the development team's work can achieve some degree of parallelity. Even smaller projects, also usually include components that can be developed independently, thereby enabling parallel development between teams. This parallelism also increases the complexity of resource management and workflow synchronization while significantly accelerating development progress.
Technical reviews should also be reviewed at the end of the construction phase, and whether the product can be installed and operated in the beta test environment. In the review, the problems that need to be considered are:
(1) Is this product release to stabilize and mature, can be installed and run in the actual environment of the user?
(2) Whether all people related to the project are ready to release the product to the user?
(3) Does the actual resource cost have a deviation compared to the cost of the plan, is the deviation acceptable?
2.4 Delivery Stage
When the baseline is perfect, it can be installed into the final user's actual environment, then enter the delivery phase. The focus of the delivery phase is to ensure that the software is available for end users.
The main task of the delivery phase is to perform beta test, making product release versions; regularly support documentation for end users; confirm new systems according to user needs; training users and maintenance personnel; obtain feedback from users to current versions, based on feedback adjustment products, such as feedback Enhancement of debugging, performance or availability.
Depending on the type of product, the delivery phase may be very simple, or it may be very complicated. For example, the new release of the existing desktop products may be very simple, and the air traffic control system that replaces a country may be very complicated.
At the end of the delivery phase, technical review is also possible, whether the target is implemented, whether the evolution process should be started, and the user is satisfied with the product delivered.
2.5 Technical Review
A technical review is performed at the end of each stage to determine whether the project should enter the next stage after completing the final iteration of this phase. The main issues for technical reviews should be mainly related to project management, because the main technical issues should have been solved in the final iteration of this phase and subsequent activities.
(1) Arrange the review meeting schedule
Participants of the Technical Review Conference must include external personnel (user representatives and field experts), project management team (project manager, team leader in the project team) and project review committee.
Once the participants are determined, they should arrange the date and time of the meeting, so that they will leave sufficient preparation time for participants, allowing them to review the relevant materials.
(2) Distribution Conference Materials
Before the meeting was held, technical review materials should be distributed to reviewers. It is necessary to distribute these materials before the meeting, allowing the reviewers to review them with sufficient time.
(3) Convening a review meeting
During the meeting, the reviewers mainly pay attention to the status assessment. At the end of the meeting, the reviewers should make a decision for approval. The technical review meeting may get one of the following results:
(I) The stage was accepted: The review committee considers the project to achieve the expected goals of this stage, which can enter the next stage.
(II) Conditional acceptance: The review committee agrees that the project can enter the next stage, but must first complete the specified corrective operation. If the problem is found, it is very small and is not very important, the customer may decide to accept the product while the project team performs some corrective operations. In this case, the project manager needs to process the problem based on the importance of the problem, or to start a new iteration, or only process the problem, or only by extending the final iteration, the difference is the required plan workload. .
(III) Stage is not accepted: The project does not implement the expected goal of this phase, the project manager may have to start another session, and even the project manager cannot determine the problem with the problem, and the relevant personnel need to re-determine the size of the project according to the contract or Terminate the project.
(4) Record meeting decision
The review records should be completed at the end of the meeting, including important discussion or activity and the results of the review. If the result is "Stage Not Accepted", you should temporarily arrange a follow-up review.
3 application examples
In the initial stage of the project, the software scale and boundary conditions of the project are mainly established, clarify the needs of users, and form specifications, as acceptance standards. At the same time, it is estimated that the overall cost and progress of the entire project, assessing potential risks, making a project plan with 20% resource reservation. Finally, according to customer requirements, choose Analysis and Modeling Tools, project management tools. System development tool, background database management system
In the refinement phase of the project, the software architecture is selected according to the actual needs. For some key algorithms, the prototype of exploration is produced. On this basis, a detailed iterative plan is developed for the construction phase. In terms of the selection of components, it is mainly used to use the existing components, which are re-developed.
In the construction phase of the project, complete the development and testing of the new component, integrate all components, and integrate tests. At this stage, it is widely developed in parallel development.
In the delivery phase of the project, the software that has been integrated testing is installed and the actual environment is accepted. Then conduct training and guidance on users and maintenance personnel.
RUP-based software process, standardize management and development processes, effectively controlled resources, and projects are expected to be completed underver whereby reserved resources is used. During the system operation, the software will evolve the process, eventually transition from a software project to a product.
4 Conclusion
RUP is in terms of the development of the iterative development process, demand management, component-based architecture, visualization software modeling, verification software quality and control software change, etc., for all critical development activities provide the necessary guidelines, templates, and Tool guidance. It has established a concise and clear process structure that provides greater versatility for the development process.
RUP-based software can reduce product risks, standardize management and development processes, effectively control resources, and improve development efficiency.
Part II: Steps and Suggestions for RUP Implementation
Submitted a discussion as follows by the actual situation of the project implementation in half a year
Initial stage
Final goal:
Provide project scale and project risk assessment and project implementation plan. That is: We have to do those work [Fair is not good.]
Need a person:
Understand the quality of the needs of the needs: Communication ability is more powerful [language expression ability] to have a certain extent of technical risks, good at guiding customers [some aspects can think about customers.] Production results:
Main use cases, assessment results text, project plan documentation in a relatively rough project.
Precautions:
I think that the most important thing to understand is to analyze the organizational structure of customers. As long as you understand the function of organizational structure, I think business logic will not have a big deviation, which is enough to have a typical use case for the initial phase outlined business. And The system's extension upgrade also provides a large policy [specific to the design, the possibility of considering it is more comprehensive]
Discussion hotspots:
Estimated demand often changes where you want to change
Key technical reserves can meet the needs [Do you need self-research]
2. Refining the stage
Final goal:
Submit a detailed demand analysis report, complete system design and programming.
Need a person:
You should use experienced developers to avoid delays because of programmers are not familiar with business; do not occupy time in interface design; if users have put forward a lot of opinions on prototype, some of which are more clear opinions can be developed Realization; and customer communication should be concise, not similar to not; in addition, the prototype method takes time occupied in the project program, not just a part of demand research and analysis.
Note: [Under condition, create prototype DEMO to the user to collect customer opinions]
How to avoid users to see the prototype and have no margin.
First of all, we should fully respect the customer. Think about the quality of service in other industries. Have you heard such a statement, project management is also the management of customer satisfaction; software is a kind of care for customers, and so on. Indeed The idea may be different from the ideas you have formed, and suddenly disrupted your ideas, maybe the project manager does not mind, but this is really a matter of being very annoyed. If you are checked, or you can not do it. The prototype is going. Sometimes, even if the prototype is perfect, the user will additionally put forward some opinions. This is also a human condition. But no matter what, you can't think that the user does not understand the software, let them use it when you use it, hug Most of the idea will pay a price.
Secondly, you should conduct frank consultations. Most users are actually reasonable. If you promise to meet any requirements while signing the contract, and then you can't stand the requirements of the user, then you should not be an intention of you. General comment To put it more reasonable approach, it can be submitted by increasing cost, extending progress, or putting demand to maintain its continuity. For some software, especially information management systems, customers' implementation time is not mainly It is not timely, but it is useful.
In fact, customers have many types, indeed, individual customers will refer to the same type of products, and extreme users don't really understand computer technology and propose their opinions on technology routes, technical means, etc., and so on. But why can we Come over, if you wait until the software is all submitted, this part of the user will still make the same opinion. Adversely exposed and resolved the differences, it is good for both sides. If the software company knows that there is a contradiction, it is still doing it. Then wait until the user is opposed, then propose a supplementary charge. If you like it, you should not say it.
In summary, the prototype should be made in accordance with the basic understanding of the software requirements, so that the inconsistency can be prevented. In particular, it should be made to the unclear place to make prototypes, thus trying to expose the problem, trigger the user's association, can not avoid problems, cover the problem ( In order to prevent users to make too many ideas), many problems have masked, but eventually will happen.
Discussion hotspots:
The completion flag of the initial phase is an iterative, detailed analysis of business model, generating system structure and module division
produces result:
Demand analysis report and programming documentation
3. Construction stage
Final goal:
Complete encoding work
Need a person:
Coded old hands [programmers who have long-term stable to write high quality programs]
Precautions:
Test and processing of code operating environment [It is recommended to regularly have a naked machine for code test operation environment]
produces result:
After packaging the lacquered software, the original code of various versions of the package
4. Delivery phase
Final goal:
Frank is the project remuneration.
Need a person:
Testers
Precautions:
Software Testing is the primary means of discovering errors and defects in software. In general, software testing processes are basically parallel to the entire software development process. Of course, test programs should start in the demand analysis phase. The subsequent work will be gradually expanded with the process of software development. I think our software will be tested by the specified special person test during the delivery phase [can fill in the test feedback form to the code writer, so repeat]
produces result:
Stable in the customer's environment.
Some concept explanations:
No data prototype demonstration:
1. Nothing according to the main goal of the demo version is to demonstrate the future outline of the system to the direct user, and the user can be very intuitive to experience the system to make more objective needs. 2. Establishing the Digital Demo Edition should be placed in the demand process, RUP's fine During the stage.
3. No data is required to include the system representation layer, and do not require any logical layer and data.
5. Nothing according to the demo version is generally completed by interactive creative designers, and people in this post should have participated in business and demand analysis with relevant personnel.
Interactive creative designer:
Not only the design of the UI, including the optimization of the workflow, consideration of the interface (art and layout), workflow to the customer's psychological impact (user psychological excavation) and product ideas.
Creative designers lead and coordinate the prototype design and formal design of the web interface through the following methods: Get the requirements of the web interface (including availability requirements), build a web page prototype, enabling other people in the web interface (such as end users) to participate in availability Review and use test meetings, review, and provide appropriate feedback on the final implementation of the web interface (created by other developers, such as designers and performers).
Human-machine interface overall planning and how to make a business flow
Note
Demand experience:
Software can be divided into project software and product software from the perspective of the scope of use.
Project Software: That is for a particular customer request, only software used for it. Also known as engineering software, characterized by a clear contract, strict construction, agreed maintenance period, etc.
Product Software: Software developed for a common demand for customers in a field. Features are common, rich and redundant, through one-time purchase behavior, etc.
In order to analyze the needs of the project software, some views and recommendations are proposed.
1. Determine the appropriate customer partner in accordance with the analysis stage
This is very important for getting real user requirements. Typically, the client will organize people who have launched the above-level person or a small-owned computer can cooperate with the developer's analyst, and jointly organize demand.
The customer party should be classified, hierarchically, and each phase of the analysis should be made.
The initial stage of analysis, that is, the overall analysis phase, it is necessary to obtain the overall contour demand. At this time, it should be exchanged with the personnel of the customer's leaders. This level of people will have a complete depiction of the future system. It can be divided into a subsystem, and the relationship between it is also the expectation of the advanced management to the system. It can be further analyzed as a program-specific document guidance, and constrain subsequent analysis processes, avoiding the need for a demand.
Professional system analysis stage, usually, the customer unit will have a professional division of labor, which is independent of each other and will contact some points. This phase should be discussed in depth with the personnel of the client. This level People who are quite familiar with their majors. The demand for their professional will be very in place. Most of them are rich, with considerable experience and understanding, and even they can draw business flow maps, summarize business function points. They should fully encourage them. Try to mobilize its enthusiasm;
In the system-related analysis phase, based on the full analysis of each professional system, it is necessary to clarify the relationship between them, which is a key stage of improving the demand grade, and the stage of senior leadership and specialist concerned. Usually Customer units will have some scattered software, such as financial software, deputy software, etc., these professional software play an important role, but they are some information. The customer will naturally integrate this information to the entire system. In the middle, it is shared for more people. At the same time, it is also hoped that the data can flow smoothly in various professional systems, thereby reducing duplication of labor and improving work efficiency. At this stage, the total workers should be summoned together. Commonly clarify the interface between the system.
After these three phases, the description of the needs will be more accurate and complete.
2, multi-faceted describes the same needs
Some requirements run through the grassroots people to the high-level leadership, and the needs should be described from all angles, each orientation to describe it, otherwise some information may be missed. This is also a subsequent design work. Good foundation.
3, clear each data item
Since the demand will be the foundation of the design, it is essential for the design of all the data items. It cannot be ambiguous place. At the same time, through the analysis of data items, you can make the analyst to see more clearly. The flow of data will also find some new demand points.
4, fully excavate potential demand
Since the analyst is very familiar with software technology, some potential demand brought about by technology is generally difficult to discover for customers. Do not achieve these needs, there is no substantial impact on the entire system; implement these needs, Add a flower on the brown.
There are two ways to handle these potential demands: telling customers that customers will be inspired, may further put forward new needs, there will be some more bold ideas, thereby expand demand, increase workload, and even affect During the period; do not tell customers, wait for the customer to say.
If these requirements may be a selling point, you can take it as much as possible. But consider all kinds of risks, sometimes avoided, or conceal your customers. No matter whether you tell customers, analyze The person should still go to mining, at least as its own knowledge accumulation. [Frank with a spare plan]
5, use scientific analysis report template
After the analysis is completed, it is necessary to form a "demand analysis report". It should adopt a standard scientific report template. It is very detailed through ISO or CMM, and its template is very detailed, not only as a report template, but also guided the analysis process.
For example, I have previously prepared a normative demand analysis report to write a guide, report template, and "demand matrix" and "demand change report" for management requirements and control changes.
6, accumulation of knowledge
The domain knowledge is important for analysts. The breadth and depth of these knowledge affect the accuracy and analysis progress of the analysis results. Analysts should get these, constantly accumulate, and compare and summarize.
7, attitude toward learning and guidance
In the face of a new customer, the analyst must first hold the attitude of modest learning, regard this as a chance to enrich the domain knowledge. However, there are anything worth learning from any level, with analysis The people in the field of personnel are increasing, and the analysts will become deeper and deeper, gradually grow into a field expert. There will be many places more than the understanding of the world. At this time, we must understand our own in-depth understanding Guide customers, convince customers, and even correct some of the misunderstanding of customers, and get customers' trust and respect, which is very helpful for rapid successful completion requirements.
8, misunderstanding
When performing demand analysis, it is easy to fall into some misunderstandings, resulting in the analysis results.
The more complicated the analysis results, the better
This is the case where the technical analyst is often encountered, and it is believed that it analyzes the relationship between the error, the fancy chart can show the high analysis level. In fact, the analysis often experiences "simple-complex-simple" process, the previous simple and manifestation The analyst "thinks simple"; with the in-depth analysis, the original thought that simple problems will become more complicated; finally, after summing, digestion, decomposition, make the demand simple.
Must be in place
Due to the tightening of the project, or the customer unit is remote, do not want to go to the scene, I hope to get a complete result of the result of a complete change through a demand analysis. When this is the case, the analyst is chasing the customer Farm, or insist on requesting the cooperation of people to make a guarantee, the promise demand is no longer expanded. As a result, the relationship between the two parties is tight, and the cooperation personnel are responsible, and too flexible, configurable requirement, no end increase Subsequent design and encoding workload. The idea in place is unrealistic. As the development work is carried out, users often ask the needs of the previously did not expect, or change existing needs. Need must have an iterative process, change Is inevitable, the key is to control the changes in changes, such as the cost of increasing the demand change, informing the customer, will extend such changes, or additional funds, etc. The current situation of the buyer's market, the development side often can't afford this board, but such control has a certain effect.
Customer needs must be met
Analytical personnel who have fallen into this misunderstanding often have lacking their own knowledge, whether the needs of customers are reasonable, lack of resolution, can only be taken by customers, this will bring great risks: resulting in demand redundancy, project rework More danger of demanding changes, with the development of the project, the entire development team will become more painful. Therefore, you must deepen your own knowledge, change the passive acceptance of active guidance, and then reject the unreasonable demand for customers.
Implementing Regulations:
Interface design and test rules
The interface is the most direct layer of software and user interaction. The interface is good and the user determines the user's first impression of the software. And the design has a good interface to guide the user to complete the corresponding operation, play the role of the guide. At the same time, as a person Face, with direct advantages of attracting users. The design reasonable interface can bring easy feelings and success of users. On the contrary, due to the failure of interface design, it is possible to make users with frustration, and then practical power can be in the user. Fear and abandoning the Dangdao. The current interface is still far less than the level of software designers. .
Part III: RUP implementation
About the standards of documents, based on software design documents, national standards GB8567-88 have certain changes
About the Chinese data implemented in RUP can be downloaded on the FTP site
Ftp://10.70.151.253/rup_plan/rupchinese/
See all document templates
Ftp://10.70.151.253/rup_plan/dot/
UML Design Tools [We use Microsoft Microsoft Visio] See: ftp: //10.70.151.253/rup_plan/tool/
Version Control Tool [We use Microsoft Microsoft SourceSafe] See:
Ftp://10.70.151.253/rup_plan/tool/
Document specification:
1. Initial stage:
Rough business typical use case [Destination better understanding of demand]
Project plan [specified according to the analysis of the software scale]
2. Refining the stage:
User Demand Manual [Business Use Examples and Business Borders after Refining Demand]
System Analysis Design Report [Provide policy and operational environmental assessment and development platform tools, division system module]
Database Design Report [According to the business logic portfolio data relationship, the focus on the high frequency retrieval to create a view or process]
Administrator's Manual [Description of Run Environment Configuration and System Auxiliary Module]
User Manual [Describe the interface design, torelation]
Test sample [Provide a basis for the code test]
Program Design Document [Use case of the module to write]
3. Construction stage:
Project Progress Report [Project Progress Feedback (once a week)]
Technical Discussion Draft [Multi-person collaboration project regularly held discussions (depending on the time cycle)]
4. Delivery phase:
Training plan
Project Summary Report [Different documents in response to customers]
Code specification:
Due to different development tools, the rules are different. See the documentation on the FTP
Here I mainly say a few principles:
Follow Hungarian nomenclature
Documents or classes in the project should be deleted, and non-engineering documents in the project catalog should also be removed, keeping engineering clean, avoid confusion is difficult to manage.
Puminate the modules that are relatively independence, make DLL, controls, or COM components or JavaBean, etc., which can be written and tested separately and enhance their reusability.
A relatively large engineering should have a certain message interface or plugin interface, etc.
The annotation of the code must reach more than 20%.
Our goal is to let collaborative developers as much as possible to read the code as soon as possible, easy to troubleshoot. [Master this principle can be.]
Interface specification:
This rule is even unable to review [reference rules in FTP sites], I said a few principles:
The position of the screen diagonal intersection is where the user's direct view is, and in the top quarter, it is easy to attract the user's attention. When placing the form, pay attention to the use of these two locations.
Aspect ratio is close to the gold segmentation point.
Color tries to use a color system [to reflect corporate culture or product image]
Our goal is to make the software's life, good software interface can enable a certain help [fool type, Microsoft window is a model] also makes the user a happy mood.
Code backup:
Version control problem
Supplementary question:
Part IV: RUP implementation expected results
At the end of the year
1. Preliminary formation of CMM management ideas and system specifications
2. Accumulate a certain reusable code
3. Problems encountered by the project can be used to express [to do the rigidity, you can say it clearly]
4. Through a variety of specifications, new people [Reading company accumulate speed increase] The training time is reduced, and a rational developer team is established.
