Marketing Documentation

MARKETING DOCUMENTATION

For many applications it is necessary to have some promotional materials to encourage casual observers to spend more time learning about the product. This form of documentation has three purposes :

  1. To excite the potential user about the product and instill in them a desire for becoming more involved with it.
  2. To inform them about what exactly the product does, so that their expectations are in line with what they will be receiving.
  3. To explain the position of this product with respect to other alternativeg.

One good marketing technique is to provide clear and memorable catch phrases that exemplify the point we wish to convey, and also emphasize the interoperability of the program with anything else provided by the manufacturer.

Technical Documentation

TECHNICAL DOCUMENTATION

This is what most programmers mean when using the term software documentation. When creating software, code alone is insufficient. There must be some text along with it to describe various aspects of its intended operation. It is important for the code documents to be thorough, but not so verbose that it becomes difficult to maintain them.

Often, tools such as Doxygen, NDoc, javadoc, SandCastle, ROBODoc, POD , TwinText , or Universal Report can be used to auto-generate the code documents-that is, they extract the comments from the source code and create reference manuals in such forms as text or HTML files. Code documents are often organized into a reference guide style, allowing a programmer to quickly look up an arbitrary function or class.

Many programmers really like the idea of auto-generating documentation for various reasons. For example, because it is extracted from the source code itself, the programmer can write it while referring to his code, and can use the same tools he used to create the source code, to make the documentation. This makes it much easier to keep the documentation up-to-date.

User Documentation

Unlike code documents, user documents are usually far more diverse with respect to the source code of the program, and instead simply describe how it is used.

In the case of a software library, the code documents and user documents could be effectively equivalent and are worth conjoining, but for a general application this is not often true. Typically, the user documentation describes each feature of the program, and assists the user in realizing these features. A good user document can also go so far as to provide thorough troubleshooting assistance. It is very important for user documents to not be confusing, and for them to be up to date. User documents need not be organized in any particular way, but it is very important for them to have a thorough index. Consistency and simplicity are also very valuable. User documentation is considered to constitute a contract specifying what the software will do.

There are three broad ways in which user documentation can be organized.

(a) Tutorial

A tutorial approach is considered the most useful for a new user, in which they are guided through each step of accomplishing particular tasks.

(b) Thematic

A thematic approach, where chapters or sections concentrate on one particular area of interest, is of more general use to an intermediate user.

(c) List or Reference

The final type of organizing principle is one in which commands or tasks are simply listed alphabetically or logically grouped, often via cross-referenced indexes. This latter approach is of greater use to advanced users who know exactly what sort of information they are looking for.

Architecture/Design Documentation

ARCHITECTURE/DESIGN DOCUMENTATION.

Architecture documentation is a special breed of design documents. These documents do not describe how to program a particular routine, or even why that particular routine exists in the form that it does, but instead merely lays out the general requirements that would motivate the existence of such a routine. A good architecture document is short on details but thick on explanation. It may suggest approaches for lower level design, but leave the actual exploration trade studies to other documents.

Another breed of design does is the comparison document, or trade study. This would often take the form of a whitepaper. It focuses on one specific aspect of the system and suggests alternate approaches. It could be at the user interface, code, design, or even architectural level. It will outline what the situation is, describe one or more alternatives, and enumerate the pros and cons of each. A good trade study document is heavy on research, expresses its idea clearly, and most importantly is impartial. It should honestly and clearly explain the costs of whatever solution it offers as best.

Documentation

DOCUMENTATION

Software documentation is written text that accompanies computer software. It either explains how it operates or how to use it, and may mean different things to people in different roles.

Types

Documentation is an important part of software engineering. Types of documentation include :

  • Architecture/Design – Overview of software. Includes relations to an environment and construction principles to be used in design of software
  • Technical – Documentation of code, algorithms, interfaces, and APIs.
  • End User Manuals for the end-user, system administrators and support staff.
  • Marketing – Product briefs and promotional collateral.

Disadvantages of Prototyping

DISADVANTAGES OF PROTOTYPING

Using, or perhaps misusing, prototyping can also have disadvantages:

  1. Insufficient analysis : The focus on a limited prototype can distract developers from properly analyzing the complete project. This can lead to overlooking better solutions, preparation of incomplete specifications or the conversion of limited prototypes into poorly engineered final projects that are hard to maintain. Further, since a prototype is limited in functionality it may not scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if developers are too focused on building a prototype as a. •
  2. User confusion of prototype and finished system : Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished. (They are, for example, often unaware of the effort needed to add error-checking and security features which a prototype may not have.) This can lead them to expect the prototype to accurately model the performance of the final system when this is not the intent of the developers. Users can also become attached to features that were included in a prototype for consideration and then removed from the specification for a final system. If users are able to require all proposed features be included in the final system this can lead to feature creep.
  3. Developer attachment to prototype : Developers can also become. attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture.
  4. Excessive development time of the prototype : A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a prototype that is too complex. When the prototype is thrown away the precisely developed requirements that it provides may not yield a sufficient increase in productivity to make up for the time spent developing the prototype. Users can become stuck in debates over details of the prototype, holding up the development team and delaying the final product.
  5. Expense of implementing prototyping : The start up costs for building a development team focussed on prototyping may be high. Many companies have development methodologies in place, and changing them can mean retraining, retooling, or both. Many companies tend to just jump into the prototyping without bothering to retrain their workers as much as they should.

