UNIT III DESIGN CONCEPTS AND PRINCIPLES

Transcription

1 UNIT III DESIGN CONCEPTS AND PRINCIPLES Design process and concepts modular design design heuristic design model and document. Architectural design software architecture data design architectural design transform and transaction mapping user interface design user interface design principles. Real time systems - Real time software design system design real time executives data acquisition system -monitoring and control system. SCM Need for SCM Version control Introduction to SCM process Software configuration items. Design Engineering A software design is a meaningful engineering representation of some software product that is to be built. Designers must strive to acquire a repertoire of alternative design information and learn to choose the elements that best match the analysis model. A design can be traced to the customer's requirements and can be assessed for quality against predefined criteria. During the design process the software requirements model is transformed into design models that describe the details of the data structures, system architecture, interfaces, and components. Each design product is reviewed for quality (i.e., identify and correct errors, inconsistencies, or omissions) before moving to the next software engineering action. Design Engineering Encompasses the set of principles, concepts, and practices that lead to the development of a high quality system or product Design principles establish and overriding philosophy that guides the designer as the work is performed

2 Design concepts must be understood before the mechanics of design practice are applied Goal of design engineering is to produce a model or representation that is bug free (firmness), suitable for its intended uses (commodity), and pleasurable to use (delight) Design Specification Models Data/Class design - created by transforming the analysis model class-based elements (class diagrams, analysis packages, CRC models, collaboration diagrams) into classes and data structures required to implement the software Architectural design - defines the relationships among the major structural elements of the software, it is derived from the class-based elements and floworiented elements (data flow diagrams, control flow diagrams, processing narratives) of the analysis model Interface design - describes how the software elements, hardware elements, and end-users communicate with one another, it is derived from the analysis model scenario-based elements (use-case text, use-case diagrams, activity diagrams, swim lane diagrams), flow-oriented elements, and behavioral elements (state diagrams, sequence diagrams) Component-level design - created by transforming the structural elements defined by the software architecture into a procedural description of the software components using information obtained form the analysis model class-based elements, flow-oriented elements, and behavioral elements Software Quality Attributes A good design must implement all explicit requirements from the analysis model and accommodate all implicit requirements desired by the user

3 be readable and understandable guide for those who generate code, test components, or support the system provide a complete picture (data, function, behavior) if the software from an implementation perspective Design Quality Guidelines A design should exhibit good architectural structure be modular contain distinct representations of data, architecture, interfaces, and components (modules) lead to data structures that are appropriate for the objects to be implemented and be drawn from recognizable design patterns lead to components that exhibit independent functional characteristics lead to interfaces that reduce the complexity of connections between modules and with the external environment be derived using a reputable method that is driven by information obtained during software requirements analysis FURPS Quality Factors Functionality Usability Reliability Performance Supportability Generic Design Task Set 1. Select an architectural pattern appropriate to the software based on the analysis model

4 2. Partition the analysis model into design subsystems, design interfaces, and allocate analysis functions (classes) to each subsystem 3. Examine information domain model and design appropriate data structures for data objects and their attributes 4. Create a set of design classes o Translate analysis class into design class o Check each class against design criteria and consider inheritance issues o Define methods and messages for each design class o Select design patterns for each design class or subsystem after considering alternatives o Revise design classes and revise as needed 5. Design user interface o Review task analyses o Specify action sequences based on user scenarios o Define interface objects and control mechanisms o Review interface design and revise as needed 6. Conduct component level design o Specify algorithms at low level of detail o Refine interface of each component o Define component level data structures o Review components and correct all errors uncovered 7. Develop deployment model Design Concepts Abstraction - allows designers to focus on solving a problem without being concerned about irrelevant lower level details (procedural abstraction - named sequence of events, data abstraction - named collection of data objects) Software Architecture - overall structure of the software components and the ways in which that structure provides conceptual integrity for a system Design Patterns - description of a design structure that solves a particular design problem within a specific context and its impact when applied

