Project Management Software

PROJECT PRELIMINARIES

2008-10-08T03:41:00.001-07:00

* 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

2008-10-03T14:15:00.000-07:00

• 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

2008-09-23T19:06:00.000-07:00

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..........................

Software Configuration Management

2008-09-14T13:51:00.000-07:00

The configuration of a software system is the function and/or physical characteristics of hardware, firmware, software or a combination thereof as set forth in technical documentation and achieved in a product.It can also be thought of as a collection of specific versions of hardware, firmware, or software items combined according to specific build procedures to accomplish a particular purpose.
Software configuration management (SCM) comprises a set of technical, managerial, and administrative activities related to identifying the configuration of a software system at distinct points in time for the purpose of systematically controlling changes to the configuration, recording and reporting change processing and implementation status, verifying compliance with specified requirements, and maintaining the integrity and traceability of the configuration
throughout the system life cycle. Responsibilities of each software project manager related to SCM include enforcing the practice of SCM activities for the project, distributing the activities to the relevant individuals, and managing and administrating the results of these activities.
Since SCM is a supporting lifecycle process to software product development and maintenance, a successful SCM implementation requires careful management and planning.
These are typically performed by the project manager or another designated individual, who does it in close relation with SQA activities. Management and planning activities cover all the other sets of activities,establish all the relevant SCM policies, and result in recording/updating the Software Configuration Management Plan (SCMP) for the project. The SCMP is typically subject to SQA review and audit.
Configuration identification activities provide the basis for other SCM activities. These activities enumerate the configuration items to be controlled(such as plans, specifications, source and executable code, code libraries, data and data dictionaries, testing materials, software tools, and documentation for installation, maintenance, operations and software use), establish identification schemes for the items and their versions, and establish the tools and techniques
to be used in acquiring and managing controlled items.
SCM control activities involve both managers and developers. Managers make decisions on whether some changes in configuration should be made or not, and authorize the changes. Developers perform change activities (code management) in a coordinated manner. Status reports are generated that account for each change in the configuration, and can be of use to various parties in the project, including managers, developers, testers, SQA team members, and
maintenance engineers. The information obtained by status accounting can also serve as a basis for various measurements, such as the number of change requests per software configuration item and the average time needed to implement a change request. Release processing activities support customers and the maintenance team. They are related to identification.
Packaging and delivery of the elements of a product (such as the software, its documentation, release notes, and configuration data), as well as product version management (versions for different platforms or versions with varying capabilities). The software configuration auditing activity determines the extent to which an item satisfies the required functional and physical characteristics. Its ultimate goal is to evaluate the conformance of software products and processes to applicable regulations, standards, guidelines, plans, and procedures.

Software Quality Assurance

2008-09-08T06:46:00.000-07:00

The goals of software quality assurance (SQA) are monitoring the software and its development process, ensuring compliance with standards and procedures, and ensuring that product, process, and standards defects are visible to management.
Quality is the operational behavior of a product required by its users. It comprises a set of product characteristics, both external and internal. External quality characteristics are related to how the product works in its environment (e.g., usability and reliability). Internal quality characteristics reflect how the product is developed (characteristics such as structural complexity, size, test coverage, and fault rates). Important factors affecting product’s quality
characteristics are process maturity level of the company that has developed the software product, its development environment (such as the design methodology and CASE tools used), and the development team’s skill and experience.
It is desirable for a software development organization to plan and control product quality during development. Projects managers cannot allow the luxury of going back and adding quality by the time a quality problem is detected, it is probably too late to fix it. For that reason, it is necessary to establish procedures and expectations for high levels of quality before any other
development begins. Also, hiring developers proven to develop high-quality code, staffing the project accordingly, and enforcing peer-level code reviews and external reviews must be top priority of every software project management.

