Fundamental Software Engineering Processes
There are two general design processes in software engineering:
- Waterfall process
- Iterative process
Waterfall Design Process
The waterfall process follows a step by step sequence, beginning with analysis of the proposed product and ending with testing the implementation.
The 4 step waterfall process:
The 4-step waterfall is a very general problem solving technique and can be used in many domains. The steps refer to:
- studying the problem
- conceiving a solution
- implementing the solution
- checking the solution
The 4 step process is too general to capture all the steps required to develop a larger system. Developing larger systems becomes more involved because the system cannot be implemented in its totality, all at once. More steps are added to identify, design, implement and integrate the components.
The 6 step waterfall process for developing larger software:
- Requirement specification
- Architectural design
- Detailed design
- Coding and unit testing
- Integration and testing
The designer and client describe what the systems should do in the requirement specification. The requirement specification should describe the costumers, the work environment, and the functionality of the system. The architectural design is a top level design which describes how the system should provide the functionality. Architectural design identifies the components of the systems, and the resources that components will use. In software development, the detailed design describes the components in sufficient detail to program the components. Coding and unit testing is programming the components and testing the individual components. Integration and testing brings the components together. The integrated system is tested to ensure proper synchronization of the components and that the shared resources are used properly. After the software is released, it is maintained. Maintenance identifies mistakes made in the previous 5 steps and attempts to correct the mistakes. These corrections typically are patches for the system. Maintenance can provide feedback to all the steps during the development of a new version of the system or software.
Side note: Checking the correctness of software typically involves validating and verifying. Validating is checking that the software provides what the customer wants. Verifying is checking that the software produces the correct results. Boehm describes the difference, “validation is designing the right thing and verification is designing the thing right.”
All waterfall design processes have the primary advantages that they are clear and results in a definitive product at the end of process. They have the disadvantage that issues in the early phases of the design process are not always illuminated until later phases of the design process. For example testing the implementation may illuminate design flaws that require reconsideration. So, an iterative design process is generally more appropriate.
Iterative Design Process
The iterative process assumes that the final product cannot be made correct the first time. The phases are repeated until the product passes specification:
A simple iterative process
Until pass specification (evaluate product)
The iterative process is more appropriate for the design of products with many unknowns. Still, a disadvantage of many iterative design processes is that product features cannot be evaluated until coding is done. Coding a full blown product is an expensive proposition. So, a variation of the iterative process that is more appropriate for HCI is rapid prototyping.
Random House dictionary defines prototype as the original or model on which something is based or formed. Important notion in rapid prototyping is that there are several levels of prototyping, called fidelity. The fidelity of the prototyping can vary from text documents, drawings, mock up, and programs. These levels of prototyping allow rapid iteration of the process. There are several variations of iterative prototyping.
Throw-away iterative prototyping process
- Preliminary requirements gathering
- Until passes specifications increase prototype fidelity by
- Build prototype
- Evaluate prototype
The process above is called throw-away prototyping because lower fidelity prototypes are thrown-away after their evaluations and then higher fidelity prototypes are made.
The rapid prototyping design process has the advantage that the designers and clients can view and try early versions of the product. This is especially appropriate for a HCI product because a HCI product cannot really be evaluated until it is “tried.”
Iterative prototyping can also be configured in two other ways: incremental and evolutional.
In incremental iteration design process, the prototypes are components of the software. The software is designed as a set of components. Each component is developed and integrated with the other components. The product is released as a series of products with each product including an additional component.
Incremental iterative process
- Overall system design
- Identify components
- Until all components done and working together
- design, build, and test component
Designing, building and testing components is typically performed in a waterfall like process. The incremental iterative process has the advantage that the software is designed as separate components, so early release can test critical design issues.
In evolutionary iterations design processes, the prototypes are not thrown-away (nor are they components of the software), rather the software is refined.
Evolutionary prototyping process
- Preliminary requirements gathering
- Until software passes all specifications
- design and code refinement
- test refinement
All of the iterative processes design processes are appropriate for software development. Throw-away iterations are good for requirement gathering and early usability testing. Incremental iterations are good during the development of larger software. Evolutionary increments are good for developing software components and for maintaining the software after release. I expect that you will use all the forms of iterative and prototyping software development; throw-away iterations for testing your initial ideas, incremental iterations for identifying critical components and insuring that the critical components of your project are completed, and evolutionary iterations to develop the components and final debugging of your projects.
References from Usability.Gov:
- Karla’s go-to page for all things usability, https://www.usability.gov/
Modern HCI realizes that a user interface (UI) is to be used by users, so it is appropriate that the design process be centered on the user, called user-centered design. McCracken and Wolf list the attributes of user-centered design:
- User-centered design is user centric, not data centric. It involves users as much as possible in the process in creating the interface. Involvement varies from observing users, expert users designing and evaluating the prototypes
- User-centered design is interdisciplinary, draws on knowledge from art, psychology, technical writing, and computer science.
- User-centered design is highly interactive and involves many testing and revisions.
The general user-centered process follows these steps:
- Analyses: Needs, User, Tasks, Functional, Requirements
- Setting Usability Specifications
Needs analysis summarizes the goals of the interactive system. It gives a general description of the system and identifies the primary users. The document is typically only a paragraph.
User analysis characterizes the people who will use the product and identifies the other stakeholders. The document will identify stakeholders’ goals or how they will be affected by the product.
Task analysis identifies the tasks and sequence of tasks to achieve the users’ goals. This is a longer document and uses scenario descriptions to describe the tasks.
Functional analysis identifies the computer services, deciding what can be automated by computers and what requires user inputs. This analysis is close to a system design. In this document uses cases can be used to describe the functions and division between computer and user.
Requirement analysis is the formal specifications of the system. The document includes object modeling, UML. Requirement analysis may include identifying resources such as data bases and dictionaries. If the software uses a database then entity-relationship diagrams will be included in the document.
Setting usability specifications defines how the product will be evaluated, including performance and preference measures. Performance measures aspects of software use such as time to perform a task. Preference measures how satisfied the user is while using the software.
Design is the preparation for prototyping. It describes how the product how will look and work. It will include drawings and description of use.
Prototypes can be global or local. Global prototypes depict the entire system at various levels of fidelity. Local prototypes model specific parts of the system. Early prototypes should be low fidelity global prototypes to insure a cohesive general design. Higher fidelity local prototypes can be used to test specific usability. Also prototyping can be throw-away, incremental and evolutionary.
After a prototype is constructed the product can be evaluated by users.
Other User Centered Design Process
There are other forms of UI development. For example participatory design which constantly involves the potential users or clients.
- Scenario Based Design which focuses on scenarios, short descriptive alternative descriptions of use, to develop the design. During the course, we will frequently use scenario based design to inform and describe our designs.
- eXtreme programming which focuses on the actual process of implementation.
- Conceptual design which is centered on developing ideas for the UI.
- Data centered design which focuses on presenting the data and interacting with data.
- There is also task centered which concentrates on performing the task efficiently and reliably.
In this course you have several deliverables activities:
- Group and App Selection
- Interview scientist
- Describe Stakeholders
- Nominal Use Scenario
- Nominal Interaction Design
- Simplified Hierarchical Task Analysis
- Usability Goals List
- Paper Prototype
- Use scenarios
- Usability Concerns List
- Cognitive walkthrough
- Initial Design Review
- Final Design Presentation
- Usability Tests
- Implementation Review
- You will also get documents from the graduate students:
- Stakeholder Analysis
- User personas
- Simplified Hierarchical Task Analysis
- Heuristic Evaluations of paper prototype
- Usability Test Plans and Results
This process follows a user-centered iterative design process. The process has basically 5 phases
1. Stakeholder Analysis and Interaction Design
The applications selection represent your first choice of app ideas. You interview the scientist to learn of their needs. Your team makes a team/project website. The website is a mini design project unto itself, and creates a site for posting your design documents so that they are accessible to your scientist, grad students (UX experts) and instructors. You identify and describe all the stakeholders. Grad students give you a more thorough stakeholder analysis which describes their goals and influences on the project. Your team and grad students make user personas which you can use to focus your thinking about potential users of your app. The grad students also provide simplified Hierarchical Task Analysis. You also describe the interaction in nominal use scenario. The nominal interaction diagram delineates some of the roles of stakeholders and sequentially lists the tasks of the application. Your simplified hierarchical task analysis is tabulates potential views of your application.
2. Paper Prototype
You then make paper prototypes which illustrate the views of the app and serve to illustrate the interactions of your applications. For the paper prototype you will delineate usability goals and concerns. Your team will then refine the use scenario for the cognitive walkthrough. The cognitive walkthrough is an opportunity for the rest of the class to view your design and provide feedback. You will also get an opportunity to see other teams’ designs. The presentation is also an opportunity for a heuristic evaluation which are performed by the grad students. The heuristic evaluation contains both a list of usability principles for your app and an expert usability evaluation of your design.
3. Refined Design
After receiving feedback on your design from the client, the rest of the class, graduate student and me, you refine your design. The design review documents includes the modification to your design after you have reviewed all the evaluations of others.
You will then begin implementing your app. The final design documents will present the final iteration of your design. The final design presentation will also inform the graduate students, UX experts, how much you have implemented, so that they can begin designing usability testing. The final design presentation is also the last opportunity that you get evaluations from UX experts and classmates before the final usability test.
5. Usability Testing
The graduate students will design a usability test, and you will assist in administrating the test. This will give you a first look at the usability of your app. The implementation review allows me to learn the details of your implementation and results of the usability testing.