5 Modularity - the degree to which software can be understood by examining its components independently of one another Information Hiding - information (data and procedure) contained within a module is inaccessible to modules that have no need for such information Functional Independence - achieved by developing modules with single-minded purpose and an aversion to excessive interaction with other models Refinement - process of elaboration where the designer provides successively more detail for each design component Refactoring - process of changing a software system in such a way internal structure is improved without altering the external behavior or code design Objects - encapsulate both data and data manipulation procedures needed to describe the content and behavior of a real world entity Class - generalized description (template or pattern) that describes a collection of similar objects Inheritance - provides a means for allowing subclasses to reuse existing superclass data and procedures; also provides mechanism for propagating changes Messages - the means by which objects exchange information with one another Polymorphism - a mechanism that allows several objects in an class hierarchy to have different methods with the same name (instances of each subclass will be free to respond to messages by calling their own version of the method) Design Classes - refine analysis classes by providing detail needed to implement the classes and implement a software infrastructure the support the business solution (i.e., user interface classes, business domain classes, process classes, persistent classes, system classes) Modular Design Method Evaluation Criteria Modular decomposability - provides systematic means for breaking problem into sub problems Modular composability - supports reuse of existing modules in new systems Modular understandability - module can be understood as a stand-alone unit Modular continuity - side-effects due to module changes minimized

6 Modular protection - side-effects due to processing errors minimized Effective Modular Design Functional independence - modules have high cohesion and low coupling Cohesion - qualitative indication of the degree to which a module focuses on just one thing Coupling - qualitative indication of the degree to which a module is connected to other modules and to the outside world Design Class Characteristics Complete and sufficient Primitiveness - each class method focuses on providing one service High cohesion Low coupling Design Model Process dimension - indicates design model evolution as design tasks are executed during software process o Architecture elements o Interface elements o Component-level elements o Deployment-level elements Abstraction dimension - represents level of detail as each analysis model element is transformed into a design equivalent and refined o High level (analysis model elements) o Low level (design model elements) Many UML diagrams used in the design model are refinements of diagrams created in the analysis model Data Design

7 High level model depicting user's view of the data or information Design of data structures and operators is essential to creation of high-quality applications Translation of data model into database is critical to achieving system business objectives Reorganizing databases into data warehouse enables data mining or knowledge discovery that can impact success of business itself Architectural Design Derived from o Information about the application domain relevant to software o Relationships and collaborations among specific analysis model elements o Availability of architectural patterns and styles Usually depicted as a set of interconnected systems that are often derived from the analysis packages Interface Design Interface is a set of operations that describes the externally observable behavior of a class and provides access to its operations Important elements o User interface (UI) o External interfaces to other systems o Internal interfaces between various design components Modeled using UML collaboration diagrams Component-Level Design Describes the internal detail of each software component Defines o Data structures for all local data objects o Algorithmic detail for all component processing functions

8 o Interface that allows access to all component operations Modeled using UML component diagrams, UML activity diagrams, and pseudocode (PDL) Deployment-Level Design Indicates how software functionality and subsystems will be allocated within the physical computing environment Modeled using UML deployment diagrams Design Pattern Template Name Intent Aliases Motivation Applicability Structure Participants Collaborators Consequences Related patterns Using Patterns in Design Architectural patterns - define overall structure and relationships of software components (classes, packages, subsystems) Design patterns - address specific design elements (component aggregations, component relationships, or communication) Idioms (coding patterns) - language specific implementations for algorithms or communications mechanisms Frameworks

9 Collection of "plug points" hooks or slots that enable it to be adapted to a specific problem domain Plug points enable designers to integrate problem specific functionality within the skeleton In an object-oriented context a skeleton is a collection of cooperating classes Architectural Design Architectural design represents the structure of the data and program components required to build a computer-based system. A number of architectural "styles" exist. Architectural design begins with data design and proceeds to the derivation of one or more representations of the architectural structure of the system. The resulting architectural model encompasses both the data architecture and the program structure. Alternative architectural patterns are analyzed to determine the structure that is best suited to the customer's requirements. The architectural model is subjected to software quality review like all other design work products. - Software architecture is a representation that enables a software engineer to Analyze the effectiveness of the design in meeting stated requirements Consider architectural alternatives Reduce the risk associated with the construction of the software Importance of Architecture Architecture highlights early design decisions that will have a profound impact on the ultimate success of the system as an operational entity The architecture itself constitutes an intellectually manageable model of how the system is structured and how its components work together Data Warehouse Challenges for Data Architects

