Software method Reading notes (i)

"Software Method" is about usingUMLlanguage to assist US in the software0to the1the process. The result of this process is not the interface that eventually runs on the computer screen, but a pile of drawings and visual drawings.
Yes, it is indeed a drawing. Construction industry has design and construction drawings, electrical industry has design and implementation of drawings, urban planning has drawings··· ···any project you can see has drawings, you have to write the software actually did not.
“the blueprints are in my head.", I have said. Until you see the book.
The direct audience of this book should have two categories of people:
1.Programmer
This kind of person's general work idea is to mention the function of the person said to do what, um oh oh after, can't wait to open the editor to start writing code, debugging, and then found that the finished things, always be told to modify, not play no change.
2.Project Manager
This kind of what we call"ITContractor", they need to talk to customers about demand, turn around and tell the programmer. As an intermediary, both sides have to communicate, the reality is that both sides are not good communication. Isn't that what the user is saying? How to make something is wrong! Faced with demand and change, they are the most helpless, because they are not only the process, but the cost and efficiency of the company.
I even recommend the product manager to take a look at the book, as it is the first thing to think about what a product needs to meet and what features to provide. The progressive iterative improvement of lean thinking is true, but it also requires you to understand what real customer value your product can bring at the beginning of the product.
I'm glad to be able to work in the first8years to see this book, and more honored to be with their team to use the7class to discuss learning together and do homework together. The most exciting thing is that every time we have a project discussion, we start with the knowledge learned in the software approach, and do what we do every day in new ways: internal communication is more structured, demand changes more carefully, and customer communication is more efficient.··· ···

After reading this masterpiece of teacher pan, my overall impression is:
Unclear concepts, improper use of words, rambling, logical confusion.
The most ridiculous and absurd mistakes in the book include:
-design constraints are requirements, but not functional requirements, nor non-functional requirements (teacher Pan does not understand the simplest two-dollar logic?) );
-Book for"Stakeholder"(StakeholderThe understanding of this basic term is almost all wrong and inconsistent;
-UMLmodels are not used to communicate with stakeholders! (It's hard to believe that this is aUMLthe chief expert's remarks);
-stakeholders are neither qualified nor responsible for providing demand;
-putActortranslated into"Performer", leading to many faulty wordings that violate Chinese common sense, such as: The People's Bank is the executive of the commercial Bank, the patient is the hospital executor;
-systemActorand important irrelevant, and important related concepts are the stakeholders;
-Viewers (stakeholders) look under the table,Actorperform on stage (in fact, the actors on the stage are also stakeholders);
-requirements or use cases."Particle size","level"These concepts do not actually exist, and the misleading of developers is rather serious;
-design is code, so design workflow does not recommend paintingUMLdiagram;
-interface components are not requirements. Man has eyes not demand;
-in chapter two or three, we introduceUMLuse case diagrams and business sequence diagrams with no emphasis on business activity diagrams and no detailed descriptionsUMLother graphs commonly used in demand analysis, such as system sequence diagram, activity diagram, state diagram, etc. (content is thin, one-sided);
-Section2chapter of the so-called"Vision", just a few"boss"or a stakeholder's goal, the name"Metric Metrics", but even a number does not indicate that the actual content and vision document is far from the gap;
-as a masterpiece of demand analysis, from the first3Chapter to article6Chapter focuses only on dynamic modeling using use cases, without detailing the other half of the requirements analysis--static modeling (such as domain modeling, conceptual modeling);

1-Organization Modeling(Business Modeling): Remember that the system you are developing is simply replacing the labor costs in your organization, so the objects you are modeling are organizations rather than systems.
Key steps:
1.Determine the modeling organization: (The selection of the organization needs to stand in the main interests and involves of the masses of the perspective of consideration, do not hasty selection of the company this large-scale organization. For Internet projects, the target group of the project should be selected for organization. ) Draw a circle, putting most of the blame may be (partly/all) replaced system (Human flesh system/Computer system...) wrapped inside.
2.Draw an organization (business) use case diagram and sequence diagram: (Externally, you can represent an organization with a business use case diagram.) From the inside, you can represent your organization with a business sequence diagram. )
The purpose of the research organization is to hook the value of the system to the value of the organization and give the organization a reason to buy the system.
1).Business use case diagram:
A.Identify business performers: Find the performers (business performers) of an organization, people who interact with the organization outside the organization. (A business performer is an organization or a crowd, not a system.) )
Thinking: The camera is aligned to the organization's boundaries, who is looking for an organization, who sends an email to the organization...and so on, who is likely to be a business performer.
B.identify business workers and business entities: The business worker is the human system within the organization (the business performer is outside the organization), the worker within the organization, and the business entity is the non-manual system within the organization.
Business workers and business entities are cost rather than value for the organization, so they are not present in the business use case diagram, but are placed in"Business Objects"in the bag. It is not necessary to draw business workers and business entities when identifying business performers, and add them when drawing business sequence diagrams.
C.Business use cases and business processes: Consider business processes as implementations of business use cases and organize them under business use cases. Everything that happens in the organization is designed to provide value to business performers.
Identify business use cases: The first route is also the main route, starting with the business performer and thinking about the purpose of business execution and organizational dealings. The focus of thinking is"Performers ' expectations of the organization and the Organization's commitment to the performer"balance Point. The second way is by observing the internal activities of the Organization, and always asking why, to a business performer outside the organization.
The main performer and the secondary performer: the performer points to the use case, which is the main performer, and the use case points to the performer as the secondary performer. Such as:"Publishing House→Promotional Books→External Translator"this can be interpreted as: in order to provide publishers with the promotion of books services, organizations rely on their own strength is not enough to complete, need to find external translators to help.
Note: Business use cases are organizations that serve the organization, and in different scenarios, the systems of two organizations form different interactions. A business use case is an organization, not a use case for a system within an organization.

2). Business Sequence diagram: There are three ways to describe business processes: text mode, business activity diagram mode, and business sequence diagram mode. The text way is not vivid, not recommended, business activity diagram is the mainstream way, but the recommended is the business sequence diagram. The interaction overview diagram of UML is a series of sequence diagrams of each scene in the form of activity diagram, which is equivalent to the characteristics of activity diagram and sequence diagram.

Software method Reading notes (i)