PROJECT PRELIMINARIES

* BSO - Business Systems Options
* CASE - Computer Aided Software Engineering
* CCTA - Central Computing and Telecommunications Agency
* COCOMO - Constructive Cost Model
* CPM - Critical Path Method
* DFD - Data Flow Diagram
* DFM - Data Flow Modelling
* ELH - Entity Life History
* EM - Entity/Event Modelling
* EV - Earned Value
* LDM - Logical Data Modelling
* LDS - Logical Data Structure
* MTA - Milestone Trend Analysis
* OGC - Office of Government Commerce
* PB - Project Board
* PERT - Program Evaluation and Review Technique
* PID - Project Initiation Document
* PM - Project Management
* PMBOK - Project Management Body of Knowledge
* PPR - Post Project Review
* PPRP - Post Project Review Plan
* PRINCE - Projects in Controlled Environments
* RUP - Rational Uni ed Process
* SSADM - Structured Systems Analysis and Design Methodology
* UML - Uni ed Modeling Language
* XP - eXtreme Programming....................

Best Practices

• Communication problems arising when a distributed team is developing software must be handled with special care. A kick-off meeting must be held face-to-face, and all the developers, partners, and contractors must attend. All product deliverables must be clearly defined in the very beginning. After this the communication between team members is
mostly electronic. Time zones differences are not necessarily a problem on the contrary, they may turn out to be an advantage, since by the time one group of developers comes to work in the morning, the testers may have already sent them the test results from the other side of the Globe! Some overlap in working hours is, however, desirable. Establishing availability standards (when and how the team members will be available for communication, how quickly they respond to emails, and so on) facilitates electronic communication in software development done by distributed teams.

• Top-down approach to software analysis and design should be enforced in software development projects when the application domain is numerically intensive, such as signal processing, pattern recognition, and real-time control. The reason is that in such applications the data are not predictable enough, and developers are usually not familiar enough with
the data. For example, if object-oriented design is used in developing such an application, then more general classes (located close to the top of the inheritance tree) should be designed first, and design of their children classes should come next. Contrary to that practice, developing a
business-oriented application (an information system) suggests bottom-up approach. Developers of such applications usually know their data well, and it is quite natural to start the projects from modeling data to be stored in databases. As for the top-down approach to analysis and design, note also that it may inhibit reuse. It may be more economical to look at what reuse and COTS (components-of-the-shelf) software components are available, and select a design based on them. Such a system may not fully meet a client's needs, but the client may be happy to accept it on the basis of its greatly lower cost.

• Productivity of a newly assembled development team should be calibrated in a pilot project. A small pilot project gives project manager the possibility of gaining a rough model of performance for every team member and for the team as a whole before the real work on a large
application begins. Put simply, the work on a pilot project can give a multiplier factor m, so that if a certain team member estimates to take n weeks to do something, in reality he/she will need m times n weeks. This is important for schedule planning for the larger project. How trustworthy
and realistic is the multiplier factor acquired that way depends to a large extent on whether the application domains of the pilot project and the larger application are the same or not and whether the team member(s) is (are) familiar with the domain(s) or not.......................

Software Standards

There are two major aspects of the term ``standards" in software development. One of them is that of using widely accepted standards under the assumption that they embody the common body of knowledge and accepted state of industry best practice. Such standards include universally recognized control frameworks for software process control and improvement. Some examples include ISO 9000, ISO 12207, TickIt, and CMM. They provide a basis for defining systematic activities, roles, and tasks that can be carried out in software development, independent of individual projects, companies, or designers. Furthermore, they make possible to understand and manage all of the diverse forms of software activity from the standpoint of a single framework. Software project managers should understand and apply these standards and frameworks as points of reference in software development, in order to ensure that quality is
being designed and built into the products.
The ISO 9000 series of standards provide a generic model for the Quality Management System (QMS) of a supplier organization that is involved in design and development activities. It specifies the requirements against which the organization’s QMS can be formally assessed. ISO 9000’s issue of particular interest for software industry is ISO 9000-3 Guideline for the Application of ISO 9001 to the Development, Supply and Maintenance of Software.
The ISO 12207 standard covers the entire lifecycle of software, from inception through extinction. It details processes for acquiring and supplying software products and services
TickIt is the standard related to ISO 9000-3. Its purpose is to fill in the gaps and clarify the relationship between ISO 9000-3 and ordinary software development operations. It does this by adding additional documentation and audit requirements to the ISO 9000-3 Guidelines, and by providing direction needed to implement ISO 9000-3 compliant quality system.
Software Engineering Institute’s Capability Maturity Model (CMM), described in the Organizational aspects section does not have a formal status; hence it is called a model, or a framework, rather than a standard. It is used as a reference to establish the maturity level of an organization's software processes. The other aspect of the term ``standards" in software development is that of deploying organizational standards across the life of a project. In large
organizations, having many software development teams, some standardization of methods across teams is important. For example, an organization may prescribe standard (consistent) processes, roles, schedules, and reusability policies across teams and projects. It can lead to many benefits, including better planning, more predictable outcomes, increased staffing flexibility (decreased sensitivity to employee turnover), and reuse of experience..........................