Marketing strategies for product software assist software firms to determine the type of market analysis that is needed for decision-making. Two general strategies that are well known in the marketing discipline are:
marketing mix; and
relationship marketing.
"Marketing mix" is the typical strategy for traditional mass marketers of product software in competitive markets. Structured market research, and agility in reacting to sales, are characteristic of their product development process (Alajoutsijarvi et al., 2000). An example would be Electronic Arts, with their various home computer software games, which are advertised on television and sold in many electronic stores.
"Relationship marketing", (closely associated to CRM), is used by product software companies who focus on long-term customer relationships (Alajoutsijarvi et al., 2000). An example of this is SAP, which offers enterprise resource planning systems, along with support (since the software is complicated to install). Maintaining customer relationships helps sell additional modules and future upgrades.
Broethers and van't Kruis explain two other strategies that are important to the growth of software firms:
a service-based strategy; and
a different marketing channels strategy.
software etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
software etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
7 Aralık 2009 Pazartesi
Architecture/Design documentation
Architecture/Design documentation
Architecture documentation is a special breed of design document. In a way, architecture documents are third derivative from the code (design document being second derivative, and code documents being first). Very little in the architecture documents is specific to the code itself. 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 docs 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 (without relying heavily on obtuse jargon to dazzle the reader), and most importantly is impartial. It should honestly and clearly explain the costs of whatever solution it offers as best. The objective of a trade study is to devise the best solution, rather than to push a particular point of view. It is perfectly acceptable to state no conclusion, or to conclude that none of the alternatives are sufficiently better than the baseline to warrant a change. It should be approached as a scientific endeavor, not as a marketing technique.
A very important part of the design document in enterprise software development is the Database Design Document (DDD). It contains Conceptual, Logical, and Physical Design Elements. Database Design Document includes the formal information that the people who interact with the database needs. The purpose of preparing the DDD is to create a common source to be used by all players within the scene. The potential users are:
Database Designer
Database Developer
Database Administrator
Application Designer
Application Developer
When talking about Relational Database Systems, the document should include following parts:
Entity - Relationship Schema, including following information and their clear definitions:
Entity Sets and their attributes
Relationships and their attributes
Candidate keys for each entity set
Attribute and Tuple based constraints
Relational Schema, including following information:
Tables, Attributes, and their properties
Views
Constraints such as primary keys, foreign keys,
Cardinality of referential constraints
Cascading Policy for referential constraints
Primary keys
It is very important to include all information that is to be used by all actors in the scene. It is also very important to update the documents as any change occurs in the database as well.
Architecture documentation is a special breed of design document. In a way, architecture documents are third derivative from the code (design document being second derivative, and code documents being first). Very little in the architecture documents is specific to the code itself. 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 docs 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 (without relying heavily on obtuse jargon to dazzle the reader), and most importantly is impartial. It should honestly and clearly explain the costs of whatever solution it offers as best. The objective of a trade study is to devise the best solution, rather than to push a particular point of view. It is perfectly acceptable to state no conclusion, or to conclude that none of the alternatives are sufficiently better than the baseline to warrant a change. It should be approached as a scientific endeavor, not as a marketing technique.
A very important part of the design document in enterprise software development is the Database Design Document (DDD). It contains Conceptual, Logical, and Physical Design Elements. Database Design Document includes the formal information that the people who interact with the database needs. The purpose of preparing the DDD is to create a common source to be used by all players within the scene. The potential users are:
Database Designer
Database Developer
Database Administrator
Application Designer
Application Developer
When talking about Relational Database Systems, the document should include following parts:
Entity - Relationship Schema, including following information and their clear definitions:
Entity Sets and their attributes
Relationships and their attributes
Candidate keys for each entity set
Attribute and Tuple based constraints
Relational Schema, including following information:
Tables, Attributes, and their properties
Views
Constraints such as primary keys, foreign keys,
Cardinality of referential constraints
Cascading Policy for referential constraints
Primary keys
It is very important to include all information that is to be used by all actors in the scene. It is also very important to update the documents as any change occurs in the database as well.
Programming Tools
A programming tool or software development tool is a program or application that software developers use to create, debug, maintain, or otherwise support other programs and applications. The term usually refers to relatively simple programs that can be combined together to accomplish a task, much as one might use multiple hand tools to fix a physical object.
The history of software tools began with the first computers in the early 1950s that used linkers, loaders, and control programs. Tools became famous with Unix in the early 1970s with tools like grep, awk and make that were meant to be combined flexibly with pipes. The term "software tools" came from the book of the same name by Brian Kernighan and P. J. Plauger.
Tools were originally simple and light weight. As some tools have been maintained, they have been integrated into more powerful integrated development environments (IDEs). These environments consolidate functionality into one place, sometimes increasing simplicity and productivity, other times sacrificing flexibility and extensibility. The workflow of IDEs is routinely contrasted with alternative approaches, such as the use of Unix shell tools with text editors like Vim and Emacs.
The distinction between tools and applications is murky. For example, developers use simple databases (such as a file containing a list of important values) all the time as tools. However a full-blown database is usually thought of as an application in its own right.
For many years, computer-assisted software engineering (CASE) tools were sought after. Successful tools have proven elusive. In one sense, CASE tools emphasized design and architecture support, such as for UML. But the most successful of these tools are IDEs.
The ability to use a variety of tools productively is one hallmark of a skilled software engineer.
The history of software tools began with the first computers in the early 1950s that used linkers, loaders, and control programs. Tools became famous with Unix in the early 1970s with tools like grep, awk and make that were meant to be combined flexibly with pipes. The term "software tools" came from the book of the same name by Brian Kernighan and P. J. Plauger.
Tools were originally simple and light weight. As some tools have been maintained, they have been integrated into more powerful integrated development environments (IDEs). These environments consolidate functionality into one place, sometimes increasing simplicity and productivity, other times sacrificing flexibility and extensibility. The workflow of IDEs is routinely contrasted with alternative approaches, such as the use of Unix shell tools with text editors like Vim and Emacs.
The distinction between tools and applications is murky. For example, developers use simple databases (such as a file containing a list of important values) all the time as tools. However a full-blown database is usually thought of as an application in its own right.
For many years, computer-assisted software engineering (CASE) tools were sought after. Successful tools have proven elusive. In one sense, CASE tools emphasized design and architecture support, such as for UML. But the most successful of these tools are IDEs.
The ability to use a variety of tools productively is one hallmark of a skilled software engineer.
6 Aralık 2009 Pazar
Software Evaluation
Program evaluation is a systematic method for collecting, analyzing, and using information to answer basic questions about projects, policies and programs[1]. Program evaluation is used in the public and private sector and is taught in numerous universities. Evaluation became particularly relevant in the U.S. in the 1960s during the period of the Great Society social programs associated with the Kennedy and Johnson administrations[2][3]. Extraordinary sums were invested in social programs, but the impacts of these investments were largely unknown.
Program evaluations can involve quantitative methods of social research or qualitative methods or both. People who do program evaluation come from many different backgrounds: sociology, psychology, economics, social work. Some graduate schools also have specific training programs for program evaluation.
wiki
Program evaluations can involve quantitative methods of social research or qualitative methods or both. People who do program evaluation come from many different backgrounds: sociology, psychology, economics, social work. Some graduate schools also have specific training programs for program evaluation.
wiki
Kaydol:
Kayıtlar (Atom)