10 Subject orientation - data warehouse organized by business subjects rather than business processes or functions Integration - data in the warehouse must exhibit consistent naming conventions, encoding structures, and physical attributes even when inconsistencies exist among application-oriented databases Time variancy - unlike transaction-oriented databases where data may only be accurate for short time periods, the time horizon for a data warehouse may be several years Nonvolatility - data remains in the data warehouse once added and old data may only be purged every few years if at all Data Specification Principles Systematic analysis principles applied to function and behavior should also be applied to data. All data structures and the operations to be performed on each should be identified. Data dictionary should be established and used to define both data and program design. Low level design processes should be deferred until late in the design process. Representations of data structure should be known only to those modules that must make direct use of the data contained within in the data structure. A library of useful data structures and operations should be developed. A software design and its implementation language should support the specification and realization of abstract data types. Architectural Style Elements Set of components Set of connections that enable communication, coordination, and cooperation among components Constraints defining how components can be integrated to form the system

11 Semantic models that enable designers to understand the overall system properties by analyzing properties of its constituent parts Comparing Architectural Styles and Patterns Both impose transformations on the design of an entire system Scope of architectural pattern is less broad Patterns impose rules on the architecture describing how the software will deliver some aspect of its functionality at the infrastructure level Canonical Architectural Structures Functional structure - components represent function or processing entities, connectors are interfaces that allow data access Implementation structure - components are vehicles for packaging functionality (i.e., packages, classes, objects, functions, methods, etc.), connectors include data sharing, control transfer, associations, etc. Concurrency structure - components are units of concurrency, connectors are execution or communications constraints Physical structure - components are physical hardware that software is deployed on, connectors are the hardware interfaces Developmental structure - components are work products and required information sources, connectors are the relationships among the work products Architectural Styles Data centered - data store (e.g., file or database) lies at the center of this architecture and is accessed frequently by other components that modify data Data flow - input data is transformed by a series of computational or manipulative components into output data Call and return - program structure decomposes function into control hierarchy with main program invokes several subprograms

12 Object-oriented - components of system encapsulate data and operations, communication between components is by message passing Layered - several layers are defined, each accomplishing operations that progressively become closer to the machine instruction set Architectural Design Software to be developed must be put into context (i.e., model external entities and define interfaces) Identify architectural archetypes (collection of abstractions that must be modeled if the system is to be constructed) Specify structure of the system by defining and refining the software components needed to implement each archetype Continue the process iteratively until a complete architectural structure has been derived Representing the System in Context Use the architectural context diagram to model the manner in which the system interacts with external entities Systems that interoperate with the target system are represented as o Super ordinate systems - using the target system as part of some higher level processing scheme o Subordinate systems - used by the target system to provide data or processing needed to complete the target system o Peer level systems - producing or consuming information needed by peers of the target system o Actors - people or devices that interact with the system to produce or consume information needed for requisite processing Interfaces must be defined All the data that flow into or out of the target system must be identified Defining Archetypes

13 May be defined by examining the analysis classes defined in the analysis model Determine the stable elements of the architecture that will need to be implemented when the system is built Refining Architecture into Components Process begins with an examination of the analysis classes for entities from the business domain that must be addressed in the software architecture Infrastructure components needed to support the business functions The interfaces depicted in the architecture context diagram may imply specialized components needed to process data that crosses the interfaces Look for archetypes that are reoccur in several components and create new components that service each repeating design pattern Architecture Design Assessment Questions How is control managed within the architecture? Does a distinct control hierarchy exist? How do components transfer control within the system? How is control shared among components? What is the control topology? Is control synchronized or asynchronous? How are data communicated between components? Is the flow of data continuous or sporadic? What is the mode of data transfer? Do data components exist? If so what is their role? How do functional components interact with data components? Are data components active or passive? How do data and control interact within the system? Architecture Trade-off Analysis Method 1. Collect scenarios

14 2. Elicit requirements, constraints, and environmental description 3. Describe architectural styles/patterns chosen to address scenarios and requirements (module view, process view, data flow view) 4. Evaluate quality attributes independently (e.g., reliability, performance, security, maintainability, flexibility, testability, portability, reusability, interoperability) 5. Identify sensitivity points for architecture (any attributes significantly affected by variation in the architecture) 6. Critique candidate architectures (from step 3) using the sensitivity analysis (conducted in step 5) Quantitative Design Analysis Techniques Spectrum analysis - assesses an architecture using a goodness spectrum from best to worst design Design selection analysis - architecture is assessed to determine how it compares to an ideal or best case system Contribution analysis - identifies reasons why one set of design choices gets a lower score than another Architectural Complexity (similar to coupling) Sharing dependencies - represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers Flow dependencies - represent dependence relationships between producers and consumers of resources Constrained dependencies - represent constraints on the relative flow among a set of components Architectural Description Language (ADL) Provides syntax and semantics for describing software architecture Provides designers with ability to decompose components, combine components, and define interfaces