A common problem with adopting prototyping technology is high expectations for productivity with insufficient effort behind the learning curve. In addition to training for the use of a prototyping technique, there is an often overlooked need for developing corporate and project specific underlying structure to support the technology. When this underlying structure is omitted, lower productivity can often result.

Evolutionary Prototyping

EVOLUTIONARY PROTOTYPING

Evolutionary Prototyping is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. “The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built. When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt. This technique allows the development team to add features, or make changes that couldn’t be conceived during the requirements and design phase.

Evolutionary Prototyping have an advantage over Throwaway Prototyping in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the, final system is delivered. It is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed version.The user may decide that a ‘flawed’ system is better than no system at all

In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system. To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest.

Best Projects to Use Prototyping

It has been argued that prototyping, in some form or another, should be used all the time. However, protttyping is most beneficial in systems that will have many interactions with the users.

It has been found that prototyping is very effective in the analysis and design of on-line systems, especially for transaction processing, where the use of screen dialogs is much more in evidence. The greater the interaction between the computer and the user, the greater the benefit is that can be obtained from building a qui.ck system and letting the user play with it.

Systems with little user interaction, such as batch processing or systems that mostly do calculations, benefit little from prototyping. Sometimes, the coding needed to perform the system functions may be too intensive and the potential gains that prototyping could provide are too small.

Prototyping is especially good for designing good human-computer interfaces. “One of the most productive uses of rapid prototyping to date has been as a tool for iterative user requirements engineering and human-computer interface design.”

Advantages of Prototyping

There are many advantages to using prototyping in software development which are as follows :

  1. Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software.
  2. Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications. The presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believe the other understands what they Since users know the problem domain better than anyone on the development team does, increased interaction can result in final product that has greater tangible and intangible quality. The final product is more likely to satisfy the users desire for look, feel and performance.

Prototyping

PROTOTYPING

Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an integral part of the system design process, where it is believed to reduce project risk and cost. Often one or more prototypes are made in a process of iterative and incremental development where each prototype is influenced by the performance of previous designs, in this way problems or deficiencies in design can be corrected. When the prototype is sufficiently refined and meets the functionality, robustness, manufacturability and other design goals, the product is ready for production.

Prototyping is the process of building a model of a system. In terms of an information system, prototypes are employed to help system designers build an information system that intuitive and easy to manipulate for end users. Prototyping is an iterative process that is part of the analysis phase of the systems development life cycle. During the requirements determination portion of the systems analysis phase, system analysts gather information about the organization’s current procedures and business processes related the proposed information system. In addition, they study the current information system, if there is one, and conduct user interviews and collect documentation. This helps the analysts develop an initial set of system requirements.

Prototyping can augment this process because it converts these basic, yet sometimes intangible, specifications into a tangible but limited working model of the desired information system. The user feedback gained from developing a physical system that the users can touch and see facilitates an evaluative response that the analyst can employ to modify existing requirements as well as developing new ones.

Prototyping comes in many forms – from low tech sketches or paper screens from which users and developers can paste controls and objects, to high tech operational systems using CASE (computer-aided software engineering) or fourth generation languages and everywhere in between. Many organizations use multiple prototyping tools. For example, some will use paper in the initial analysis to facilitate concrete user

feedback and then later develop an operational prototype using fourth generation languages, such as Visual Basic, during the design stage.

The process of prototyping involves the following steps :

  1. Identify basic requirements : Determine basic requirements including the input and output information desired. Details such as security, can typically be ignored.
  2. Develop Initial Prototype : The initial prototype is developed that includes only user interfaces.
  3. Review : The customers, including end-users, examine the prototype and provide feedback on additions or changes.
  4. Revise and Enhancing the Prototype : Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are introduced then a repeat of steps 3 and step 4 may be needed.

Types of prototyping

Software prototyping has many variants. However, all the methods are in some way based on two major types of prototyping : Throwaway Prototyping and EvolutionaryPrototyping.

Throwaway prototyping

Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rathey than becoming part of the finally delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.

Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is ‘thrown away’, and the system is formally developed based on the identified. requirements. The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development life cycle is extremely cost effective since there is nothing at that point to re-do. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded.

Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work.

