Patent Application
20090100406
Software development teams employ domain specific knowledge in order to develop software solutions to real world problems. This domain specific knowledge can include, for example, information regarding business processes, functional and non-functional requirements, business and technical architecture, proven technology choices and implementation decisions, reusable patterns and guidelines, regulatory compliance statements, deployment practices and the like.
Development of software is generally accomplished to acceptable levels of quality. For example, the acceptable levels of quality can include, in addition to functional requirements, conformance to industry standards, manufacturing practices, organizational policies and/or governmental regulations. A development goal can further include embodiment of established methodologies and patterns such that others can understand and maintain the developed software. Additional development goals can include quality attributes, for example, usability, reliability, performance and/or scalability with acceptable levels of resource consumption.
Conventionally, development teams have employed generic tools and platforms to develop software. However, employing these generic tools and platforms has proven frustrating for the development teams as it has been difficult to produce solutions that deliver the required functionality with acceptable quality. Further, using the generic tools and platforms, development teams have been unable to reliably predict budgets and schedules. For example, employment of generic tools and platforms can result in software developed which is over budget and/or is not produced on time. Additionally, the developed software can be of poor quality and/or consistency, have less than optimal traceability, require a significant ramp-up time and/or result in high maintenance costs.
The following presents a simplified summary in order to provide a basic understanding of novel embodiments described herein. This summary is not an extensive overview, and it is not intended to identify key/critical elements or to delineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
The disclosed systems and methods facilitate software development by providing a software factory based on an instance of a metamodel (i.e., a model) called a “factory schema” or simply a “schema”. The model defines one or more viewpoints or perspectives with each viewpoint defining views of the software that isolate a specific set of concerns, typically specifying the scope of such a view, the notation(s), if any, used to render it, and the editor(s), if any, used to create and modify it. The model may further define the type(s) of work product(s), if any, produced from each viewpoint, and template(s) for the task(s), if any, executed to produce or maintain each type of view or work product. The model may further define relationship(s) among the viewpoints, as well as relationships between viewpoint(s) and work product types(s), and operation(s) that can be performed across relationship(s). Additionally, the model may describe asset(s), if any, available to support the execution of any task(s) instantiated from the task template(s).
In one implementation, a computer-implemented software factory specification system is provided. The software factory specification system can be employed, for example, by a factory developer to specify a factory schema. The factory schema and the editor(s), task template(s) and asset(s) described collectively form a “software factory”, or simply a “factory” that can capture domain specific knowledge, for example, business processes, requirements, architecture, technology decisions, implementation, patterns and guidelines, regulatory compliance, development constraints, etc. Once implemented, a software factory can be employed, for example, to tailor a general purpose interactive development environment (IDE) to develop a specific kind of software solution.
To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles disclosed herein can be employed. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the drawings.
The disclosed systems and methods facilitate software development by providing a software factory based on an instance of a metamodel (i.e., a model), called a “factory schema”, or simply a “schema”. The factory schema captures domain specific knowledge to facilitate building of software solutions to real world problems, defining tasks that can be performed by a software development team to build such solutions, and providing editor(s) and asset(s) that can be used when performing the tasks.
The model defines one or more viewpoints or perspectives with each viewpoint defining views of the software that isolate a specific set of concerns, typically specifying the scope of such a view, the notation(s), if any, used to render the view, and the editor(s), if any, used to create and modify the view. The model may further define the type(s) of work product(s), if any, produced from each viewpoint, and template(s) for the task(s), if any, executed to produce and/or maintain each type of view or work product. The model may further define relationship(s) among the viewpoints, as well as relationships between viewpoint(s) and work product(s), and operation(s) that can be performed across relationship(s). Additionally, the model may describe asset(s), if any, available to support the execution of any task(s) instantiated from the task template(s).
Such a model can be defined, for example, by a factory developer. In one implementation, the model and the editor(s), task template(s) and asset(s) defined can be collectively employed in an interactive development environment by a development team to produce a specific type of product (e.g., client application, mobile client, web service(s), etc.).
Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the novel embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate a description thereof
Referring initially to the drawings,
The factory schema 130 can be employed in an interactive development environment, along with the editor(s), task template(s) and asset(s) described, to support the specification, development, deployment and maintenance of a product (e.g., client application, mobile client, web service(s), etc.). The factory schema 130 and the editor(s), task template(s) and asset(s) described collectively form a “software factory”, or simply a “factory”, that can be employed to improve the productivity of software development team(s) by enabling systematic reuse of software assets that can be applied to produce a wide range of variants of a specific type of software system by exploiting well-defined variability points.
Conventional systems designed to promote the reuse of software assets have been only marginally successful. The metamodel 110 facilitates more effective reuse of software assets by specifying the structure of a factory schema 130 that defines the architectural context(s) in which work products are developed, by placing the process(es) used to develop each work product in the same architectural context(s), and, by providing assets that can be applied to support the enactment of the process(es), for example, within an interactive development environment.
Turning briefly to
The metamodel 110 further supports the specification within a factory schema 130 of relationship(s) 220 among viewpoints 210 and between viewpoint(s) 210 and work product types(s) 260, and, operation(s) 230 that can be performed across relationships 220. Additionally, the metamodel 110 supports the specification within a factory schema 130 of a set of task templates(s) 240 describing tasks that comprise template(s) 270 for workstream(s) (e.g., custom process(es)) for each viewpoint 210, and, a set of asset(s) 250 (e.g., reusable assets) available to accelerate execution of each instance of a task template 240 (i.e., each task). The metamodel 110 further supports the definition within a factory schema 130 of the type(s) of work product(s) 260 to be consumed and/or produced by each task.
Turning briefly to
Referring to
For each viewpoint 210, the factory developer can specify the type(s) of work product(s) 260 to be produced and define template(s) 240 for task(s) and template(s) 270 for workstream(s) comprised of sets of related tasks (e.g., custom process(es)) for building the specified work product(s) 260. The factory developer can further specify asset(s) 250 (e.g., reusable assets) that support enactment of the task(s) described by the task template(s) 240. The viewpoints 210, relationship(s) 220, operation(s) 230, task template(s) 240 and asset(s) specified, for example, by a factory developer can be described by a factory schema 130. Asset(s) 250 can include, for example, a document, a code template, a script, a pattern, etc.
The factory schema 130, thus, describes viewpoint(s) 210 and template(s) for task(s) 240 that are performed from the particular viewpoint(s) 210 along with asset(s) 250 available to support the performance of the particular task(s) described by the task template(s) 240.
Through the factory schema 130, the factory developer can capture domain specific knowledge regarding business processes, requirements, architecture, technology decisions, implementation, patterns and guidelines, regulatory compliance, development and the like. Using a factory described by such a factory schema 130, a development team can produce software solutions in a structured manner within the architecture specified by the factory developer. Once specified by the factory developer, the factory schema 130 can be employed, along with the editor(s), task template(s) and asset(s) described, for example, in an interactive development environment (IDE) as a software factory, as described in great detail below.
By using the metamodel 110 to specify a factory schema 130, a factory developer can provide a baseline for the development of a software product. Since the factory schema 130 defines a repeatable process, quality and consistency can be predicted more accurately and improved by refining the factory as experience is gained. Additionally, the factory environment can facilitate traceability of software requirements.
For example, the factory schema 130 can enable the software development team to quickly identify work that needs to be accomplished and the best manner in which the work can be accomplished. In one implementation, reusable asset(s) 250 can help the software development team to quickly perform the work that needs to be accomplished.
The structure inherent to the factory schema 130 can result in reduced maintenance costs of the product produced by the software factory. Additionally, changes to the product produced by the software factory can be more readily understood. Further, new member(s) of the software development team can be brought up to speed more quickly.
Turning to
In one implementation, the user interface component 410 is an interactive development environment (IDE). Thus, the software factory system 400 is an extension of the IDE which supplies and supports the application of domain specific knowledge that has been captured in the factory schema 130, for example, by a factory developer, as discussed previously. The factory schema 130 further enables harvesting, production and/or packaging of contextualized manual and/or automated guidance that encapsulates that knowledge and makes the knowledge available to member(s) of a development team and/or their customers.
A user of the system 400 is able to interact with the factory schema 130 via the user interface component 410. The user interface component 410 can expose graphical user interface(s) (GUIs) and/or application program interface(s) (APIs) which interact with the factory schema 130 to assist in creation of the product 420.
The factory schema 130 includes a description of viewpoints 210, a set of work product type(s) 260 associated with particular viewpoints 210, a set of templates for task(s) 240 associated with particular viewpoints and work product type(s) 260, and asset(s) 250 associated with particular task template(s) 240. That is, factory schema 130 describes asset(s) 250 associated with a particular task template 240 associated with a particular viewpoint 210 or work product type 260.
In one implementation, the factory schema 130 allows member(s) of the development team to access one or more views of the product 420 (e.g., the software system under development) corresponding to viewpoints 210 defined in the factory schema 130. The team member(s) can further retrieve and use relationships 220 and operations 230 across viewpoints 210, generate tasks and workstream(s) (i.e., customized processes) from task template(s) 240 and workstream templates 270, and access associated asset(s) 250 for those tasks, in order to evaluate and modify the state of the product 420 under development expressed as a collection of work products (i.e., instances of work product type(s) 260), as an extension to an IDE (e.g., MICROSOFT® VISUAL STUDIO® Team System development environment). Using the factory schema, instances of the viewpoints it describes (i.e., views), and instances of the work product types it describes (i.e., work products) the IDE can facilitate a user's visualization of a structure of the product 420. Using the tasks and workstreams described by the templates supplied by the factory schema, the IDE can further facilitate a user's tracking of progress on parts of the product 420.
The system 400 can support a manner to build a specific type of product 420 as described in the factory schema 130. The factory schema 130 can describe a custom process for building the product 420. Via the user interface component 410, a user can obtain information regarding execution of identified task(s) and asset(s) supporting each task.
In one example, the factory schema 130 describes a core subset of tasks associated with a particular need. That is, the factory schema 130 describes aspects that are common and repeatable across all products 420. In this manner, software development time can be reduced while quality is increased through the employment of reusable assets.
Next, referring to
In this example, the user interface 500 provides a platform (e.g., GUIs and APIs) for developing software using the software factory system 400. The user interface 500 provides a graphical representation that can assist user(s) to interact with the software factory system 400 to produce the product 420. In this example, the user can select a single activity “CREATE DESIGN”. Selection of the “CREATE DESIGN” task causes the software factory system 400 to display information as specified in the factory schema 130.
Turning to
The user can create view(s) associated with a viewpoint 210. A “view” is a specific description of a specific product 420 under development from a particular viewpoint 210. A view often maps to a specific document opened in a particular editor. A view is associated with a specific product 420 that the software factory system 400 is building. A view also may contain one or more instances of the work product type(s) 260 (i.e., work products) that have been specified in the factory schema 130 in the context of a particular viewpoint 210.
Referring briefly to
In one implementation, the software factory system 400 can capture information associated with the software development experience which can assist in budgeting and scheduling. For example, the system 400 can capture the amount of time a particular task took to complete, the number and skills of user(s) that worked on a particular task, etc.
At 800, viewpoints are created in a factory schema 130, for example, an instance of the metamodel 110. For example, a factory developer can create a factory schema to be employed in an interactive development environment as part of a software factory system 400. The viewpoints created can correspond to specific aspects of software architecture representing and isolating concerns of stakeholders in specific roles.
At 802, editors are provisioned and assigned to viewpoints that require editor(s). Some, all or none of the viewpoints may require editors.
At 804, task templates(s) are created for each viewpoint. The task template(s) can be grouped into workstream template(s) 270 describing workstreams that represent custom process(es) for building instances of the work product type(s) 260 in instance(s) of the particular viewpoint (i.e., view(s)). The work product type(s) 260 are also created in this step.
At 806, asset(s) are provisioned and assigned to each task. The assets can be reusable software assets, for example, document(s), recipes and the like. At 808, relationship(s) are created among viewpoints 210 and/or between viewpoints 210 and work product types 260.
At 810, operation(s) are defined and assigned to relationship(s). At 812, the factory schema 130 and all of the items it describes are stored. The factory schema 130 and the items described by the factory schema 130 can be collectively stored (e.g., to be later employed in an interactive development environment as a software factory).
At 904, task(s) associated with a selected view or work product are generated from template(s), if necessary, and then displayed. For example, the task(s) can be part(s) of workstream(s) that implement custom process(es). Generally, tasks are generated once for a given context (i.e., for a given view or work product), and then displayed each time the context is selected. In one example, values for parameters in the templates can be provided by the context. For example, the name of a task can be taken from the name of the work product with which the task is associated.
At 906, asset(s) associated with a selected task are displayed. At 908, a selected task is performed using the associated asset(s). At 910, the particular product produced using the software factory is stored. The product can be a result of the performing the selected task(s).
While certain ways of displaying information to users are shown and described with respect to certain figures as user interfaces, those skilled in the relevant art will recognize that various other alternatives can be employed. The terms “screen,” “screenshot”, “webpage,” “document”, and “page” are generally used interchangeably herein. The pages or screens are stored and/or transmitted as display descriptions, as graphical user interfaces, or by other methods of depicting information on a screen (whether personal computer, PDA, mobile telephone, or other suitable device, for example) where the layout and information or content to be displayed on the page is stored in memory, database, or another storage facility.
As used in this application, the terms “component” and “system” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers.
Referring now to
Generally, program modules include routines, programs, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the inventive methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like, each of which can be operatively coupled to one or more associated devices.
The illustrated aspects may also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.
A computer typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer and includes volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media can comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital video disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer.
With reference again to
The system bus 1008 can be any of several types of bus structure that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory 1006 includes read-only memory (ROM) 1010 and random access memory (RAM) 1012. A basic input/output system (BIOS) is stored in a non-volatile memory 1010 such as ROM, EPROM, EEPROM, which BIOS contains the basic routines that help to transfer information between elements within the computer 1002, such as during start-up. The RAM 1012 can also include a high-speed RAM such as static RAM for caching data.
The computer 1002 further includes an internal hard disk drive (HDD) 1014 (e.g., EIDE, SATA), which internal hard disk drive 1014 may also be configured for external use in a suitable chassis (not shown), a magnetic floppy disk drive (FDD) 1016, (e.g., to read from or write to a removable diskette 1018) and an optical disk drive 1020, (e.g., reading a CD-ROM disk 1022 or, to read from or write to other high capacity optical media such as the DVD). The hard disk drive 1014, magnetic disk drive 1016 and optical disk drive 1020 can be connected to the system bus 1008 by a hard disk drive interface 1024, a magnetic disk drive interface 1026 and an optical drive interface 1028, respectively. The interface 1024 for external drive implementations includes at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.
The drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For the computer 1002, the drives and media accommodate the storage of any data in a suitable digital format. Although the description of computer-readable media above refers to a HDD, a removable magnetic diskette, and a removable optical media such as a CD or DVD, it should be appreciated by those skilled in the art that other types of media which are readable by a computer, such as zip drives, magnetic cassettes, flash memory cards, cartridges, and the like, may also be used in the exemplary operating environment, and further, that any such media may contain computer-executable instructions for performing novel methods of the disclosed architecture.
A number of program modules can be stored in the drives and RAM 1012, including an operating system 1030, one or more application programs 1032, other program modules 1034 and program data 1036. The software factory system 400 can be an application program 1032. All or portions of the operating system, applications, modules, and/or data can also be cached in the RAM 1012. It is to be appreciated that the disclosed architecture can be implemented with various commercially available operating systems or combinations of operating systems.
A user can enter commands and information into the computer 1002 through one or more wired/wireless input devices, for example, a keyboard 1038 and a pointing device, such as a mouse 1040. Other input devices (not shown) may include a microphone, an IR remote control, a joystick, a game pad, a stylus pen, touch screen, or the like. These and other input devices are often connected to the processing unit 1004 through an input device interface 1042 that is coupled to the system bus 1008, but can be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.
A monitor 1044 or other type of display device is also connected to the system bus 1008 via an interface, such as a video adapter 1046. In addition to the monitor 1044, a computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.
The computer 1002 may operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote computer(s) 1048. The remote computer(s) 1048 can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 1002, although, for purposes of brevity, only a memory/storage device 1050 is illustrated. The logical connections depicted include wired/wireless connectivity to a local area network (LAN) 1052 and/or larger networks, for example, a wide area network (WAN) 1054. Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communications network, for example, the Internet.
When used in a LAN networking environment, the computer 1002 is connected to the local network 1052 through a wired and/or wireless communication network interface or adapter 1056. The adaptor 1056 may facilitate wired or wireless communication to the LAN 1052, which may also include a wireless access point disposed thereon for communicating with the wireless adaptor 1056.
When used in a WAN networking environment, the computer 1002 can include a modem 1058, or is connected to a communications server on the WAN 1054, or has other means for establishing communications over the WAN 1054, such as by way of the Internet. The modem 1058, which can be internal or external and a wired or wireless device, is connected to the system bus 1008 via the serial port interface 1042. In a networked environment, program modules depicted relative to the computer 1002, or portions thereof, can be stored in the remote memory/storage device 1050. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.
Referring now to
The system 1100 also includes one or more server(s) 1104. The server(s) 1104 can also be hardware and/or software (e.g., threads, processes, computing devices). The servers 1104 can house threads to perform transformations by employing the architecture, for example. One possible communication between a client 1102 and a server 1104 can be in the form of a data packet adapted to be transmitted between two or more computer processes. The data packet may include a cookie and/or associated contextual information, for example. The system 1100 includes a communication framework 1106 (e.g., a global communication network such as the Internet) that can be employed to facilitate communications between the client(s) 1102 and the server(s) 1104.
Communications can be facilitated via a wired (including optical fiber) and/or wireless technology. The client(s) 1102 are operatively connected to one or more client data store(s) 1108 that can be employed to store information local to the client(s) 1102 (e.g., cookie(s) and/or associated contextual information). Similarly, the server(s) 1104 are operatively connected to one or more server data store(s) 1110 that can be employed to store information local to the servers 1104.
What has been described above includes examples of the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and/or methodologies, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