15 Mapping Requirements to Software Architecture in Structured Design (Used for developing a "call and return" architecture) 1. Establish type of information flow (transform flow - overall data flow is sequential and flows along a small number of straight line paths; transaction flow - a single data item triggers information flow along one of many paths) 2. Flow boundaries indicated 3. DFD is mapped into program structure 4. Control hierarchy defined 5. Resultant structure refined using design measures and heuristics 6. Architectural description refined and elaborated Transform Mapping 1. Review fundamental system model 2. Review and refine data flow diagrams for the software 3. Determine whether the DFD has transform or transaction characteristics 4. Isolate the transform center by specifying incoming and outgoing flow boundaries 5. Perform first level factoring 6. Perform second level factoring 7. Refine the first iteration architecture using design heuristics for improved software quality Transaction Mapping 1. Review fundamental system model 2. Review and refine data flow diagrams for the software 3. Determine whether the DFD has transform or transaction characteristics 4. Identify the transaction center and flow characteristics along each action path 5. Map the DFD to a program structure amenable to transaction processing 6. Factor and refine the transaction structure and the structure of each action path 7. Refine the first iteration architecture using design heuristics for improved software quality

16 Refining Architectural Design Processing narrative developed for each module Interface description provided for each module Local and global data structures are defined Design restrictions/limitations noted Design reviews conducted Refinement considered if required and justified Modeling component level design The purpose of component level design is to define data structures, algorithms, interface characteristics, and communication mechanisms for each software component identified in the architectural design. Component level design occurs after the data, architectural, and interface designs are established. The component-level design represents the software in a way that allows the designer to review it for correctness and consistency, before it is built. The work product produced is a design for each software component, represented using graphical, tabular, or text-based notation. Design walkthroughs are conducted to determine correctness of the data transformation or control transformation allocated to each component during earlier design steps. Component Definitions A component is a modular, deployable, replaceable part of a system that encapsulates implementation and exposes a set of interfaces Object-oriented view is that a component contains a set of collaborating classes Traditional view is that a component (or module) resides in the software and serves one of three roles o Control components coordinate invocation of all other problem domain components o Problem domain components implement a function required by the customer

17 o Infrastructure components are responsible for functions needed to support the processing required in a domain application Process-Related view emphasizes building systems out of existing components chosen from a catalog of reusable components as a means of populating the architecture Object-Oriented Component Design Focuses on the elaboration of domain specific analysis classes and the definition of infrastructure classes Detailed description of class attributes, operations, and interfaces is required prior to beginning construction activities Principles for Designing Class-based Components Open-Closed Principle (OCP) - class should be open for extension but closed for modification Liskov Substitution Principle (LSP) - subclasses should be substitutable for their base classes Dependency Inversion Principle (DIP) - depend on abstractions, do not depend on concretions Interface Segregation Principle (ISP) - many client specific interfaces are better than one general purpose interface Release Reuse Equivalency Principle (REP) - the granule of reuse is the granule of release Common Closure Principle (CCP) - classes that change together belong together Common Reuse Principle (CRP) - classes that can't be used together should not be grouped together Component-Level Design Guidelines Components o Establish naming conventions during architectural modeling

18 o Architectural component names should have meaning to stakeholders o Infrastructure component names should reflect implementation specific meanings o Use of UML stereotypes may help identify the nature of components Interfaces o Use lollipop representation rather than formal UML box and arrow notation o For consistency interfaces should flow from the left-hand side of the component box o Show only the interfaces relevant to the component under construction Dependencies o For improved readability model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes) o Component interdependencies should be represented by interfaces rather that component to component dependencies Cohesion Utility cohesion - components grouped within the same category but are otherwise unrelated Temporal cohesion - operations are performed to reflect a specific behavior or state Procedural cohesion - components grouped to allow one be invoked immediately after the preceding one was invoked with or without passing data Communicational cohesion - operations required same data are grouped in same class Sequential cohesion - components grouped to allow input to be passed from first to second and so on Layer cohesion - exhibited by package components when a higher level layer accesses the services of a lower layer, but lower level layers do not access higher level layer services Functional cohesion - module performs one and only one function

