Software construction is the process of creating working software via coding and integration. The process includes unit and integration testing although does not include higher level testing such as system testing. Construction is an aspect of the software development lifecycle and is integrated in the various software development process models with varying focus on construction as an activity separate from other activities. In the waterfall model, a software development effort consists of sequential phases including requirements analysis, design, and planning which are prerequisites for starting construction. In an iterative model such as scrum, evolutionary prototyping, or extreme programming, construction as an activity that occurs concurrently or overlapping other activities. Construction planning may include defining the order in which components are created and integrated, the software quality management processes, and the allocation of tasks to teams and developers. To facilitate project management, numerous construction aspects can be measured; these include the amount of code developed, modified, reused, and destroyed, code complexity, code inspection statistics, faults-fixed and faults-found rates, and effort expended. These measurements can be useful for aspects such as ensuring quality and improving the process. == Activities == Construction includes many activities. === Coding === The following are a few of the key aspects of the coding activity: Naming Choice of name for each identifier. One study showed that the effort required to debug a program is minimized when variable names are between 10 and 16 characters. Logic Organization into statements and routines Highly cohesive routines proved to be less error prone than routines with lower cohesion. A study of 450 routines found that 50 percent of the highly cohesive routines were fault free compared to only 18 percent of routines with low cohesion. Another study of a different 450 routines found that routines with the highest coupling-to-cohesion ratios had 7 times as many errors as those with the lowest coupling-to-cohesion ratios and were 20 times as costly to fix. Although studies showed inconclusive results regarding the correlation between routine sizes and the rate of errors in them, but one study found that routines with fewer than 143 lines of code were 2.4 times less expensive to fix than larger routines. Another study showed that the code needed to be changed least when routines averaged 100 to 150 lines of code. Another study found that structural complexity and amount of data in a routine were correlated with errors regardless of its size. Interfaces between routines are some of the most error-prone areas of a program. One study showed that 39 percent of all errors were errors in communication between routines. Unused parameters are correlated with an increased error rate. In one study, only 17 to 29 percent of routines with more than one unreferenced variable had no errors, compared to 46 percent in routines with no unused variables. The number of parameters of a routine should be 7 at maximum as research has found that people generally cannot keep track of more than about seven chunks of information at once. One experiment showed that designs which access arrays sequentially, rather than randomly, result in fewer variables and fewer variable references. One experiment found that loops-with-exit are more comprehensible than other kinds of loops. Regarding the level of nesting in loops and conditionals, studies have shown that programmers have difficulty comprehending more than three levels of nesting. Control flow complexity has been shown to correlate with low reliability and frequent errors. Modularity Structuring and refactoring the code into classes, packages and other structures. When considering containment, the maximum number of data members in a class shouldn't exceed 7±2. Research has shown that this number is the number of discrete items a person can remember while performing other tasks. When considering inheritance, the number of levels in the inheritance tree should be limited. Deep inheritance trees have been found to be significantly associated with increased fault rates. When considering the number of routines in a class, it should be kept as small as possible. A study on C++ programs has found an association between the number of routines and the number of faults. A study by NASA showed that the putting the code into well-factored classes can double the code reusability compared to the code developed using functional design. Error handling Encoding logic to handle both planned and unplanned errors and exceptions. Resource management Managing computational resource use via exclusion mechanisms and discipline in accessing serially reusable resources, including threads or database locks. Security Prevention of code-level security breaches such as buffer overrun and array index overflow. Optimization Optimization while avoiding premature optimization. Documentation Both embedded in the code as comments and as external documents. === Integration === Integration is about combining separately constructed parts. Concerns include planning the sequence in which components will be integrated, creating scaffolding to support interim versions of the software, determining the degree of testing and quality work performed on components before they are integrated, and determining points in the project at which interim versions are tested. === Testing === Testing can reduce the time between when faulty logic is inserted in the code and when it is detected. In some cases, testing is performed after code has been written, but in test-first programming, test cases are created before code is written. Construction includes at least two forms of testing, often performed by the developer who wrote the code: unit testing and integration testing. === Reuse === Software reuse entails more than creating and using libraries. It requires formalizing the practice of reuse by integrating reuse processes and activities into the software life cycle. The tasks related to reuse in software construction during coding and testing may include: selection of the reusable code, evaluation of code or test re-usability, reporting reuse metrics. === Quality assurance === Techniques for ensuring quality as software is constructed include: Testing One study found that the average defect detection rates of Unit testing and integration testing are 30% and 35% respectively. Software inspection With respect to software inspection, one study found that the average defect detection rate of formal code inspections is 60%. Regarding the cost of finding defects, a study found that code reading detected 80% more faults per hour than testing. Another study shown that it costs six times more to detect design defects by using testing than by using inspections. A study by IBM showed that only 3.5 hours were needed to find a defect through code inspections versus 15–25 hours through testing. Microsoft has found that it takes 3 hours to find and fix a defect by using code inspections and 12 hours to find and fix a defect by using testing. In a 700 thousand lines program, it was reported that code reviews were several times as cost-effective as testing. Studies found that inspections result in 20% - 30% fewer defects per 1000 lines of code than less formal review practices and that they increase productivity by about 20%. Formal inspections will usually take 10% - 15% of the project budget and will reduce overall project cost. Researchers found that having more than 2 - 3 reviewers on a formal inspection doesn't increase the number of defects found, although the results seem to vary depending on the kind of material being inspected. Technical review With respect to technical review, one study found that the average defect detection rates of informal code reviews and desk checking are 25% and 40% respectively. Walkthroughs were found to have a defect detection rate of 20% - 40%, but were found also to be expensive especially when project pressures increase. Code reading was found by NASA to detect 3.3 defects per hour of effort versus 1.8 defects per hour for testing. It also finds 20% - 60% more errors over the life of the project than different kinds of testing. A study of 13 reviews about review meetings, found that 90% of the defects were found in preparation for the review meeting while only around 10% were found during the meeting. Static analysis With respect to Static analysis (IEEE1028), studies have shown that a combination of these techniques needs to be used to achieve a high defect detection rate. Other studies showed that different people tend to find different defects. One study found that the extreme programming practices of pair programming, desk checking, unit testing, integration testing, and regression testing can achieve a 90% defect detection rate. An experiment involving exper
Softwarp
Softwarp is a software technique to warp an image so that it can be projected on a curved screen. This can be done in real time by inserting the softwarp as a last step in the rendering cycle. The problem is to know how the image should be warped to look correct on the curved screen. There are several techniques to auto calibrate the warping by projecting a pattern and using cameras and/or sensors. The information from the sensors is sent to the software so that it can analyze the data and calculate the curvature of the projection screen. == Usage == The softwarp can be used to project virtual views on curved walls and domes. These are usually used in vehicle simulators, for instance boat-, car- and airplane simulators. To make it possible to cover a dome with a 360 degree view you need to use several projectors. A problem with using several projectors on the same screen is that the edges between the projected images get about twice the amount of light. This is solved by using a technique called edge blending. With this technique a “filter” is inserted on the edge that fades the image from 100% light strength (luminance) to 0% (the lowest luminance depends on the contrast ratio of the projector). == History == The first warping technologies used a hardware image processing unit to warp the image. This processing unit was inserted between the graphics card and the projector. The problem with this technique is that it depends on the type of signal and the quality of the signal from the graphics card to warp it correctly. The process unit also needs several lines of image information before it can start sending out the warped image. This adds a latency to the display system that could be a problem in simulators that need fast response time, for instance fighter jet simulators. Softwarping eliminates the latency.
Tom's Planner
Tom's Planner is a web-based tool and application service provider for project planning, management and collaboration. == History == Tom's Planner is based on Curaçao. In November 2009, it announced its public beta launch on TechCrunch and moved out of beta in August 2010. In 2013 Tom's Planner acquired its competitor Gantto. == Software == Tom's Planner is project management software that enables the creation of project schedules (Gantt charts) using a visual perspective. Tom's Planner uses the Freemium Business Model. Users can register for a free account or choose a paid version. Tom's Planner is available in five languages and is used by thousands of users on a daily basis in more than 100 countries worldwide. Customers range from fortune 500 companies to small mom-and-pop shops. == Reviews == Tom's Planner has been reviewed by PC World, TechCrunch, Lifehacker, and several other periodicals.
The Outliner of Giants
The Outliner of Giants was commercial outlining software. Like other outliners, it allowed the user to create a document consisting of a series of nested lists. It was one of a number of browser-based outliners that are delivered as a web application, used through a web browser, rather than being installed as a stand-alone application. The Outliner of Giants was released in 2009. The service was shut down on December 31, 2017 and only exports are allowed at this time. == Feature set == Unlike most other browser-based outliners - which often focus on providing a minimum viable product - the Outliner of Giants had much of the functionality typically associated with a desktop outliner, such as the ability to use of columns to structure information. However, The Outliner of Giants did not support offline editing, requiring an active internet connection in order to make changes to an outline document. === Outlining === Like all outliners, The Outliner of Giants supported the creation of a hierarchy of items, with users modifying the parent-child relationship between items in order to structure a document. This included the ability to promote or demote items up or down the hierarchy, or move an item up or down a list of siblings on the same level. The Outliner of Giants did not support the true cloning of items (where an item can appear to be in multiple places within the hierarchy at the same time), although it did support the copying of single or multiple nodes. === Import === The Outliner of Giants could import both plain text and the OPML XML format, which is commonly used to transfer data between outlining applications. === Editing === Outline documents could be edited using a WYSIWYG editor, as well as the Markdown, and Textile markup languages. === Annotation === The Outliner of Giants supported functions to annotate an outline, such as the ability to add colored labels, highlights and text, as well as tags and hashtags. === Collaboration === The Outliner of Giants supported real-time collaboration, where multiple users could edit the same document, and can see the changes made by another user as they happened. === Publication === Outlines created through The Outliner of Giants could be published directly online through the service, either as outlines, pages or in a blog format. === Export === The Outliner of Giants can export outline data as plain text, HTML, as well as directly to the Google Docs word processor.
Web container
A web container (also known as a servlet container; and compare "webcontainer") is the component of a web server that interacts with Jakarta Servlets. A web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access-rights. A web container handles requests to servlets, Jakarta Server Pages (JSP) files, and other types of files that include server-side code. The Web container creates servlet instances, loads and unloads servlets, creates and manages request and response objects, and performs other servlet-management tasks. A web container implements the web component contract of the Jakarta EE architecture. This architecture specifies a runtime environment for additional web components, including security, concurrency, lifecycle management, transaction, deployment, and other services. == List of Servlet containers == The following is a list of notable applications which implement the Jakarta Servlet specification from Eclipse Foundation, divided depending on whether they are directly sold or not. === Open source Web containers === Apache Tomcat (formerly Jakarta Tomcat) is an open source web container available under the Apache Software License. Apache Tomcat 6 and above are operable as general application container (prior versions were web containers only) Apache Geronimo is a full Java EE 6 implementation by Apache Software Foundation. Enhydra, from Lutris Technologies. GlassFish from Eclipse Foundation (an application server, but includes a web container). Jetty, from the Eclipse Foundation. Also supports SPDY and WebSocket protocols. Open Liberty, from IBM, is a fully compliant Jakarta EE server Virgo from Eclipse Foundation provides modular, OSGi based web containers implemented using embedded Tomcat and Jetty. Virgo is available under the Eclipse Public License. WildFly (formerly JBoss Application Server) is a full Java EE implementation by Red Hat, division JBoss. === Commercial Web containers === iPlanet Web Server, from Oracle. JBoss Enterprise Application Platform from Red Hat, division JBoss is subscription-based/open-source Jakarta EE-based application server. WebLogic Application Server, from Oracle Corporation (formerly developed by BEA Systems). Orion Application Server, from IronFlare. Resin Pro, from Caucho Technology. IBM WebSphere Application Server. SAP NetWeaver.
Personality computing
Personality computing is a research field related to artificial intelligence and personality psychology that studies personality by means of computational techniques from different sources, including text, multimedia, and social networks. == Overview == Personality computing addresses three main problems involving personality: automatic personality recognition, perception, and synthesis. Automatic personality recognition is the inference of the personality type of target individuals from their digital footprint. Automatic personality perception is the inference of the personality attributed by an observer to a target individual based on some observable behavior. Automatic personality synthesis is the generation of the style or behaviour of artificial personalities in Avatars and virtual agents. Self-assessed personality tests or observer ratings are always exploited as the ground truth for testing and validating the performance of artificial intelligence algorithms for the automatic prediction of personality types. There is a wide variety of personality tests, such as the Myers Briggs Type Indicator (MBTI) or the MMPI, but the most used are tests based on the Five Factor Model such as the Revised NEO Personality Inventory. Personality computing can be considered as an extension or complement of Affective computing, where the former focuses on personality traits and the latter on affective states. A further extension of the two fields is Character Computing which combines various character states and traits including but not limited to personality and affect. == History == Personality computing began around 2005 with the pioneering research in personality recognition by Shlomo Argamon and later by François Mairesse. These works showed that personality traits could be inferred with reasonable accuracy from text, such as blogs, self-presentations, and email addresses. In 2008, the concept of "portable personality" for the distributed management of personality profiles has been developed. A few years later, research began in personality recognition and perception from multimodal and social signals, such as recorded meetings and voice calls. In the 2010s, the research focused mainly on personality recognition and perception from social media, helped by the first workshops organized by Fabio Celli. In particular personality was extracted from Facebook, Twitter and Instagram. In the same years, automatic personality synthesis helped improve the coherence of simulated behavior in virtual agents. Scientific works by Michal Kosinski demonstrated the validity of Personality Computing from different digital footprints, in particular from user preferences such as Facebook page likes, showed that machines can recognize personality better than humans and raised a warning against Cambridge Analytica and misuse of this kind of technology. == Applications == Personality computing techniques, in particular personality recognition and perception, have applications in Social media marketing, where they can help reducing the cost of advertising campaigns through psychological targeting.
Digital transaction management
Digital transaction management (DTM) is a category of cloud services designed to digitally manage document-based transactions. DTM removes the friction inherent in transactions that involve people, documents, and data to create faster, easier, more convenient, and secure processes. DTM goes beyond content and document management to include e-signatures, authentication and non-repudiation; enabling co-browsing between the customer and the business; document transfer and certification; secure archiving that goes beyond records management; and a variety of meta-processes around managing electronic transactions and the documents associated with them. DTM standards are proposed and managed by the xDTM Standard Association Aragon Research has estimated that "by YE 2016, 70% of large enterprises will have a DTM initiative underway or fully implemented."