• Establishing targets for the external quality characteristics.
• Pursuing those targets during development by defining and monitoring targets for internal quality characteristics - this can be done using conventional software measures of size, fault rates, change rates, structure, test coverage, and so on, taken early in product development.
• Establishing relationships between internal and external quality characteristics, using experience from similar past software development projects.
• Identifying and setting targets for internal quality characteristics.In practice, all this can be done by first defining a quality model (in terms of measurable quality characteristics; it can be an international standard like ISO 9126, or a company-specific model), and then applying a quality process.
Quality process includes quality specification (establishing the software product’s quality requirements), planning (deciding on a suitable development process and setting target values for measurable internal quality characteristics),control (monitoring progress throughout development using internal software measures associated with deliverables and activities related to each major review point in development), and evaluation (measuring the actual values of the
external quality characteristics and comparing each actual value with its target value). Maintaining and using a database of past projects helps perform each step in the process more successfully....................

Software Testing

2008-09-03T17:50:00.000-07:00

In spite of the fact that in every software development project the product undergoes testing, delivered software always contains residual defects. Software testing is a difficult, time-consuming process. It requires specific skills from software testers, skills that only partially overlap with those of software developers. Apart from mastering coding, testers must also possess a great deal of knowledge of formal languages, graph theory and algorithms.

• Modeling the software’s environment
• Selecting test scenarios
• Running and evaluating test scenarios
• Measuring testing progress

In the first phase, the tester’s task is to simulate the interaction between the application and its environment, be it the user or the other applications, taking into account all possible inputs and outputs that can cross the application’s boundaries. The hardest part here is the fact that in many cases the interactions can go through numerous different file formats, communication protocols, GUIs, and file systems. The other hard part is the unpredictability of the user’s actions the software under test must account for that. Since the number of possible test scenarios is usually extremely large, testers should select those scenarios that cover all code statements and all significant representatives of external events. Before running the selected scenarios, it is necessary to convert them into executable form (often as code) in order to
simulate typical interactions between the system and the external world. Applying test scenarios manually is labor-intensive and error-prone. For that reason, testers try to automate the test scenarios as much as possible. In many environments, automated application of inputs through code that simulates users is possible, and tools are available to help.

Measuring testing progress is difficult, simply because it is not just counting the numbers of bugs found. As stated in the section on software metrics, specific metrics for software testing are used to measure the coverage of the tests applied (in terms of running all lines of the source code, forcing all the internal data to be initialized and used, applying all test scenarios, exploring all the inputs, and checking for functional completeness). Note also that software reliability
engineering can greatly help - the Cleanroom methodology developed at IBM has been particularly useful in improving software quality and providing a quantitative measure for the quality of a software product at its release. TheCleanroom approach provides for the transition of process technology to the project staff and integrates several proven software-engineering practices into one methodology. The testing strategy of the Cleanroom methodology can
be best described as random sample based on usage model that predicts field reliability, rather than a futile attempt for coverage and little insight on field reliability.

If the Unified Process is used to manage software development, software testing is performed in every iteration. Test scenarios are defined from use cases, and comprise both functionality and performance testing. The advantage of this incremental and iterative approach to software testing is that in each iteration the testers test just some of the application. Moreover, the tests performed in early phases usually discover such bugs and faults that would
cause more severe instability in the project’s rhythm if they were discovered in later phases. In every iteration, tests also check whether the current iteration has jeopardized some of the previously built and tested architecture. If the project’s size is large, it is impractical to manually run all the test cases, so the use of automated testing tools is recommended. Project managers should adopt the practice of enforcing thorough testing in every iteration, and not allowing the
next iteration to begin before all the tests planned in the current iteration are completed. The entire project is considered completed only when all the UML models and all the tests are completed and delivered.

Software Metrics

2008-08-23T17:35:00.000-07:00