19 Coupling Data coupling - occurs when long strings of arguments are passed between components Stamp coupling - occurs when parts of larger data structures are passed between components Control coupling - occurs when one component passes control flags as arguments to another External coupling - occurs when a component communicates or collaborates with in infrastructure component (e.g., database) Common coupling - occurs when several components make use of a global variable Content coupling - occurs when one component surreptitiously modifies internal data in another component Routine call coupling - occurs when one operator invokes another Type use coupling - occurs when one component uses a data type defined in another Inclusion or import coupling - occurs when one component imports a package or uses the content of another Conducting Component Level Design 1. Identify all design classes that correspond to the problem domain. 2. Identify all design classes that correspond to the infrastructure domain. 3. Elaborate all design classes that are not acquired as reusable components. a. Specify message details when classes or components collaborate. b. Identify appropriate interfaces for each component. c. Elaborate attributes and define data types and data structures required to implement them. d. Describe processing flow within each operation in detail. 4. Identify persistent data sources (databases and files) and identify the classes required to manage them.

20 5. Develop and elaborate behavioral representations for each class or component. 6. Elaborate deployment diagrams to provide additional implementation detail. 7. Factor every component-level diagram representation and consider alternatives. Object Constraint Language (OCL) Complements UML by allowing a software engineer to use formal grammar and syntax to construct unambiguous statements about design model element Parts of OCL language statements 1. a context that denotes the limited situation in which the statement is valid 2. a property representing some characteristics of the context 3. an operation that manipulates or qualifies a property 4. keywords used to specify conditional expressions Conventional or Structured Component Design Each block of code has a single entry at the top Each block of code has a single exit at the bottom Only three control structures are required: sequence, condition (if-then-else), and repetition (looping) Reduces program complexity by enhancing readability, testability, and maintainability Design Notation Flowcharts - arrows for flow of control, diamonds for decisions, rectangles for processes Decision table - subsets of system conditions and actions are associated with each other to define the rules for processing inputs and events Program Design Language (PDL) - structured English or pseudocode used to describe processing details Program Design Language Characteristics

21 Fixed syntax with keywords providing for representation of all structured constructs, data declarations, and module definitions Free syntax of natural language for describing processing features Data declaration facilities for simple and complex data structures Subprogram definition and invocation facilities Design Notation Assessment Criteria Modularity - notation supports development of modular software Overall simplicity - easy to learn, easy to use, easy to write Ease of editing - easy to modify design representation when changes are necessary Machine readability - notation can be input directly into a computer-based development system Maintainability - maintenance of the configuration usually involves maintenance of the procedural design representation Structure enforcement - enforces the use of structured programming constructs Automatic processing - allows the designer to verify the correctness and quality of the design Data representation - ability to represent local and global data directly Logic verification - automatic logic verification improves testing adequacy Easily converted to program source code (makes code generation quicker) User interface design This introduces the principles of user interface design as it relates to the development of software products. Proper interface design begins with careful analysis of the user, the task and the environment. Once the user's tasks are identified, user scenarios are created and validated. Good user interfaces are designed, they don't happen by chance. Prototyping is a common approach to user interface analysis and design. Early involvement of the user in the design process makes her or him more likely to accept the final product. User interfaces must be field tested and validated prior to general release.

22 Place User in Control Define interaction in such a way that the user is not forced into performing unnecessary or undesired actions Provide for flexible interaction (users have varying preferences) Allow user interaction to be interruptible and reversible Streamline interaction as skill level increases and allow customization of interaction Hide technical internals from the casual user Design for direct interaction with objects that appear on the screen Reduce User Memory Load Reduce demands on user's short-term memory Establish meaningful defaults Define intuitive short-cuts Visual layout of user interface should be based on a familiar real world metaphor Disclose information in a progressive fashion Make Interface Consistent Allow user to put the current task into a meaningful context Maintain consistency across a family of applications If past interaction models have created user expectations, do not make changes unless there is a good reason to do so Usability Assessment by Observing Users Is system usable without continual help of instruction? Do rules of interaction help a knowledgeable user work efficiently?

