User story là một câu chuyện có người dùng, hành động và kết quả. Nó thường được mô tả theo cấu trúc sau:
Là một [người dùng], Tôi muốn [làm gì đó] để tôi có thể [nhận được một kết quả nào đó]
Trong bài viết này, tôi sẽ sử dụng những ví dụ về một công ty tưởng tượng có tên là Enable Quiz. Công ty này đang xây dựng một ứng dụng giúp cho các quản lý nhân sự tìm kiếm các ứng viên dựa trên những kỹ năng cụ thể tương ứng với một bản mô tả công việc.
Ví dụ cho user story:
Là một quản lý nhân sự, tôi muốn ghép các kỹ năng của một vị trí cần tuyển với những chủ đề quiz, để tôi có thể tạo được các quiz lọc ứng viên
Các story thường được tổ chức theo mô hình top-down (từ trên xuống dưới). Sẽ có một epic story mô tả một câu chuyện tổng quát. Epic story này sẽ bao gồm nhiều user story, mỗi user story sẽ thực hiện một chức năng riêng biệt. Mỗi user story sẽ có nhiều test case để kiểm tra chúng
Tổ chức của các user story
Ví dụ cho epic story:
Là một quản lý nhân sự, tôi muốn tạo ra các quiz để tôi có thể dùng khi phỏng vấn ứng viên
Những thứ cần có để xây dựng user story
Người dùng là ai?
Nếu bạn không xác định rõ người dùng sản phẩm là ai thì sẽ rất khó để xây dựng user story. Và có thể bạn sẽ gặp phải lỗi the twin anti-poles of design failure:
Nếu bạn làm chính xác những gì người dùng yêu cầu, thì cuối cùng bạn sẽ rơi vào vòng lặp vô tận Product Death Cycle :
hỏi khách hàng chức năng nào đang thiếu
xây dựng những chức năng thiếu
không ai sử dụng sản phẩm của bạn
cuối cùng lại quay trở lại 1
Nếu bạn cho rằng mình biết rõ người dùng muốn gì, cuối cùng thì cũng không ai sử dụng sản phẩm của bạn
Để tránh lỗi thiết kế the twin anti-poles , hãy đặt mình vào vị trí người sử dụng (persona): đặt một cái tên cụ thể cho người dùng (ví dụ như chị quản lý nhân sự Helen) và đưa ra ý tưởng về mối liên quan giữa cô ấy và phần mềm của bạn:
Cô ấy nghĩ như thế nào về các mọi thứ vận động hàng ngày?
Cô ấy muốn trở thành người như thế nào?
Cô ấy nhìn thấy người khác làm những gì, và điều đó ảnh hưởng đến quan điểm của cô ấy như thế nào?
Cô ấy cảm nhận như thế nào về công việc của mình?
Cô ấy thực sự đang làm gì trong lĩnh vực nghiệp vụ mà phần mềm của bạn sẽ đụng chạm tới nó?
Nếu thật sự hiểu người dùng nghĩ - nhìn thấy - cảm nhận - làm những gì, bạn sẽ tìm ra được nhiều user story.
Người dùng muốn gì?
Hãy xây dựng một tình huống để mô tả cái mà người dùng muốn làm. Nó phải tương đối tổng quát để có thể tương đương với nhiều tình huống khác.
Ví dụ
Tình huống Tìm kiếm các tài năng kỹ thuật tương đương với đọc các CV hay là gọi điện cho các ứng viên. Vì vậy mà tình huống này sẽ xây dựng được những user story tốt
Tình huống Thuê được những tài năng kỹ thuật thì quá rộng
Các tình huống chi tiết hơn như Người quản lý nhân sự chuẩn bị một quiz cho một vị trí cần tuyển hoặc Người quản lý nhân sự gửi những ghi chú về các ứng viên cho một nhân viên HR khác thì quá chi tiết
Để thiết kế những user story tốt hơn
User story nên có mức độ chi tiết như thế nào là đủ?
Các user story nên chi tiết, mô tả hành động cụ thể, có thể test được và gắn liền với các tình huống
Ví dụ
User story Tôi muốn tìm kiếm các ứng viên kỹ thuật để công ty của tôi có thể thu được lợi ích tuyển dụng cao nhất thì quá rộng và không thể test được trực tiếp
Với tình huống Tìm kiếm các tài năng kỹ thuật thì user story Là một người quản lý nhân sự, tôi muốn tìm kiếm các ứng viên kỹ thuật để tôi có thể biết được những kỹ năng của họ là cụ thể hơn, có thể test được
Để tìm kiếm được hết các user story của một epic story, bạn nên sử dụng các storyboard. Đây là một công cụ bao gồm những hình ảnh với người dùng, hành động và bối cảnh. Nó mô tả epic story theo cách của một câu truyện tranh
Ví dụ với epic story Là một quản lý nhân sự, tôi muốn tạo ra các quiz để tôi có thể dùng khi phỏng vấn ứng viên
Storyboard
Kết quả có những gì?
Kết quả phải có thể test được, và là những gì người dùng muốn nhận được khi họ thực hiện hành động. Ví dụ với user story ở trên Là một người quản lý nhân sự, tôi muốn tìm kiếm các ứng viên kỹ thuật thì kết quả biết được những kỹ năng của các ứng viên có thể test được, nhưng nó không phải là kết quả mong muốn của Helen. Không phải ngẫu nhiên mà Helen tìm kiếm các ứng viên kỹ thuật, mà thường đó là do yêu cầu từ các phòng ban khác. Vì vậy mà kết quả có thể sử dụng thông tin các ứng viên khi phỏng vấn họ mới là cái mà Helen cần.
Test các User Story
Cần phải test những gì?
Việc test các user story không phải là kiểm tra với hành động của người dùng, họ có thu được kết quả đúng như trong user story hay không. Mà việc test các user story là kiểm tra xem họ có muốn thực hiện hành động trong user story hay không?
Vì thế mà bạn nên sử dụng công cụ BJ Fogg’s curve để mô tả nó:
Như vậy để có thể test được thì cần phải
Đưa ra một sự phân biệt rõ ràng giữa động cơ (motivation) thôi thúc người dùng sử dụng chức năng gắn với user story và tính dễ dùng (usability) của chức năng đó
Hiểu được mối quan hệ giữa động cơ và tính dễ dùng: nếu người dùng thật sự cần dùng ứng dụng của bạn thì cho dù nó có khó dùng đi nữa họ vẫn sẽ dùng. Còn nếu họ không cần dùng nó (ví dụ như trong trường hợp ứng dụng của bạn có nhiều đối thủ cạnh tranh) thì bạn phải cố gắng làm tăng tính dễ dùng của chức năng để lôi kéo họ
Test như thế nào?
Việc test các story nên được chia thành các giai đoạn (phase), mỗi giai đoạn bao gồm nhiều vòng lặp thiết kế (design)- xây dựng nguyên mẫu (prototype) - kiểm thử (test).
Giai đoạn khám phá (exploratory) có mục đích là tìm ra một hướng tiếp cận phù hợp cho việc test. Giai đoạn đánh giá (assessment) có mục đích là đánh giá chức năng đã hoàn thành chưa. Giai đoạn xác thực (validation) có mục đích là xác nhận xem chức năng đã sẵn sàng để triển khai cho người dùng hay chưa.
Khi nào story kết thúc?
Để trả lời câu hỏi này, cần phải hiểu rằng bạn không thể dự đoán được cái gì là có giá trị với người dùng. Do đó, bạn cần phải có những ý tưởng mà có thể test được và kiểm chứng nó bằng những thử nghiệm.
Trong trường hợp lý tưởng, story của bạn bắt đầu bằng việc quan sát người dùng và những vấn đề họ gặp phải. Sau đó bạn đưa ra 1 mô hình để đo lường được tính hữu ích của giải pháp của bạn.
Ví dụ điển hình của Lean UX là tạo 1 button giả trên ứng dụng. Khi người dùng click vào button đó, họ sẽ nhận được một thông báo "comming soon". Như vậy bạn có thể đo lường xem có bao nhiêu người dùng click vào button đó. Nếu như có đủ nhiều người muốn dùng chức năng đó thì hãy bắt đầu xây dựng các user story. Sau đó khi bạn release chức năng, bạn sẽ thu được những số đo về động cơ người dùng và tính khả dụng của chức năng. Lúc đó bạn sẽ biết khi nào story sẽ kết thúc (khi mà động cơ người dùng và tính khả dụng của chức năng rơi vào phần trên của BJ Fogg’s curve)
Phát triển ứng dụng với user story và story map
Ai viết các user story?
Vì user story là một khái niệm của Agile, nên người viết các user story tất nhiên sẽ là PO (Product Owner). Nhưng bạn hãy chú ý vài vấn đề sau:
1/40: theo một nghiên cứu của Stanford, mọi người chỉ hiểu 1/40 những gì bạn đã nói. Vì vậy nếu như PO đưa user story lên JIRA hay trello và cho rằng mọi thành viên đội phát triển đã hiểu, thì sớm muộn sẽ có hiểu nhầm.
Chúng ta đo hiệu suất của chính mình theo cách chủ quan: Bản chất của con người chỉ muốn biết đủ mức để giải quyết công việc của họ, và muốn biết rõ mình đã làm được đến đâu. Họ luôn muốn sự chắc chắn và cảm thức lập tức về sự hoàn thành. Nhưng làm phần mềm thì không như thế. Nếu bạn không hợp tác với đội phát triển để xây dựng lên các user story, họ sẽ cảm thấy mình không phải chịu trách nhiệm về nội dung của user story và không cần thiết phải suy nghĩ về tính khả dụng, tính thực tiễn của user story đó. Họ chỉ nghĩ rằng công việc của mình là biến user story đó thành chức năng chạy được.
Bạn không phải lúc nào cũng nghĩ ra được những ý tưởng tốt nhất. Vì thế mà PO nên tổ chức các buổi thảo luận để xây dựng user story
Sử dụng story trong nội bộ team như thế nào?
Chúng ta nên sử dụng story map, một công cụ giúp kết nối các story trong một epic với nhau và làm cho chúng trở nên trực quan với team phát triển.
Story map
Dải đầu tiên (stripe 0) là trục x của story map, mô tả các hành động của người dùng theo thời gian trong một epic story. Nó nên được mô tả bằng các hình ảnh lấy từ storyboard. Trục y mô tả thứ tự ưu tiên của các user story, như trong hình vẽ thì các user story trong dải 1(stripe 1) có độ ưu tiên thực hiện cao hơn dải 2 (stripe 2).
Sử dụng story hàng ngày như thế nào?
Để user story trở nên thân thiện dễ dùng, thì nó nên tuân theo quy tắc INVEST: Độc lập (Independent), Có thể trao đổi(Negotiable), Hữu ích (Valuable), Có thể ước lượng (Estimable), Nhỏ (Small), và Có thể kiểm chứng được (Testable).
Independent: các user story phải độc lập không phụ thuộc vào nhau. mỗi story đều có thể triển khai độc lập.
Negotiable: user story không phải là các yêu cầu bắt buộc phải tuân theo chính xác, mà nó có thể bị thay đổi cho phù hợp
Valuable: mỗi user story phải đem lại giá trị gì đó cho người dùng
Estimable: có thể ước lượng được độ lớn của user story (ví dụ cần bao nhiêu man day hoặc bao nhiêu point)
Small: user story nên đủ nhỏ để có thể đưa vào hệ thống, và dễ dàng thực hiện kiểm thử tích hợp (incremental integration testing)
Testable: người viết ra user story nên viết ra các test case cho nó.
“As a [persona], I want to [do something] so that I can [realize a reward]”
As an HR manager, I want to match an open position’s required skills with quiz topics so I can create a quiz relevant for candidate screening.”
organize stories: epic story -> user story -> test case
Examples for epic story: “As the HR manager, I want to create a screening quiz so that I can make sure I’m prepared to use it when I interview job candidates.”
Knowing If You Have a Story (những thứ cần có để viết 1 user story)
Who are we talking about?
the twin anti-poles of design failure:
1. Do precisely what the user asks => no one uses the product
2. assuming that you know the user and ignore them => no one uses the product
persona: be they buyer and/or user of your product
What do they want?
Example for Enable Quiz:
‘Hiring technical talent. => too broad, abstract
‘Screening technical talent.’ => probably about right
‘The HR manager preparing a new quiz from an open job description.’, ‘The HR manager sending notes on candidates to the functional manager.’=> too detail
Designing Better User Stories
What’s the right level of detail?
Example:
‘I want to properly screen engineering candidates so my company can get the best possible hiring outcomes.’ => too board
‘As Helen the HR Manager, I want to screen an engineering candidate, so I know their skills profile.’=> more specific
Use storyboard to explore an epic user story (images with users, actions and background)
What’s their reward?
testable reward
example:
so I know their skills profile => can not test
so that I can make sure I’m prepared to use it when I interview job candidates => testable
Testing User Stories
What are we testing?
the most important thing is to a) draw a clear distinction between usability and motivation and b) understand the relationship between them.
BJ Fogg’s curve
How do we test stories?
When is a story done?
you just can’t predict (with any consistency) what’s going to be valuable for the user. Therefore, you need to work with testable ideas and closed-loop experiments to see if you’re right or not.
Ideally your stories begin with some kind of observation about your user and the problems (jobs, desires) they have. Then you come up with a testable formulation of how you’ll know if your solution idea is really better than what they have now.
Developing with Stories & Story Maps
Who writes user stories?
Product Owner (PO)
But take care of Some problems
1/40: people only understand 1/40 what you said
We Measure our Efficiency Locally: A certain part of us just wants to know in the simplest possible terms what our job is and how much of it we have to do. We crave certainty and an immediate sense of accomplishment.
Unfortunately, you can’t build software that’s valuable to users this way (at least not with any consistency). If you don’t co-create stories with your team, they’re just not going to feel like they own them and their work won’t be as thoughtful.
You Don’t Have All the Best Ideas =>PO/story lead should run story writing workshops
How do you use stories within a team?
story map: (a tool that formulate the stories together and make them highly visible to the team) (image)
first stripe (0) defines the x-axis of the story map and represents the customer/user journey. It’s best built with storyboard squares.
The y-axis describes relative priority, so stripe 1 is higher priority than stripe 2 and so forth.
How do you use stories day to day?
use stories should follow the Bill Wake’s INVEST acronym: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
A flowchart is a type of diagram that represents an algorithm, workflow
or process, showing the steps as boxes of various kinds, and their
order by connecting them with arrows. This diagrammatic representation
illustrates a solution model to a given problem. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields.[1]
Flowcharts are used in designing and documenting simple processes or
programs. Like other types of diagrams, they help visualize what is
going on and thereby help understand a process, and perhaps also find
flaws, bottlenecks, and other less-obvious features within it. There are
many different types of flowcharts, and each type has its own
repertoire of boxes and notational conventions. The two most common
types of boxes in a flowchart are:
a processing step, usually called activity, and denoted as a rectangular box
a decision, usually denoted as a diamond.
A flowchart is described as "cross-functional" when the page is divided into different swimlanes
describing the control of different organizational units. A symbol
appearing in a particular "lane" is within the control of that
organizational unit. This technique allows the author to locate the
responsibility for performing an action or making a decision correctly,
showing the responsibility of each organizational unit for different
parts of a single process.
Flowcharts depict certain aspects of processes and are usually complemented by other types of diagram. For instance, Kaoru Ishikawa defined the flowchart as one of the seven basic tools of quality control, next to the histogram, Pareto chart, check sheet, control chart, cause-and-effect diagram, and the scatter diagram. Similarly, in UML, a standard concept-modeling notation used in software development, the activity diagram, which is a type of flowchart, is just one of many different diagram types. Nassi-Shneiderman diagrams and Drakon-charts are an alternative notation for process flow.
Common alternative names include: flow chart, process flowchart,
functional flowchart, process map, process chart, functional process
chart, business process model, process model, process flow diagram, work flow diagram, business flow diagram. The terms "flowchart" and "flow chart" are used interchangeably.
The underlying graph structure of a flowchart is a flow graph, which abstracts away node types, their contents and other ancillary information.
History
The first structured method for documenting process flow, the "flow process chart", was introduced by Frank and Lillian Gilbreth to members of the American Society of Mechanical Engineers (ASME) in 1921 in the presentation "Process Charts: First Steps in Finding the One Best Way to do Work".[2] The Gilbreths' tools quickly found their way into industrial engineering curricula. In the early 1930s, an industrial engineer, Allan H. Mogensen
began training business people in the use of some of the tools of
industrial engineering at his Work Simplification Conferences in Lake Placid, New York.
A 1944 graduate of Mogensen's class, Art Spinanger, took the tools back to Procter and Gamble where he developed their Deliberate Methods Change Program. Another 1944 graduate, Ben S. Graham, Director of Formcraft Engineering at Standard Register Industrial,
adapted the flow process chart to information processing with his
development of the multi-flow process chart to display multiple
documents and their relationships.[3] In 1947, ASME adopted a symbol set derived from Gilbreth's original work as the "ASME Standard: Operation and Flow Process Charts."[4] Douglas Hartree in 1949 explained that Herman Goldstine and John von Neumann had developed a flowchart (originally, diagram) to plan computer programs.[5] His contemporary account is endorsed by IBM engineers[6] and by Goldstine's personal recollections.[7]
The original programming flowcharts of Goldstine and von Neumann can be
seen in their unpublished report, "Planning and coding of problems for
an electronic computing instrument, Part II, Volume 1" (1947), which is
reproduced in von Neumann's collected works.[8]
Flowcharts became a popular means for describing computer algorithms. The popularity of flowcharts decreased in the 1970s when interactive computer terminals and third-generation programming languages became common tools for computer programming. Algorithms can be expressed much more concisely as source code in such languages. Often pseudo-code is used, which uses the common idioms of such languages without strictly adhering to the details of a particular one.
Nowadays flowcharts are still used for describing computer algorithms.[9] Modern techniques such as UMLactivity diagrams and Drakon-charts can be considered to be extensions of the flowchart.
Types
Sterneckert
(2003) suggested that flowcharts can be modeled from the perspective of
different user groups (such as managers, system analysts and clerks)
and that there are four general types:[10]
Document flowcharts, showing controls over a document-flow through a system
Data flowcharts, showing controls over a data-flow in a system
System flowcharts, showing controls at a physical or resource level
Program flowchart, showing the controls in a program within a system
Notice that every type of flowchart focuses on some kind of control, rather than on the particular flow itself.[10]
However, there are several of these classifications. For example,
Andrew Veronis (1978) named three basic types of flowcharts: the system flowchart, the general flowchart, and the detailed flowchart.[11] That same year Marilyn Bohl (1978) stated "in practice, two kinds of flowcharts are used in solution planning: system flowcharts and program flowcharts...".[12]
More recently Mark A. Fryman (2001) stated that there are more
differences: "Decision flowcharts, logic flowcharts, systems flowcharts,
product flowcharts, and process flowcharts are just a few of the
different types of flowcharts that are used in business and government".[13]
In addition, many diagram techniques exist that are similar to flowcharts but carry a different name, such as UMLactivity diagrams.
Shows the program's order of operation. A line coming from one symbol and ending at another.[14] Arrowheads are added if the flow is not the standard top-to-bottom, left-to right.[15]
Beginning or ending of a program or sub-process. Represented as a stadium,[14]
oval or rounded (fillet) rectangle. They usually contain the word
"Start" or "End", or another phrase signaling the start or end of a
process, such as "submit inquiry" or "receive product".
Conditional operation determining which of two paths the program will take.[14] The operation is commonly a yes/no question or true/false test. Represented as a diamond (rhombus).[15]
Additional information about a step the program. Represented as an
open rectangle with a dashed or solid line connecting it to the
corresponding symbol in the flowchart.[15]
A labeled connector for use when the target is on another page. Represented as a home plate-shaped pentagon.[14][18]
Other symbols
The ANSI/ISO standards include symbols beyond the basic shapes. Some are:[17][18]
Data File or Database represented by a cylinder (disk drive).
Document represented as a rectangle with a wavy base.
Manual input represented by quadrilateral, with the top irregularly sloping up from left to right like the side view of a keyboard.
Manual operation represented by a trapezoid with the longest parallel side at the top, to represent an operation or adjustment to process that can only be made manually.
Parallel Mode represented by two horizontal lines at the beginning or ending of simultaneous operations[17]
Preparation or Initialization represented by an elongated hexagon, originally used for steps like setting a switch or initializing a routine.
For parallel and concurrent processing the Parallel Mode horizontal lines[19] or a horizontal bar[20] indicate the start or end of a section of processes that can be done independently:
At a fork,
the process creates one or more additional processes, indicated by a
bar with one incoming path and two or more outgoing paths.
At a join, two or more processes continue as a single
process, indicated by a bar with several incoming paths and one outgoing
path. All processes must complete before the single process continues.[20]
Software
Diagramming
Flowgorithm
Any drawing program can be used to create flowchart diagrams, but
these will have no underlying data model to share data with databases or
other programs such as project management systems or spreadsheet. Some tools such as yEd, Inkscape and Microsoft Visio
offer special support for flowchart drawing. Many software packages
exist that can create flowcharts automatically, either directly from a
programming language source code, or from a flowchart description
language.
There are several applications and visual programming languages[21]
that use flowcharts to represent and execute programs. Generally these
are used as teaching tools for beginner students. Examples include Flowgorithm, Raptor. LARP, Visual Logic, and VisiRule.
Software design is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.[1]
Software design may refer to either "all the activity involved in
conceptualizing, framing, implementing, commissioning, and ultimately
modifying complex systems" or "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."[2]
Software design usually involves problem solving and planning a software solution. This includes both a low-level component and algorithm design and a high-level, architecture design.
Software
design is the process of implementing software solutions to one or more
sets of problems. One of the main components of software design is the software requirements analysis (SRA). SRA is a part of the software development process that lists specifications used in software engineering. If the software is "semi-automated" or user centered, software design may involve user experience design yielding a storyboard to help determine those specifications. If the software is completely automated (meaning no user or user interface), a software design may be as simple as a flow chart or text describing a planned sequence of events. There are also semi-standard methods like Unified Modeling Language and Fundamental modeling concepts. In either case, some documentation of the plan is usually the product of the design. Furthermore, a software design may be platform-independent or platform-specific, depending upon the availability of the technology used for the design.
The main difference between software analysis and design is that the
output of a software analysis consists of smaller problems to solve.
Additionally, the analysis should not be designed very differently
across different team members or groups. In contrast, the design focuses
on capabilities, and thus multiple designs for the same problem can and
will exist. Depending on the environment, the design often varies,
whether it is created from reliable frameworks or implemented with suitable design patterns. Design examples include operation systems, webpages, mobile devices or even the new cloud computing paradigm.
Software design is both a process and a model. The design process is a
sequence of steps that enables the designer to describe all aspects of
the software for building. Creative skill, past experience, a sense of
what makes "good" software, and an overall commitment to quality are
examples of critical success factors for a competent design. It is
important to note, however, that the design process is not always a
straightforward procedure; the design model can be compared to an
architect’s plans for a house. It begins by representing the totality of
the thing that is to be built (e.g., a three-dimensional rendering of
the house); slowly, the thing is refined to provide guidance for
constructing each detail (e.g., the plumbing lay). Similarly, the design
model that is created for software provides a variety of different
views of the computer software. Basic design principles enable the
software engineer to navigate the design process. Davis [DAV95][full citation needed] suggests a set of principles for software design, which have been adapted and extended in the following list:
The design process should not suffer from "tunnel vision." A
good designer should consider alternative approaches, judging each based
on the requirements of the problem, the resources available to do the
job.
The design should be traceable to the analysis model. Because
a single element of the design model can often be traced back to
multiple requirements, it is necessary to have a means for tracking how
requirements have been satisfied by the design model.
The design should not reinvent the wheel. Systems are
constructed using a set of design patterns, many of which have likely
been encountered before. These patterns should always be chosen as an
alternative to reinvention. Time is short and resources are limited;
design time should be invested in representing (truly new) ideas by
integrating patterns that already exist (when applicable).
The design should "minimize the intellectual distance" between the software and the problem as it exists in the real world. That is, the structure of the software design should, whenever possible, mimic the structure of the problem domain.
The design should exhibit uniformity and integration. A
design is uniform if it appears fully coherent. In order to achieve this
outcome, rules of style and format should be defined for a design team
before design work begins. A design is integrated if care is taken in
defining interfaces between design components.
The design should be structured to accommodate change. The design concepts discussed in the next section enable a design to achieve this principle.
The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.
Well- designed software should never "bomb"; it should be designed to
accommodate unusual circumstances, and if it must terminate processing,
it should do so in a graceful manner.
Design is not coding, coding is not design. Even when
detailed procedural designs are created for program components, the
level of abstraction of the design model is higher than the source code.
The only design decisions made at the coding level should address the
small implementation details that enable the procedural design to be
coded.
The design should be assessed for quality as it is being created, not after the fact.
A variety of design concepts and design measures are available to
assist the designer in assessing quality throughout the development
process.
The design should be reviewed to minimize conceptual (semantic) errors.
There is sometimes a tendency to focus on minutiae when the design is
reviewed, missing the forest for the trees. A design team should ensure
that major conceptual elements of the design (omissions, ambiguity,
inconsistency) have been addressed before worrying about the syntax of
the design model.
Design Concepts
The
design concepts provide the software designer with a foundation from
which more sophisticated methods can be applied. A set of fundamental
design concepts has evolved. They are as follows:
Abstraction
- Abstraction is the process or result of generalization by reducing
the information content of a concept or an observable phenomenon,
typically in order to retain only information which is relevant for a
particular purpose.It is an act of Representing essential features
without including the background details or explanations.
Refinement
- It is the process of elaboration. A hierarchy is developed by
decomposing a macroscopic statement of function in a step-wise fashion
until programming language statements are reached. In each step, one or
several instructions of a given program are decomposed into more
detailed instructions. Abstraction and Refinement are complementary
concepts.
Modularity - Software architecture is divided into components called modules.
Software Architecture
- It refers to the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system. Good
software architecture will yield a good return on investment with
respect to the desired outcome of the project, e.g. in terms of
performance, quality, schedule and cost.
Control Hierarchy - A program structure that represents the organization of a program component and implies a hierarchy of control.
Structural Partitioning
- The program structure can be divided both horizontally and
vertically. Horizontal partitions define separate branches of modular
hierarchy for each major program function. Vertical partitioning
suggests that control and work should be distributed top down in the
program structure.
Data Structure - It is a representation of the logical relationship among individual elements of data.
Software Procedure - It focuses on the processing of each module individually.
Information Hiding
- Modules should be specified and designed so that information
contained within a module is inaccessible to other modules that have no
need for such information.
In his object model, Grady Booch mentions Abstraction, Encapsulation,
Modularisation, and Hierarchy as fundamental software design
principles.[3]
The acronym PHAME (Principles of Hierarchy, Abstraction,
Modularisation, and Encapsulation) is sometimes used to refer to these
four fundamental principles.[4]
Design considerations
There
are many aspects to consider in the design of a piece of software. The
importance of each consideration should reflect the goals and
expectations that the software is being created to meet. Some of these
aspects are:
Compatibility - The software is able to operate with other
products that are designed for interoperability with another product.
For example, a piece of software may be backward-compatible with an
older version of itself.
Extensibility - New capabilities can be added to the software without major changes to the underlying architecture.
Modularity
- the resulting software comprises well defined, independent components
which leads to better maintainability. The components could be then
implemented and tested in isolation before being integrated to form a
desired software system. This allows division of work in a software
development project.
Fault-tolerance - The software is resistant to and able to recover from component failure.
Maintainability
- A measure of how easily bug fixes or functional modifications can be
accomplished. High maintainability can be the product of modularity and
extensibility.
Reliability (Software durability) - The software is able to perform a required function under stated conditions for a specified period of time.
Reusability - The ability to use some or all of the aspects of the preexisting software in other projects with little to no modification.
Robustness
- The software is able to operate under stress or tolerate
unpredictable or invalid input. For example, it can be designed with
resilience to low memory conditions.
Security - The software is able to withstand and resist hostile acts and influences.
Usability - The software user interface
must be usable for its target user/audience. Default values for the
parameters must be chosen so that they are a good choice for the
majority of the users.[5]
Performance - The software performs its tasks within a time-frame that is acceptable for the user, and does not require too much memory.
Portability - The software should be usable across a number of different conditions and environments.
Scalability - The software adapts well to increasing data or number of users.
Modeling language
A modeling language
is any artificial language that can be used to express information,
knowledge or systems in a structure that is defined by a consistent set
of rules. These rules are used for interpretation of the components
within the structure. A modeling language can be graphical or textual.
Examples of graphical modeling languages for software design are:
IDEF is a family of modeling languages, the most notable of which include IDEF0 for functional modeling, IDEF1X for information modeling, and IDEF5 for modeling ontologies.
Jackson Structured Programming (JSP) is a method for structured programming based on correspondences between data stream structure and program structure.
Unified Modeling Language
(UML) is a general modeling language to describe software both
structurally and behaviorally. It has a graphical notation and allows
for extension with a Profile (UML).
Alloy (specification language)
is a general purpose specification language for expressing complex
structural constraints and behavior in a software system. It provides a
concise language base on first-order relational logic.
A
software designer or architect may identify a design problem which has
been visited and perhaps even solved by others in the past. A template
or pattern describing a solution to a common problem is known as a design pattern. The reuse of such patterns can help speed up the software development process.[7]
Technique
The difficulty of using the term "design" in relation to software is that in some senses, the source code of a program is
the design for the program that it produces. To the extent that this is
true, "software design" refers to the design of the design. Edsger W. Dijkstra referred to this layering of semantic levels as the "radical novelty" of computer programming,[8] and Donald Knuth used his experience writing TeX to describe the futility of attempting to design a program prior to implementing it:
TEX would have been a complete failure if I had merely specified it
and not participated fully in its initial implementation. The process of
implementation constantly led me to unanticipated questions and to new
insights about how the original specifications could be improved.[9]
Usage
Software design documentation may be reviewed or presented to allow constraints, specifications and even requirements to be adjusted prior to computer programming. Redesign may occur after review of a programmed simulation or prototype. It is possible to design software in the process of programming, without a plan or requirement analysis,[10] but for more complex projects this would not be considered feasible. A separate design prior to programming allows for multidisciplinary designers and Subject Matter Experts (SMEs) to collaborate with highly skilled programmers for software that is both useful and technically sound.
Như vậy để có thể test được thì cần phải
Giai đoạn khám phá (exploratory) có mục đích là tìm ra một hướng tiếp cận phù hợp cho việc test. Giai đoạn đánh giá (assessment) có mục đích là đánh giá chức năng đã hoàn thành chưa. Giai đoạn xác thực (validation) có mục đích là xác nhận xem chức năng đã sẵn sàng để triển khai cho người dùng hay chưa.
