Personally, I haven't encountered a lot of literature in academia, insofar as project management. I've read some little about the Capability Maturity Model (CMM), perhaps a sort of monolithic or centralized project management model, and some little about Scrum. I've not read a lot about "Extreme Programming" (XP) -- sort of an older agile project management trend, in a sense -- but I understand that it involves an iterative process. I've also read a little about the ideas management method proposed by Scott Belsky, in the book, Making Ideas Happen. Belsky's Action Method addresses more of a creative approach, juxtaposed to what one might expect that an implementation of monolithic CMM might be like, at a personal level. Of course, a large project might need a large management information system (MIS) to manage it by, entailing a certain degree of formalism throughout.
Personally -- as my being a student, at this time in my life -- I'm more interested about management methods for small-scale, original projects, rather than for projects developed under monolithic requirements. As a person of any manner of a creative bent, and a student of a technical field, with some self-managed knowledge of computer programming language, personally I'm interested in developing a project management system for small-scale thesis development projects, and for small free/open source software (FOSS) projects -- in an abstract sense, two types of project. In juxtaposition to monolithic project management methods, personally I'm of an impression that each of a thesis type of project and a FOSS type of project might be -- in the most of which -- each managed individually, and by a small number of contributors.
To inquire, "How does a FOSS project begin?" or similarly, "How does a thesis project begin?" perhaps the Action Method might present the most readily applicable practical model for such a context -- as towards an ideas management phase of project development.
Towards a View of Idea Management
Aside to the metaphysical aspects of positive intention, ideas are some of the raw stuff of academic work. Parenthetically, the reader is offered the author's sincerest apology for a lack of formal citation, to that effect. Perhaps the reader may agree that it is a valid assertion. Broadly, it may be a matter of philosophy -- namely, towards a relevance of ideas, in academic work -- furthermore, a practical matter of a functional application of intellect to a formal or informal task. Whether or not that may satisfy all of a model of "Left brain" and "Right brain" knowledge, perhaps it at least serves to present two juxtaposed views about -- in broad sense -- a relevance of ideas.
Aside to this thesis, the reader -- at any time -- might wish to criticize the author's style of writing, if it may serve as a convenient alternative to an addressing of any of the content of the discussion. The author has an idea that the ad hominem mode of discussion occurs in numerous forms. Inevitably, there will be another biting ad hominem criticism over my own writing. At that, I might wish to only address the topic: Philosophy.
Ideas and Theses
Aside to this thesis, the reader -- at any time -- might wish to criticize the author's style of writing, if it may serve as a convenient alternative to an addressing of any of the content of the discussion. The author has an idea that the ad hominem mode of discussion occurs in numerous forms. Inevitably, there will be another biting ad hominem criticism over my own writing. At that, I might wish to only address the topic: Philosophy.
Ideas and Theses
In a capital sense, ideas cannot be exchanged for raw currency. Thesis articles -- insofar as being works made as expressions of ideas -- thesis articles may not seem to be terribly profitable, either, not in any manner of an immediate economic sense. In a practical sense, a thesis article about barns does not in itself build a barn, though a thesis article may ever attract some manner of attention from a barn builder. In a literate society, thesis articles -- as literate works -- thesis articles are one manner of a textual medium on which ideas may be communicated.
Without any too lengthy reference to the Business Process Management Notation (BPMN), hypothetically, a model can be developed for a process of thesis article development. Certainly, thesis articles are works developed in chronologically linear manner, from a discrete "Start point" to a discrete "Stop point," at which time the work is published or filed away, if not altogether abandoned. The process of developing a thesis paper, essentially, is a process of developing ideas, and expressing those ideas on a written medium. In that sense, it may be analogous to a development of any of other forms of prose, and forms of written verse, such as poetry.
Thesis articles, as ideal media, thesis articles may not seem to serve any single, exacting functional role in society, except insofar as being required of some academic programs. If all of the world is a functional world, thesis articles may not seem to have any obvious relevance -- at least, outside of any manners of academic cultures as in which thesis articles would be any manner of a common fare. Ideally, even in proceeding from academic cultures in which learning itself would seem to be presupposed to be something akin to "Just press play", there may be a relevance recognized of thesis articles as discursive works, in a literary medium, works communicating ideas, and serving in further development of ideas. Hypothetically, a diagram of the ideas content of a single set of thesis works and the ideal derivatives of thesis articles may be all made in a single directed graph. In a practical sense, there is at least the bibliographical cross-reference, incidental to the actual content of individual thesis articles.
Without any too lengthy reference to the Business Process Management Notation (BPMN), hypothetically, a model can be developed for a process of thesis article development. Certainly, thesis articles are works developed in chronologically linear manner, from a discrete "Start point" to a discrete "Stop point," at which time the work is published or filed away, if not altogether abandoned. The process of developing a thesis paper, essentially, is a process of developing ideas, and expressing those ideas on a written medium. In that sense, it may be analogous to a development of any of other forms of prose, and forms of written verse, such as poetry.
Thesis articles, as ideal media, thesis articles may not seem to serve any single, exacting functional role in society, except insofar as being required of some academic programs. If all of the world is a functional world, thesis articles may not seem to have any obvious relevance -- at least, outside of any manners of academic cultures as in which thesis articles would be any manner of a common fare. Ideally, even in proceeding from academic cultures in which learning itself would seem to be presupposed to be something akin to "Just press play", there may be a relevance recognized of thesis articles as discursive works, in a literary medium, works communicating ideas, and serving in further development of ideas. Hypothetically, a diagram of the ideas content of a single set of thesis works and the ideal derivatives of thesis articles may be all made in a single directed graph. In a practical sense, there is at least the bibliographical cross-reference, incidental to the actual content of individual thesis articles.
That a thesis article represents a communicative medium, in communicating ideas in a literal manner, that in itself does not describe how to write an idea down.
Presently, the linear thread of this article's textual content will diverge onto software development.
Logical Software Development
In a functional manner, a software program represents a linear application of digital data and control structures, such as to produce some manner of a functional result in a microprocessor for which the software program is compiled into machine code. Prototypically, the microprocessor is the central element of a software program, Once compiled to machine code, a software program performs a linear series of applications of digital functions and digital data shift procedures, in any number of linear, processor-level threads of execution. Excepting procedures applied for data shift, as in memory access and in transmission and receiving of data onto digital communication interfaces, the digital functions provided of a microprocessor architecture may include mathematical functions, for scalar and floating point values.
Firmware programming, as a manner of software programming -- as in an instance of FPGA programming -- firmware programming, insofar as FPGA programming, represents a configuration of circuit elements, such that those circuit elements would either produce a direct implementation of a discrete functional model, or that the circuit as implemented of an FPGA program would, itself, be a programmable element of a computer.
Insofar as that a software program and an FPGA program -- in a categorical manner -- would both represent an application of software for application of a digital system, then a certain philosophical parallel may be illustrated between the two categories, in some abstraction. Essentially, an FPGA program configures a digital machine. A software program applies a digital machine, whether a microprocessor implemented as an FPGA program or a microprocessor implemented directly in a semiconductor design.
Software programming, as a practice, would represent a work of developing of a software program. A software program, itself, represents -- essentially -- a medium for application and control of a digital system.
If there may be a single topic denoted of the stylistic qualities of applications of individual programming languages, perhaps it would be a contentious topic to develop. For instance, what manner of a Java collection class is preferred for which applications? What is the deeper meaning of a Common Lisp iterative macro? How often should C pointer arithmetic be applied? Opinions might vary.
To differentiate programming languages on a basis of programming media, broadly, there are text-based programming languages -- such as C, C++, Java, and the numerous dialects of Lisp -- and some visual programming languages -- at which topic, the author refers the reader to an article at Wikipedia: Visual Programming Language, The author would wish to categorize the older punched--card and punched-tape programs as being some earlier text-based languages -- presumably, those not having been designed expressly for the visual qualities of the chad-betokened storage surfaces on which the historic punched-paper programs would be conveyed to their respective machines.
Again in a social context, the choice of a licensing model for a software program -- there is another possibly contentious topic, in software programming, certainly a topic much related to any number of topics in social, commercial, and legal views of a concept of software program as property.
So, this article has developed a succinct view of two distinct qualities of a software program: The programming language, and the license under which the software program is developed. Again viewing a software program as a categorical item distinct to a thesis paper, there is also the distinct quality of documentation for a software program. Consulting the FreeBSD Handbook. at a level of a view of project meta-data, a software project itself may essentially contain any one or more thesis projects, insofar as the documentation quality of a software project.
In a view of resources and resource containers, the whole set of documentation resources of a software project may not be represented singularly of any single source tree in which the software project is formally developed. That is, documentation may be available about a software project, such that the documentation is not developed by the software project developers, or at least is not contained in the same source tree as the software project itself.
Again, that is not to say how a software project is developed. It is to suggest a sense of a model of what a software project represents, in a sense of three fundamental qualities: A selection of a programming language; a software license for the content of the software program, altogether; documentation. Finally, there is the content of the software program itself -- as the software program being represented in a sense of source code or compiled code and correlated data elements -- the latter not being, expressly, "Program code," though supporting the execution of the program code, for instance as with firmware data for driving an external peripheral, or visual graphics data for the layout of a graphical program interface.
Certainly, the relevance of logic in software development, as a topic, may not be as easily illustrated as the relevance of ideas in development of thesis articles. A software program -- as a product of a software project -- may represent a multi-faceted kind of work, including some literary work in a form of documentation.
As in order to develop a concept of a relevance of ideas in software development, a concept of topic maps may be presented.
Insofar as to answer a question, "How is a software program developed?" perhaps that may be illustrated with any single "Proof of concept." A concept of requirements, and of styles for best practice in application of any single programming language -- perhaps, again, some contentious topics.
The concept, "For attention" may not be sufficient as a goal or a requirement for software program development. Incentive -- there, another complex and perhaps contentious quality of software program development.
Why?
If it may be possible to develop a system applying CORBA for project management, and that system support an individual, decentralized, by-in-large independent manner of management -- as in development of thesis articles and, in a separate sense, software -- of course, one would want to have determined, "What is that CORBA application going to support?" At that, of course it should be implemented with a license making a clear statement of indemnity.
#YMMV
Firmware programming, as a manner of software programming -- as in an instance of FPGA programming -- firmware programming, insofar as FPGA programming, represents a configuration of circuit elements, such that those circuit elements would either produce a direct implementation of a discrete functional model, or that the circuit as implemented of an FPGA program would, itself, be a programmable element of a computer.
Insofar as that a software program and an FPGA program -- in a categorical manner -- would both represent an application of software for application of a digital system, then a certain philosophical parallel may be illustrated between the two categories, in some abstraction. Essentially, an FPGA program configures a digital machine. A software program applies a digital machine, whether a microprocessor implemented as an FPGA program or a microprocessor implemented directly in a semiconductor design.
Software programming, as a practice, would represent a work of developing of a software program. A software program, itself, represents -- essentially -- a medium for application and control of a digital system.
If there may be a single topic denoted of the stylistic qualities of applications of individual programming languages, perhaps it would be a contentious topic to develop. For instance, what manner of a Java collection class is preferred for which applications? What is the deeper meaning of a Common Lisp iterative macro? How often should C pointer arithmetic be applied? Opinions might vary.
To differentiate programming languages on a basis of programming media, broadly, there are text-based programming languages -- such as C, C++, Java, and the numerous dialects of Lisp -- and some visual programming languages -- at which topic, the author refers the reader to an article at Wikipedia: Visual Programming Language, The author would wish to categorize the older punched--card and punched-tape programs as being some earlier text-based languages -- presumably, those not having been designed expressly for the visual qualities of the chad-betokened storage surfaces on which the historic punched-paper programs would be conveyed to their respective machines.
Again in a social context, the choice of a licensing model for a software program -- there is another possibly contentious topic, in software programming, certainly a topic much related to any number of topics in social, commercial, and legal views of a concept of software program as property.
So, this article has developed a succinct view of two distinct qualities of a software program: The programming language, and the license under which the software program is developed. Again viewing a software program as a categorical item distinct to a thesis paper, there is also the distinct quality of documentation for a software program. Consulting the FreeBSD Handbook. at a level of a view of project meta-data, a software project itself may essentially contain any one or more thesis projects, insofar as the documentation quality of a software project.
In a view of resources and resource containers, the whole set of documentation resources of a software project may not be represented singularly of any single source tree in which the software project is formally developed. That is, documentation may be available about a software project, such that the documentation is not developed by the software project developers, or at least is not contained in the same source tree as the software project itself.
Again, that is not to say how a software project is developed. It is to suggest a sense of a model of what a software project represents, in a sense of three fundamental qualities: A selection of a programming language; a software license for the content of the software program, altogether; documentation. Finally, there is the content of the software program itself -- as the software program being represented in a sense of source code or compiled code and correlated data elements -- the latter not being, expressly, "Program code," though supporting the execution of the program code, for instance as with firmware data for driving an external peripheral, or visual graphics data for the layout of a graphical program interface.
Certainly, the relevance of logic in software development, as a topic, may not be as easily illustrated as the relevance of ideas in development of thesis articles. A software program -- as a product of a software project -- may represent a multi-faceted kind of work, including some literary work in a form of documentation.
As in order to develop a concept of a relevance of ideas in software development, a concept of topic maps may be presented.
Insofar as to answer a question, "How is a software program developed?" perhaps that may be illustrated with any single "Proof of concept." A concept of requirements, and of styles for best practice in application of any single programming language -- perhaps, again, some contentious topics.
The concept, "For attention" may not be sufficient as a goal or a requirement for software program development. Incentive -- there, another complex and perhaps contentious quality of software program development.
Why?
If it may be possible to develop a system applying CORBA for project management, and that system support an individual, decentralized, by-in-large independent manner of management -- as in development of thesis articles and, in a separate sense, software -- of course, one would want to have determined, "What is that CORBA application going to support?" At that, of course it should be implemented with a license making a clear statement of indemnity.
#YMMV