Measurement is a key factor for managing and improving software development. The purpose of the measurement process in software projects is to define and operate a context-specific set of metrics, and to describe the required guidelines and procedures for data collection and analysis. Software measurement generates quantitative descriptions of key processes and products, enabling us to understand behavior and result. Such descriptions can indicate the effort needed to complete the project, the product’s quality, estimated schedules and time-to-market, rework effort, estimated project costs, and distribution of resources and costs by project phases. Software measurement makes possible to compare the project a development team is currently working on, to similar projects in terms of budget, costs, productivity, quality, staffing, development processes, and technology used.

In order to operate a metrics program during a software development project, the project manager must enforce continuous measurement of relevant factors. These factors depend on the overall management goals of the measurement process. In that sense, one can differentiate between the following kinds of software metrics.

* Metrics for project size and team productivity – typical and most widely used representatives of this kind of metrics are source lines of code (SLOC) and function points; the SLOC metric can be converted relatively accurately and easily into the number of programer-months needed to
complete the project; function points are dimensionless numbers that indicate the application’s functionality from the user’s perspective, and can also be easily converted into the effort needed to complete the project or one of its parts.

* Metrics for schedules – these include the number of tasks completed on time, the number of tasks not completed on time, the number of tasks with changed schedules, and the number of postponed tasks.

* Metrics for requirements specification – the number of requests for change (RFC) in specification, the number of new requirements, and the RFC diagram (showing the dynamics of RFC over time).

* Metrics for software testing – these metrics are used to track the percentage of SLOC covered by the testing process; increasing that percentage reduces the number of errors to be discovered by the users and increases the product’s quality.

* Metrics for software quality – they typically show the fault density (the number of errors per 1 KSLOC) and fault arrival and closing rates, as a rule of thumb, the product’s quality is satisfactory if the fault density is lower than 0.25.

