Obversive Wiki - View Source: DesignDocumentation

You are viewing an old revision of this page. View the current version.
The Obversive project uses a user centered design model combined with a project workbook based management method.  This means that the design of the program will be driven by documentation.  The following documentation is available:


!!! Requirements
Develop the initial user interface based on current user activities and types.  Group requirements into Use Cases and prioritize by importance, window of opportunity, and technical complexity.

; ProblemStatement  :   Description of the problem being solved in non-technical terms.
; UserProfiles :  A description of the specific user characteristics relevant to user interface design for the intended user population.
; ContextualTaskAnalysis :  A study of user's current tasks, work-flow, patterns, and conceptual framworks, resulting in a specification of underlying user goals.
; UsabilityGoalSetting :  Specific '''qualitative'''  and '''quantitative''' goals, reflecting usability requirements extracted from the UserProfile and ContextualAnalysis.
; PlatformCapabilitiesAndConstraints :  The user interface capabilities and constraints of the target platform.
; GeneralInterfaceDesignPrinciples :  Relevant general user interface design principles from Usability literature.
; UseCaseModel  :   An object-oriented formalization of functional requirements specifying usage of the application by external agents.
; NonFunctionalRequirements  :   Requirements that do not relate to user function, such as performance, integration, platform, etc.  Functional requirements are picked up during user analysis.
; PrioritizedRequirements  :  Defines the relative priorities of system requirements covering both functional and non-functional requirements.


!!! User Analysis
Detailed analysis of what the user wants in the application based on iterative usability studies of the proposed user interface.

; WorkReengineering :  User tasks are re-designed based on all Requirements Analysis and usability goals.  No user interface design is involved in this task, just abstract organization of functionality and work-flow design.
; ConceptualModelDesign :  Generate initial high-level design alternatives.  Navigational pathways, rules for consistent presentation, and possible actions are established.
; ConceptualModelMockups :  Generated prototype mock-ups of high-level design ideas, representing ideas about high-level functional organization.
; IterativeConceptualModelEvaluation :  The mock-ups are evaluated and modified through iterative techniques which verify the usability of the interfaces.  This WorkProduct should record the changes made, and the results should go in the target WorkProduct.
; ScreenDesignStandards :  A set of product-specific standards and conventions for all aspects of detailed screen design is developed, based on any industry and/or organizational standards.
; ScreenDesignStandardsPrototyping :  The ScreenDesignStandards and ConceptualModelMockups are applied to the design of the detailed user interface.
; IterativeScreenDesignStandardsEvaluation :  The ScreenDesignStandards are evaluated for usability.  The changes made are recorded in this recorded in this WorkProduct, and the results are put in the target WorkProduct.
; StyleGuideDevelopment :  A detailed recording of all specific UserInterface design guidelines, as discovered during UserAnalysis.
; DetailedUserInterfaceDesign :  Detailed design of the complete product user interface is carried out based on the refined and validated UserAnalysis to date.
; IterativeDetailedUserInterfaceDesignEvaluation :  The usability of the DetailedUserInterfaceDesign is evaluated and altered as needed.  The changes are recorded here, the results are placed in the target WorkProduct.


!!! Project Management
Allocate requirements to releases and/or increments and plan activities that manage resource availability and other project constraints.

; IntendedDevelopmentProcess :  Outlines the general approach to be adopted in terms of techniques, work products, standards, etc.
; ResourcePlan :  Analysis of resources required for the successful completion of the project.  Often focused on Human Resources.
; ProjectSchedule :  Time line showing dates, milestones, critical paths, etc.
; ReleasePlan :  For a multi-release project, this shows what functionality will be delivered in what release of the project.
; QualityAssurancePlan :  Documents quality assurance activities for topics such as Defect Removal.
; RiskManagementPlan :  Describes the plan for minimizing project failure risk.
; ReusePlan :  Describes what approaches will be followed to achieve the desired level of reuse.
; TestPlan :  Outlines the project's plans for testing the application.
; StatisticalProcessControlMetrics :  Lists the planned and actual measurements for the project.  Used to determine whether a project is on schedule.   See StatisticalProcessControl.
; ProjectDependencies :  Describes what dependencies or assumptions the project is relying on (for example, a deliverable from a vendor).
; ProjectIssues :  A list of all outstanding issues, questions, and concnerns that are reviewed on a regular basis.  This should just be a link to your Request Tracking queue, since that accomplishes the same thing.


!!! Analysis & Design
Develop solutions to scenarios in terms of active objects that group related tasks and communicate with other object in order to complete them.  Plan a solution to the problem explained from this analysis in terms of interacting objects, within constraints specified by the NonfunctionalRequirements.  Do this in an iterative fashion, revisiting UserAnalysis as new information is found.

; AnalysisDesignGuidelines :  Records the details on the analysis and design approaches being followed.
; SubjectAreas :  A distinct business domain of interest that can be identified at analysis time perhaps allowing it to be analyzed and developed as a separate unit.
; ObjectModel :  A consolidated model of objects' data (attributes), behavior, and relationships.  Gives a high-level overview of the domain being analyzed
; UsageScenarios :  UseCase plus assumptions plus outcome.
; ObjectInteractionDiagrams :  A working out of a scenario, showing interactions between objects to accomplish a task.
; StateModels : Show the life cycle of an objects -- its possible states and how it can change states.
; ClassDescriptions :  A detailed description of each class.  You should just point at your JavaDoc (or similar) documentation generated from the source.  Initially this can be like a DataDictionary, but should be replaced with the JavaDocs.
; SystemArchitecture :  Description of the high-level components/structures of the implementation and the design principles guiding the implementation.
; ApplicationProgrammingInterfaces :  Describes the programming interfaces to the project (from external sources).  Simply linking to the JavaDocs for the project will do.
; TargetEnvironment :  Describes hardware and software environment in which the software will run.
; SubsystemModel :  Partitioning of the system into smaller pieces (subsystems).
; RejectedDesignAlternatives :  Details of designs considered, but rejected.
; UserFeedback :  Records of what users thought of the interface at different stages.


!!! Implementation
Develop the classes specified as a result of analysis and design in a programming language according to documented public/private interfaces so that they can be built and installed on the target platforms.

; CodingGuidelines :  Guildelines for develoeprs.  Focus on naming conventions and packaging, not on source formatting.  Source formatting should be left to AutoFormatters.
; PhysicalPackagingPlan :  Documentation about deliverables that will be shipped with the product.
; DevelopmentEnvironment :  Describes the Development Environment developers will use.
; SourceCode :  Actual implementation source code for the project.  Simply point to the CVS browser or JavaDocs.
; UserSupportMaterials :  Documentation, delivered in various forms, which support the customer's use of the product.


!!! Testing
Insure that the application meets the requirements, usability goals, and stability requirements as described in the Requirements and User Analysis sections.

; BlackboxTests :  Tests done against the system as a regular user, but much more intense.
; BuildTests :  Tests which verify that the system will build and run on each platform planned as a target.
; InstallTests :  Tests that ensure that the system is installable by the intended user.
; UnitTests :  Tests written by developers intended to verify the internal operation of the system.  See UnitTesting.
; UserInterfaceTests :  Records of the UsabilityTests performed on the system.  This should be the raw records that result from the User Analysis section.