23 Do interaction rules become more flexible as users become more knowledgeable? Has system been tuned to the physical and social user environment? Is the user aware of the state of the system? Does the user know where he or she is at all times? Is the interface structured in a logical and consistent manner? Are interaction mechanisms, icons, and procedures consistent across the interface? Does the interaction anticipate errors and help users correct them? Is the interface tolerant of errors made? Is the interaction simple? User Interface Design Models Design model (incorporates data, architectural, interface, and procedural representations of the software) User model (end user profiles - novice, knowledgeable intermittent user, knowledgeable frequent users) User's model or system perception (user's mental image of system) Implementation model (look and feel of the interface and supporting media) User Categories Novices - have no syntactic knowledge of the system and little knowledge of the application or general computer usage Knowledgeable intermittent users - have reasonable semantic knowledge of the application, but low recall of syntactic information necessary to use the interface Knowledgeable frequent users - good semantic and syntactic knowledge of the application, look for interaction shortcuts User Interface Design Process (Spiral Model) User, task, and environment analysis and modeling Interface design

24 Interface construction Interface validation Analysis of Physical Work Environment Where will the interface be located physically? Will the user be sitting, standing, or performing other tasks unrelated to the interface? Does the interface hardware accommodate space, light, or noise constraints? Are there special human factors considerations driven by environmental factors? Validation Considerations Does the interface implement every user task correctly, accommodate all task variations, and achieve all general user requirements? To what degree is the user interface easy to use and easy to learn? Do users' accept that the user interface as a useful tool in their daily work? Interface Analysis Goals Understand people who interact with system through the interface Understand tasks end-users must perform to do their work Understand the content presented as part of the interface Understand the nature of the environment in which tasks will be performed User Analysis Sources User interviews - designers meet with end-users individually or in groups Sales input - sales people help designers categorize users and better understand their needs Marketing input - marketing analysis can help define market segments and help understand how each segment might use the software

25 Support input - support staff can provide good input what works and does not, what users like, what features generate questions, and what features are easy to use Task Analysis and Modeling Use-cases o What work will the user perform in specific circumstances? Task elaboration o What tasks and subtasks will be performed as the user does the work? Object elaboration o What specific problem domain objects will the user manipulate as work is performed? Workflow analysis o What is the sequence of work tasks? Hierarchical representation o What is the hierarchy of tasks? Interface Layout and Content Review Questions Are different types of data assigned to consistent geographical locations on the screen? Can user customize screen locations of content? Is proper on-screen identification assigned to all content? How should large report be partitioned for ease of understanding? Will mechanisms be available for moving directly to data summary information for large data collections? Will graphical output be scaled to fit bounds of display device used? How will color be used to enhance understanding? How will error messages and warnings be displayed to the user? Interface Design

26 Use the information developed during interface analysis to define interface objects and actions (operations) Define events (user actions) that will cause the state of the user interface to change and model this behavior Depict each interface state as it will appear to the end-user Indicate how the user interprets the state of the system from information provided through the interface User Interface Design Pattern Examples Top-level navigation Card stack Fill-in-the-blanks Sortable table Bread crumbs Edit-in-place Simple search Shopping cart Progress indicator Interface Design Issues System response time - time between the point at which user initiates some control action and the time when the system responds User help facilities - integrated, context sensitive help versus add-on help Error handling - messages should be non-judgmental, describe problem precisely, and suggest valid solutions Menu and command labeling - based on user vocabulary, simple grammar, and have consistent rules for abbreviation Application accessibility - ensuring that interface design contains mechanisms for accommodating user with special needs (vision, hearing, mobility, speech, learning impairments)

27 Internationalization - interface accommodates needs of different locales and languages User-Interface Development System Capabilities Managing input devices Validating user input Error handling and displaying error messages Providing feedback Proving help and prompts Handling windows and fields Establishing connections between application software and interface Insulating application from interface management functions Allowing user to customize the interface User Interface Evaluation Cycle 1. Preliminary design 2. Build first interface prototype 3. User evaluates interface 4. Evaluation studied by designer 5. Design modifications made 6. Build next prototype 7. If interface is not complete then go to step 3 User Interface Design Evaluation Criteria Length and complexity of written interface specification provide an indication of amount of learning required by system users Number of user tasks and the average number of actions per task provide an indication of interaction time and overall system efficiency Number of tasks, actions, and system states in the design model provide an indication of the memory load required of system users

