Lecture 7 HCI in the Software Process Software

  • Slides: 21
Download presentation
Lecture 7 HCI in the Software Process

Lecture 7 HCI in the Software Process

Software Life Cycle: → One of the corestone of Software engineering is software life

Software Life Cycle: → One of the corestone of Software engineering is software life cycle. → It describes the activities that take place between initial concept formation until evaluation phase. → One of the claim for software development is that it comes in engineering discipline due to structure of application. → In software development process two teams are considered: Customers Designers → Some of the individuals sometimes are both customers and designers. → It is often important to distinguish between the customer who is the client of the designing company and the customer who is the eventual user of the system. These two roles of customer can be played by different people. The group of people who negotiate the features of the intended system with the designer may never be actual users of the system.

Software Life Cycle:

Software Life Cycle:

Software Life Cycle: → Activities in life cycle Requirements Specification (What). Usually requirements are

Software Life Cycle: → Activities in life cycle Requirements Specification (What). Usually requirements are narrated in native language. Architectural Design (Why) → It performs high level decomposition. i. e. function decomposition of the system, determining which component will provide which dependencies. → it also determines inter-dependencies between separate components of the system. Requirements Functional Non Functional

Software Life Cycle: → Activities in life cycle Detailed Designed: → Refinement of components

Software Life Cycle: → Activities in life cycle Detailed Designed: → Refinement of components description provided by architectural design. → Details should be enough to be implemented in any programming language. → Choosing the best refinement is often a matter of trying to satisfy as many of the non-functional requirements of the system as possible. Thus the language used for the detailed design must allow some analysis of the design in order to assess its properties. Coding and Unit Testing: → Detailed design provides the form that is possible to implement through any programming language. → In this phase system is coded and then tested to verify that it performs correctly and according to criteria and constraints determined. Integration and Testing: → Once enough components have been implemented and individually tested, they must be integrated as described in the architectural design. → Further testing is done to ensure correct behavior and acceptable use of any shared resources.

Software Life Cycle: → Activities in life cycle Integration and Testing: → It is

Software Life Cycle: → Activities in life cycle Integration and Testing: → It is also possible at this time to perform some acceptance testing with the customers to ensure that the system meets their requirements. → It is only after acceptance of the integrated system that the product is finally released to the customer. Maintenance: → After product release, all work on the system is considered under the category of maintenance, until such time as a new version of the product demands a total redesign or the product is phased out entirely. → Maintenance involves the correction of errors in the system which are discovered after release and the revision of the system services to satisfy requirements that were not realized during previous development. Validation and Verification: → Throughout the life cycle, the design must be checked to ensure that it both satisfies the high-level requirements agreed with the customer and is also complete and internally consistent. These checks are referred to as validation and verification.

Software Life Cycle:

Software Life Cycle:

Software Life Cycle: → Activities in life cycle Validation and Verification: → Validation is