In this approach the prototype is constructed with the idea that it will be discarded and the final system will be built from scratch. The steps in this approach are :

  1. Write preliminary requirements
  2. Design the prototype
  3. User experiences/uses the prototype,specifies new requirements.
  4. Writing final requirements
  5. Developing the real product.

Processes

PROCESSES

There are several phases and processes in the user interface design some of which are

more demanded upon than others depending on the project which are as follows:

  • Functionality requirements gathering : Assembling a list of the functionality required of the system to accomplish the goals of the project and the potential needs of the users.
  • User analysis : Analysis of the potential users of the system either through discussion with people who work with the users and/or the potential users themselves. Typical questions involve:
  • What would the user want the system to do?
  • How would the system fit in with the user’s normal workflow or daily activities?
  • How technically savvy is the user and what similar systems does the user already use?
  • What interface look & feel styles appeal to the user?
  • Information architecture – Development of the process and/or information flow of the system (i.e. for phone tree systems, this would be an option tree flowchart and for web sites this would be a site flow that shows the hierarchy of the pages).
  • Prototyping – Development of wireframes, either in the form of paper prototypes or simple interactive screens. These prototypes are stripped of all look & feel elements and most content in order to concentrate on the interface.
  • Usability testing – Testing of the prototypes on an actual user-often using a technique called talk aloud protocol where you ask the user to talk about their thoughts during the experience.
  • Graphic Interface design – Actual look and feel design of the final graphical user interface (GUI). It may be based on the findings developed during the usability testing if usability is unpredictable, or based on communication objectives and styles that would appeal to the user. In rare cases, the graphics may drive the prototyping, depending on the importance of visual form versus If the interface requires multiple skins, there may be multiple interface designs for one control panel or functional feature. This phase is often a collaborative effort between a graphic designer and a user interface designer, or handled by one who is proficient in both disciplines.

User interface design needs good understanding of user needs.

User Interface Design

USER INTERFACE DESIGN

User interface design or user interface engineering is the design of computers, appliances, machines, mobile communication devices, software applications, and websites with the focus on the user’s experience and interaction. Where traditional graphic design seeks to make the object or application physically attractive, the goal of user interface design is to make the user’s interaction as simple and efficient as possible, in terms of accomplishing user goals-what is often called user-centered design.

Where good graphic/industrial design is bold and eye catching, good user interface design is to facilitate finishing the task at hand over drawing attention to itself. Graphic design may be utilized to apply a theme or style to the interface without compromising its usability. The design process of an interface must balance the meaning of its visual elements that confirm the model of operation, and the functionality from a technical engineering perspective, in order to create a system that is both usable and easy to adapt to the changing user needs.

User Interface design is involved in a wide range of projects from computer systems, to cars, to commercial plans; all of these projects involve much of the same basic human interaction yet also require some unique skills and knowledge. As a result, user interface designers tend to specialize in certain types of projects and have skills centered around their expertise, whether that be software design, user research, web design, or industrial design.

Data Models

DATA MODELS

Definition : A data model is a collection of conceptual tools for describing data, their relationships, data semantics and consistency constraints.

(1) Record Based Logical Models

— Relational

  • Network

— Hierarchical

  • Physical Data Models
  • Object Based Logical Models
  • ER model
  • Object Oriented Model

(1) Hierarchical Model

  • It organises data in a tree structure.
  • There is a hierarchy of a parent and child data segments. This segment implies that a record can have repeating information, generally in the child data segment.
  • Here the data and relationships among data are represented by records and links

The record are organized as collection of trees rather than arbitrary graphs.

Hierarchical Model

(2) Relational Model

It represents data and relationships among data by a collection of tables, each of which has a number of columns with unique names.
Relational Model

Relational Model 2

(3) Network Model

— • Data in the Network model are represented by collection of records and relationships among data are represented by links which can be viewed as pointers.

  • The records in the database are organized as collection of arbitrary graphs.
  • It permits M : N relationship.

(4) Object-Based Logical Model

They are used in describing data at the conceptual and view levels. examples are :

  • E-R Model
  • Object-oriented Model.

(a) E-R-Model :

  • it is based on the perception of a real world which consists of a collection of basic objects called entities and relationships among these objects.
  • An entity is an object that is distinguishable from other objects by a specific set of attributes.
  • relationship is an association among several entities.
  • The set of all entities of same type and relationships of same type are termed as entity set and relationship set respectively.

The overall logical structure of database can be expressed graphically by an E-R-diagram.

(b) Object-Oriented Model

  • It is based on a collection of objects.
  • And object has :
  • A set of variables that contains the data for object. The value of each variable is itself an object.
  • A set of messages to which an object responds.
  • A method, which is a body of code to implement each message. A method returns a value as the response to the message.

 

The objects that contain the same type of values and same methods are grouped together into classes. A class may be viewed as a type definition for objects.

(3) Physical Data Models

  • Physical data models are used to describe data at the lowest level.