28 Interface style, help facilities, and error handling protocols provide a general indication of system complexity and the degree of acceptance by the users The SCM process: SCM is an important element of software quality assurance. Its primary responsibility is the control of change. However, SCM is also responsible for the identification of individual SCIs and various versions of the software, the auditing of the software configuration of ensure that it has been properly developed, and the reporting of all changes applied to the configuration. Various SCM tasks: Configuration management planning. Configuration item identification. Change control. Version control. Release control. Configuration auditing. Configuration status reporting. Configuration management planning: Configuration management takes over control of systems after they have been developed. However, planning this management process must start during system development. A Configuration management plan should be developed as part of the overall project planning process. The CM plan should include the following information: The definition of what entities are to be managed and a formal scheme for identifying these entities. A statement of who takes responsibility for the configuration management procedures

29 and form submitting controlled entities to the configuration management team. The configuration management policies, which are used for, change control and version management. A description of the records of the configuration management process which should be maintained. A description of the tools to be used for configuration management and the process to be applied when using these tools. A definition of the configuration database which will be used to record configuration information. An important part of the CM plan is the definition of responsibilities. It should define who is responsible for the delivery of each document or software component to quality assurance and configuration management. It may also define the reviewers of each document. The person responsible for document delivery need not be the same person as the person responsible for producing the document. To simply interfaces, it is often convenient to make project managers or team leaders responsible for all of the documents produced by their team. Configuration item identification: Project plans, specifications, designs, programs and test data suites are normally termed as configuration items. However, all documents which may be necessary for future system maintenance should be controlled. To control and manage software configuration items, each must be separately named and then organized using an object-oriented approach. Two types of objects: Basic objects. Aggregate objects. A basic object is a unit of text a software engineer during analysis, design, code, or test has created that. An aggregate object is a collection of basic objects and other aggregate

30 objects. Each object has a set of distinct features that identify it uniquely: A name. A description. A list of resources. A realization. The object name is a character string that identifies the object unambiguously. The object description is a list of data items that identify the SCI type, a project identifier and change or version information. Resources are entities that are provided, processed, referenced or otherwise required by the object. The realization is a pointer to the unit of text for a basic object and null for an aggregate object. Configuration object identification must also consider the relationships that exist between named objects. In many cases, objects are interrelated across branches of the object hierarchy. The interrelationships between configuration objects can be represented with a module interconnection language (MIL). A MIL describes the interdependencies among configuration objects and enables any version of a system to be constructed automatically. The identification scheme for software objects must recognize that objects evolve throughout the software process. Before an object is baseline, it may be quite frequent. It is possible to create an evolution graph for any object. The evolution graph describes the change history of an object. Changes may be made to any version, but not necessarily to all versions. A variety of automated SCM tools has been developed to aid in identification tasks. In some cases, a tool is designed to maintain full copies of only the most recent version. To achieve earlier versions changes are subtracted from the most recent version. This

31 scheme makes the current configuration immediately available and allows other versions to be derived easily. Changes control: Changes is a fact of life for large software systems. Organizational need and requirements change during the lifetime of a system. This requires corresponding changes to be made to the software. There is therefore a need for a system to ensure that these changes are recorded and applied to the system in a cost-effective way. The change management process should come into effect when the software or associated documentation is put under the control of the configuration management team. Change management procedures should be designed to ensure that the costs and benefits of change are properly analyzed and that changes to a system are made in a controlled way. Change management processes involve technical change analysis, cost benefit analysis and change tracking. The first stage in change management process is to complete a change request from (CRF). This is a formal document where the requester sets out the change required to the system. The information provided in the change request form is recorded in the CM database. Once a change request form has been submitted, it is analyzed to check that the change is valid. Some change requests may be due to user misunderstandings rather than system faults; others may refer to already known faults. If the analysis process discovers that a change request is invalid duplicated or has already been considered the change should be rejected. The reason for the rejection should be returned to the person who submitted the change request. For valid changes, the next stage of the process is change assessment and costing. The