Software Life Cycle: → Activities in life cycle Validation and Verification: → Validation is concerned with designing the right thing. → Verifcation is concerned with designing the things right. → Various languages are used throughout design, ranging from informal natural language to very precise and formal mathematical languages. → Validation and verification exercises are difficult enough when carried out within one language; they become much more difficult, if not impossible, when attempted between languages. → Proofs: Validation proofs (Involve several languages that's why Trickier) Verification proofs (Involves one or two languages)

Software Life Cycle: → Management and Contractual Issues: → Management is concerned with a

Software Life Cycle: → Management and Contractual Issues: → Management is concerned with a much wider perspective that must be adopted which takes into account the marketability of a system, its training needs, the availability of skilled personnel or possible subcontractors, and other topics outside the activities for the development of the isolated system. → The technical perspective of the life cycle is described in stages of activity, whereas the managerial perspective is described in temporally bound phases. → A phase is usually defined in terms of the documentation taken as input to the phase and the documentation delivered as output from the phase. So the requirements phase will take any marketing or conceptual development information, identifying potential customers, as input and produce a requirements specification that must be agreed upon between customer and designer. → As the design activity proceeds, the customer and the designer must sign off on various documents, indicating their satisfaction with progress to date. These signed documents can carry a varying degree of contractual obligation between customer and designer.

Software Life Cycle: → Management and Contractual Issues: → So contractual obligation is a

Software Life Cycle: → Management and Contractual Issues: → So contractual obligation is a necessary consequence of managing software development, but it has negative implications on the design process as well. It is very difficult in the design of an interactive system to determine a priori what requirements to impose on the system to maximize its usability.

Software Life Cycle: → Interactive System and Software Life Cycle:

Software Life Cycle: → Interactive System and Software Life Cycle:

Software Life Cycle: → Interactive System and Software Life Cycle: → The more serious

Software Life Cycle: → Interactive System and Software Life Cycle: → The more serious claim we are making here is that all of the requirements for an interactive system cannot be determined from the start, and there are many convincing arguments to support this position. The result is that systems must be built and the interaction with users observed and evaluated in order to determine how to make them more usable. → Our models of the psychology and sociology of the human and human cognition, whether in isolation or in a group, are incomplete and do not allow us to predict how to design for maximum usability.

Usability Engineering: → In software engineering, usability is the degree to which a software

Usability Engineering: → In software engineering, usability is the degree to which a software can be used by specified consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use. → Usability engineering is a professional discipline that focuses on improving the usability of interactive systems. → It draws on theories from computer science and psychology to define problems that occur during the use of such a system. → Usability engineering involves the testing of designs at various stages of the development process, with users or with usability experts.

Usability Engineering:

Usability Engineering:

Usability Engineering: → Six usability attributes/goals: 1. Effectiveness: completeness with which users achieve their

Usability Engineering: → Six usability attributes/goals: 1. Effectiveness: completeness with which users achieve their goal. 2. Learnability: ease of learning for novice users. 3. Efficiency: steady-state performance of expert users. 4. Memorability: ease of using system intermittently for casual users. 5. Errors: error rate for minor and catastrophic errors. 6. Satisfaction: how satisfying a system is to use, from user’s point of view.

Usability Engineering: → Ease of use → Usability vs. Utility (Ability of product to

Usability Engineering: → Ease of use → Usability vs. Utility (Ability of product to perform tasks) → Liking it vs. using it → Discovery vs. Learning vs. Efficiency → Slogans don't work

Iterative Design and Prototyping: Throw Away Prototyping

Iterative Design and Prototyping: Throw Away Prototyping

Iterative Design and Prototyping: Incremental Prototyping

Iterative Design and Prototyping: Incremental Prototyping

Iterative Design and Prototyping: Evolutionary Prototyping

Iterative Design and Prototyping: Evolutionary Prototyping

Problems in Management Time: Building prototypes takes time and, if it is a throw-away

Problems in Management Time: Building prototypes takes time and, if it is a throw-away prototype, it can be seen as precious time taken away from the real design task. So the value of prototyping is only appreciated if it is fast, hence the use of the term rapid prototyping. However, rapid development and manipulation of a prototype should not be mistaken for rushed evaluation which might lead to erroneous results and invalidate the only advantage of using a prototype in the first place. Planning: Most project managers do not have the experience necessary for adequately planning and costing a design process which involves prototyping. Non-functional features Often the most important features of a system will be non-functional ones, such as safety and reliability, and these are precisely the kinds of features which are sacrificed in developing a prototype. For evaluating usability features of a prototype, response time – yet another feature often compromised in a prototype – could be critical to product acceptance. This problem is similar to the technical issue of prototype realism.

Problems in Management Contracts: The design process is often governed by contractual agreements between

Problems in Management Contracts: The design process is often governed by contractual agreements between customer and designer which are affected by many of these managerial and technical issues. Prototypes and other implementations cannot form the basis for a legal contract, and so an iterative design process will still require documentation which serves as the binding agreement. There must be an effective way of translating the results derived from prototyping into adequate documentation. A rapid prototyping process might be amenable to quick changes, but that does not also apply to the design process. aqsa 9 zahoor@gmail. com