* Metrics for project risk – they measure confidence in the product’s readyto- deployment date (typically an S-shaped curve over time). The most widely used metrics models include COCOMO, which isbased on measuring SLOC, function points analysis, GQM(Goal-Question-Metrics, based on systematic translation of the company’s goals into the measurement process goals, and refinement by defining the concrete measurements to perform in order to support the goals), and Chidamber-Kemerer’s metrics suite for object-oriented software projects (specifying metrics for the number of methods per class, depth of inheritance tree...............

Risk Assessment

2008-08-12T16:25:00.000-07:00

• Estimating the project's size in the early phases - the project's size affects how the deadlines will be set up, and is positively correlated with monetary expense and risk.
• Setting up the deadlines realistically - as a result, the necessary time to establish the rhythm of the project, prevent delays, and enter a steady state in which the effort is equally distributed from the beginning of the project, without putting an extra workload to the team members at the end of the project phases.
• Collecting and studying reports on other similar projects - this provides the possibility of learning from the other projects' and other teams' experiences; in that sense, a process data base is essential for an organization that wants to go higher than Level 2 on the CMM level ladder, engineering management depends on measurements, and their proper use, and this data base is to be regarded as an organizational asset and it is to be properly managed.
• Top management commitment - if top management does not play a strong,active role in the project from initiation through implementation, then allother risks and issues may be impossible to address in a timely manner.
• Failure to gain user commitment - when the users are actively involved inthe requirements determination process, it creates a sense of ownership,thereby minimizing the risk that the end-user expectations will not be metand that the system will be rejected.
• Timeliness of additional user requirements - it is essential to have the usersinvolved in the development process from the beginning to the end;however, it is highly preferable to have the requirements frozen at acertain point in development.
• Familiarity with technology - the higher the organization’s experience with application languages, technology databases, hardware, and operating systems, the lower the risk in the project.
• Insufficient/inappropriate staffing - the risk of failing to provide adequate staffing throughout the project can be mitigated by using disciplined development processes and methodologies to break the project down into manageable chunks, and developing contingency plans.
• The degree of structure in the project's outputs - it is negatively correlated with the risk in the project.

In the context of the Unified Process of software development, it is adopted that one can never fully eliminate risks; at best, one can manage them.For that reason, the Unified Process stresses the need to drive software development as an architecture-centric activity. Architecture-centric approach forces the risk factors to emerge early in the development process and make the process simultaneously risk-driven - when the risk factors are identified early, managers can take steps to mitigate them. Experienced software project managers recommend to maintain a running list of project's top ten risk factors and use that list to drive each release..............

Management Strategies and Techniques

2008-08-03T17:38:00.000-07:00

Software development is an extremely dynamic and fluid business, and it is difficult to plan everything at the beginning of a project. Therefore, efficient management of software projects must be based on some explicit, strategic goals and organization's interests.

• Balancing the need for structure and process control in software development with the need for flexibility, informality, and more effective communication processes.
• Establishing software measurement programs and and enfocing accountability for completion of software development milestones.
• Making management objectives and product vision clear to the development team members (this is very importnt in practice, because far too often developers are in total ignorance of the broader strategy of a company, and the tactical decisions made by management to advance this
strategy seem to them arbitrary and even hostile).
• Identifying the most critical issues of the project and stressing the need to allocate most development resources, time, and efforts to such issues.
• Organizing more visible and formal management processes for reviewing and approving potential product enhancements.
• Emphasizing management approaches that facilitate flexibility and
creativity within clearly defined boundaries.
• Keeping-up with technological developments by enforcing life-long learning, training, courses, and seminars.
• Developing more globally focused, culturally sensitive management capabilities.
• Involving end-users in the development process in order to constantly provide advice on using the product in the real world, thus eliminating the customer-developer gap.
• Emphasizing progress review mechanisms across the development effort.
• Applying mechanisms of recognizing, rewarding, and leveraging extraordinary efforts and/or hyperproductivity, as an avenue to promote and retain key technological leaders.
• Adapting the software development process to the characteristics of the product being developed.
• Increasing parallelism in product development by reducing linear, sequential activities, encouraging relevant communication and social interactions among the team members, and changing the work modes when necessary.
• Insisting on creating multiple design views, such as structural, functional, object-oriented, event-based, and data-flow; although sometimes redundant, multiple design views help cover design from multiple perspectives and make it more complete and more efficient.
• Enforcing the feedback mechanism in the development process, in order to
detect inconsistencies in design as early as possible and reduce the costs
of fixing them...............

Organizational Aspects

2008-07-24T16:11:00.000-07:00

Software project management always involves various organizational aspects, such as creating and staffing development teams, assigning roles to the team members, modalities of software development, leadership considerations,interpersonal communication at work, staff training and embracing new technologies, organization's culture, social and ethical issues. Organizational aspects of software development are crucial for all successful projects. They are neither about hardware nor about software - they are about ``peopleware", i.e. about using, coordinating, and managing human resources in an organization effectively. In the context of fast-paced and extremely fluid dynamics of software industry, the key to success or failure of
software project is the way it is organized and managed.

The principle of hierarchy implies a strict pyramid of leadership, roles, duties, and tasks in the organization, with strict adherence to the organization's internal rules. Drifting away from the predefined overall course of the organization is interpreted as a lack of loyality that may lead to the organization's instability, and is not tolerated. On the opposite end of the same dimensionis the principle of independence. It relies on the individuals' initiative and individuality in doing
their jobs, directing their work, and to an extent even in decision making. Organizations that adopt this principle are usually open to innovation and changes, new technologies, and creative autonomy of their members.

* Flexible rotation of key roles and tasks (e.g., system design, integration,testing, code inspection) in the project team.
* Maintaining a catalogue that specifies all key roles and responsibilities.
* The role of the project leader(s) is focused mostly on project management and system design, and much less on coding and testing.
* The project leader should have a small board of project advisors who set the project goals prepare status reports on intermediate stages of development, care about resource management, monitor the project dynamics and stability, and suggest how to better staff the project.
* Decision making should be based on consensus among the team members whenever possible failing to allow for that may cause lacking of the sense of contribution to the project ultimate goal among those team members whose voice is never heard.
* Project manager's awareness of the staffing profile corresponding to the development process being applied is very important; for example, in object-oriented development processes it is necessary to have a chief architect throughout the development project however, the number and efforts of system analysts and application engineers necessary to complete the tasks is rather small in the early phases, and increases significantly in the later phases of the project.
* Planning transition to another development process or another technology should include an appropriate training of the development team members,mentoring and guidance among the team members in embracing the new technology, careful selection of new programming languages and tools,and strategic decisions related to software reuse.
* Effective interpersonal communication is essential to a project’s success, hence facilitating communication between team members should be a top priority for the project manager; this may include careful pairing of staff members and assigning a mediating duty to some other members according to their experience and technical background.
* Every software project manager should pay adequate attention to a number of ethical issues that always affect the project's success, the development team, and the team's relations to the customers such issues include acting in the customer's and public interest, maintaining integrity
and independence in professional judgement, adhering constantly to the highest professional standards possible..........

Software Architecture

2008-07-19T16:40:00.000-07:00

Software architecture encompasses specification and design of the application's global structure, leaving the details aside. It is related to the general software organization in terms of its components and connectors. Components are things like modules, compilation units, objects, and files. Connectors define interactions among components through procedure calls, parameters of initialization, instructions for the linker.

Defining the architecture of a software system involves the choice of architectural style. Each architectural style defines a family of software systems organized in a similar way, the corresponding vocabulary of components and connectors, constraints in using the components and connectors in building the system according to that style, and the way the overall system behavior depends on the behavior of its components. Examples of software architectural styles
include layered architectures, pipeline architecture, object-oriented architecture, event-based architecture, repository-based architecture, component-based systems (CBS) architectures, process-control architectures, real-time architectures, and various heterogeneous and Internet-based architectures.

As soon as the initial set of requirements is gathered, the project manager should direct the chief architect and some other engineers to define the initial software architecture of the system to be developed. Software architecture definition does not get sealed after the project begins. On the contrary, it is an evolving activity that continues through all the phases of the product's lifecycle. It interweaves with requirements specification, domain analysis, study of
possibilities for reuse, and even design.

Selecting an architectural style and evolving the software architecture is far from being simple, because it involves many issues other than just the system's overall structure. Project managers must be aware of such issues. The issues include the platform the system is to run on (e.g., the hardware architecture,operating system, database management system, and network protocols), global control structures, data communication, synchronization, and access protocols,
reusable building blocks available, deployment considerations, legacy systems,the choice among multiple design alternatives, assignment of functions to modules and subsystems, the system's functionality, scalability, reliability, and usability, its comprehension and resilience to changes, and also its esthetical considerations.

Requirements Engineering

2008-07-12T17:02:00.000-07:00

Almost all software development processes one way or another stress requirements analysis and specification as one of their core workflows. The reasons are simple. It is necessary to manage requirements as well as possible because a small change to requirements can profoundly affect the project's cost and schedule, since their definition underlies all design and implementation. Unfortunately, in most practical projects it is not possible to freeze the requirements at the beginning of the project and not to change them. Requirements develop over time, and their development is a learning process, rather than a gathering one. The intended result of this process is a structured but evolving set of agreed, well understood, and carefully documented requirements.This implies the need for requirements traceability the ability to describe and follow the life of a requirement, in both a forward and backward
direction, ideally through the whole system's life cycle.

The importance of constantly involving the users in the process of requirements analysis and specifications cannot be overemphasized. Only the users know their domain properly, and for that reason they should certainly participate in defining the system's functions, designing them, and evaluating their implementation and testing. The users should also participate in creating, verifying, and updating the requirements specification document for the project. The users should share with the developers the responsibility for the requirements' completeness and consistency. It is the project managers' duty to establish and maintain good relations with the users throughout the development process, as well as to consult them whenever the project gets stuck due to the development team's lack of domain understanding.
There is a wide spectrum of techniques for requirements engineering. Whatever technique is applied, it is always desirable to involve the user to increase the correctness of the requirements specification.

Some of the techniques are:
• structured interviews and questionnaires that the user fills in inquirybased requirements gathering.
• diagram-based requirements analysis using multiple diagrams to sketch relevant parts of the user's work process and describe the requirements graphically.
• using metaphors of the user's work process the office metaphor, or the agent/agency metaphor.
• scenario analysis scenario is a typical sequence of activities characterizing the user's work process, hence it reflects what the user will do with the system and helps define the test procedures.
• using special-purpose software tools for requirements gathering some of them can be simulation-based.
• requirements completeness and consistency checks some of them can be automated, others must be performed manually.
• using special-purpose requirements-specification languages in order to describe requirements more formally and hence provide more automated requirements tracing.
• prototype system development, in order to make the requirements clear and to establish better mutual understanding with the users.
• analyzing videotaped user's work process. When managing software development according to the Unified Process, requirements are captured mostly through the use cases and use-case diagrams. A use case can be described as a specific way of using the system from a user’s perspective .

Software Development Process

2008-07-08T11:22:00.000-07:00

One of the primary duties of the manager of a software development project is to ensure that all of the project activities follow a certain predefined process, that the activities are organized as a series of actions conducing to a desirable end . The activities are usually organized in distinct phases, and the process specifies what artifacts should be developed and delivered in each phase. For a software development team, conforming to a certain process means complying
with an appropriate order of actions or operations. For the project manager, the process provides means for control and guidance of the individual team members and the team as a whole, as it offers criteria for tracing and evaluation of the project's deliverables and activities.

Software development process encompasses many different tasks, such as domain analysis and development planning, requirements specification, software design, implementation and testing, as well as software maintenance. Hence it is no surprise at all that a number of software development processes exist. Generally, processes vary with the project’s goals (such as time to market, minimum cost, higher quality and customer satisfaction), available resources the company’s size, the number, knowledge, and experience of people both engineers and support personnel and hardware resources and application domain.

However, every software developer and manager should note that processes are very important. It is absolutely necessary to follow a certain predefined process in software development. It helps developers understand, evaluate, control, learn, communicate, improve, predict, and certify their work. Since processes vary with the project's size, goals, and resources, as well as the level at which they are applied the organization level, the team level, or the
individual level , it is always important to define, measure, analyze, assess,
compare, document, and change different processes.

There are several well-known examples of software development processes. Each process relies on a certain model of software development. The first wellestablished and well documented software development process has followed the waterfall model. The model assumes that the process of software development proceeds through several phases in a more-or-less linear manner. There is not much feedback and returning to previous phases other than the one directly preceding the phase in focus. In other words, once a certain phase is finished it is considered closed, and the work proceeds with the next phase. Many developers have criticized the waterfall model for its rigidity in that sense, and for its failure to comply with the reality of everchanging requirements and technology. However, the waterfall model is at least partially present in most of the other models as well, simply because of its natural order of phases in software development.

Project Measurements

2008-07-05T04:01:00.000-07:00

Successful large projects are most often found in companies that have software measurement programs for capturing productivity and quality historical data , Thus any new project can be compared against similar projects to judge the validity of schedules, costs, quality, and other important factors. The most useful measurements for projects in the 10,000-
function point domain include measures of the following:

• Accumulated effort.
• Accumulated costs.
• Development productivity.
• Volume and rate of requirements changes.
• Defects by origin.
• Defect removal efficiency.

Measures of effort should be granular enough to support work breakdown structures. Cost measures should be complete and include development costs, contract costs, and costs associated with purchasingn or leasing packages. There is one area of ambiguity even for top companies
and successful projects: The overhead or burden rates established by companies vary widely. These variances can distort comparisons between companies, industries, and countries, and make benchmarking difficult. Of course, within a single company this is not an issue.

The federal government, some military projects, and the defense industry still perform measurements using the older lines-of-code metric. This metric is hazardous because it cannot be used for measuring many important activities such as requirements, design, documentation,
project management, quality assurance, and the like. There are also programming languages such as Visual Basic that have no effective rules for counting lines of code. About one third of the large software projects examined utilized several programming languages concurrently, and one large application included 12 different programming languages.

Measures of quality are powerful indicators of top-ranked software producers and are almost universal on successful projects. Projects that are likely to fail, or have failed, almost never measure quality. Quality measures include defect volumes by origin (i.e., requirements, design, code,bad fixes) and severity level, defect severity levels, and defect repair rates. really sophisticated companies and projects also measure defect removal efficiency. This requires accumulating all defects found during development and also after release to customers for a predetermined time period. For example, if a project finds 900 defects during development
and the users find 100 defects in the first three months of use, then it can be stated that the project achieved a 90 percent defect removal efficiency level. Of course, any defect found after the first three months lowers the defect removal value.

Project Cost Estimating

2008-07-03T11:46:00.000-07:00

Software cost estimating for large software projects is far too complex to be performed manually. This observation is supported by the presence of at least 75 comcommercial software cost estimating tools, including such well-known tools as COCOMO II, CostXpert, Knowledge- Plan, PRICE-S, SEER-SEM, SLIM, and the like. Successful projects all use at least one such tool, and usage of two or more is not uncommon. Estimates producedby trained estimating specialists are also noted on many successful large projects, but not on failing projects.

• Software estimating tools (COCOMO II, CostXpert, KnowledgePLAN, PRICE-S, SEER-SEM, SLIM, etc.).
• Formal sizing approaches for major deliverables based on function points.
• Comparison of estimates to historical data from similar projects. • Availability of trained estimating specialists or project managers.
• Inclusion of new and changing requirements in the estimate. • Inclusion of quality estimation as well as schedule and cost estimation.

Failing projects tend to understate the size of the work to be accomplished due to inadequate sizing approaches. Failing projects also omit quality estimates, which are a major omission since excessive defect levels slow down testing to a standstill. Overestimating productivity rates or assuming that productivity on a large system will be equal to productivity on small projects are other common reasons for cost and schedule overruns. The main problem with estimates for projects in the 10,000-function point size range is that they err on the side of excessive optimism. Project planning tools and project estimating tools overlap in functionality, and are usually marketed separately. Normally, the project planning and cost estimating tools pass information back and forth. The software cost estimating tool would be used for overall project sizing, resource estimating, and quality estimating. The project-planning tool would be used for critical path analysis, detailed scheduling, and for work breakdown structures.

Software Project Management

2008-07-03T07:23:00.000-07:00

Project Planning :
Effective project planning for large projects in large corporations involves both planning specialists and automated planning tools. Successful planning for large software projects involvesthe following.
• Using automated planning tools such as Artemis Views or Microsoft Project.• Developing complete work breakdown structures.
• Conducting critical path analysis of project development activities.• Considering staff hiring and turnover during the project.
• Considering subcontractors and international teams.
• Factoring in time for requirements gathering and analysis.
• Factoring in time for handling changing requirements.
• Factoring in time for a full suite of quality control activities.
• Considering multiple releases if requirements growth is significant.

Successful projects do planning very well indeed. Delayed or cancelled projects, however, almost always have planning failures. The most common planning failures include
(1) not dealing effectively with changing requirements;
(2) not anticipating staff hiring and turnover during the project;
(3) not allotting time for detailed requirements analysis;
(4) not allotting sufficient time for inspections, testing, and defect repairs.

Successful project planning tends to be highly automated. There are at least 50 commercial project-planning tools on the market, and successful projects all use at least one of these. Not only are the initial plans automated, but also any changes in requirements scope or external events will trigger updated plans to match the new assumptions. Such updates cannot be easilyaccomplished via manual methods; planning tools are a necessity for large software projects.