32 impact of the change on the rest of the system must be checked. A technical analysis must be made of how to implement the change. The cost of making the change and changing other system components to accommodate the change is then estimated. This should be recorded on the change request form. It should be then submitted to change control authority (CCA) who decides whether or not the change should be accepted. The CCA considers the impact of the change from a strategic and organizational rather than a technical point of view. It divides if the change is economically justified and if there are good organizational reasons to accept the changes. When a set of changes has been approved, an engineering change order (ECO) is generated for each approved change. The software is handed over to the development or maintenance team for implementation. Once these changes have been complete, the revised software must be revalidated to check that these changes have been correctly implemented. The CM team, rather than the system developers are responsible fro building a new version or release of the software. Change requests are themselves configuration items. They should be registered in the configuration database. It should be possible to use this database to discover the status of change requests and the change requests, which are associated with specific software components. As software components are changed, a record of the changes made to each component should be maintained. The change management process is very procedural. Each person involved in the process is responsible for some activity. They complete this activity then pass on the forms and associated configuration items to someone else. The procedural nature of this process means that a change process model can be designed and integrated with a version

33 management system. This model may then be interpreted so that the right documents are passed to that right people at the right time. Version control: A system version is an instance of a system that differs, in some way, from other instances. New versions of the system may have different functionality, performance or may repair system faults. Some version may be functionality equivalent but designed for different hardware or software configurations. Version identification: Version control combines procedures and tools to manage different versions of configuration objects that are created during the software process. Identifying versions of a system appears to be straightforward. The first version and release of a system is simply called 1.0, subsequent versions are 1.1, 1.2 and so on. At some stage, it decided to create release 2.0 and the process starts again at version 2.1, 2.2 and so on. System releases normally correspond to the base version that is 1.0, 2.0, 3.0 and so on. The scheme is a linear one based on the assumption that system versions are created in sequence. Methods for representing different versions of a system: 1. By means of evolution graph. Each node on the graph is an aggregate object, that is, a complete version of the software. Each version of the software is a collection of SCIs, and each version may be composed of different variants. 2. As an object pool. The relationship between configuration objects and entities, variants and version scan be represented in a three dimensional space. An entity is composed of a collection of objects at the same revision level. A variant is a different collection of objects at the

34 same version level and therefore coexists in parallel with other variants. A new version is defined when major changes are made to one or more objects. 3. Symbolic naming scheme. Rather than refer to version 1.1.2, a particular instance of a system might be referred to as V1/VMS/Dbserver. This implies that this is a version of a database server for a digital computer running the VMS operating system. The fundamental problem with both numeric and symbolic naming schemes is that they do not reflect the many different attributes, which may be used to identify versions. If each version is identified by a unique set of attributes, it is easy to add new versions that are derived from any of the existing versions. These are identified using a set of attribute values. Version management tools. Version management involves managing large amounts of information and ensuring that system changes are recorded and controlled. Version management systems control a repository of configuration items where the contents of that repository are immutable. To work on a configuration item, it must be checked out of the repository into some working directory. After the work is complete, it is then checked into the repository. A new version is automatically created. Capabilities in a version management system: 1.Version and release identification. Managed versions may be assigned identifiers automatically when they are submitted to the system. Some systems support attribute value assignment for identification. 2. Controlled change. Versions of component must be checked out explicitly for change. 3. Storage management. To reduce the storage space required by different versions that are largely the same, version management systems provide storage management facilities so that version is described by their differences from some master version. 4. Change history recording. All of the changes made to a particular system or component may be recorded and listed.

35 For Unix platforms, the most widely used version management systems are SCCS and RCS. RCS saves the source code of the most recent version of a system as the master version. This is created from an earlier master version. When a new master is created, the previous version is deleted and replaced by a specification of the differences between it new master version. This difference specification is called a delta. Rather than having to store all source code of all masters, RCS need only save a single master version and a set of deltas. Deltas are invariably much smaller than the source code of a system version. This method of storage management therefore reduces the disc space required for version management. The main difference between RCS and SCCS are the method of storage management used and the version annotation capabilities. SCCS stores the first version of a system with further versions specified as deltas from it. It does not allow as much user-supplied information to be associated with a system version. RCS is generally most often are usually those, which were, created most recently. Release control A system release is a version that is distributed to customers. Each system release should either include new functionality or should be intended for a different hardware platform. Normally, there are a more version s of a system than releases. Some versions may never be released to customers. A release is not just an executable program or set of programs. It includes:configuration files defining how release should be configured for particular installations. Data files which are needed for successful system operation. An installation program which is used to help install the system on target hardware. Electronic and paper documentation describing the system.