Processes

The project development stages[19] Traditionally, project management includes a number of elements: four to five process groups, and a control system. Regardless of the methodology or terminology used, the same basic project management processes will be used. Major process groups generally include:[20]

initiation planning or development production or execution monitoring and controlling closing

In project environments with a significant exploratory element (e.g., research and development), these stages may be supplemented with decision points (go/no go decisions) at which the project's continuation is debated and decided. An example is the stage-gate model.

[edit] Initiating

Initiating process group processes[19] The initiating processes determine the nature and scope of the project.[21] If this stage is not performed well, it is unlikely that the project will be successful in meeting the business needs. The key project controls needed here are an understanding of the business environment and

making sure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them. The initiating stage should include a plan that encompasses the following areas:

analyzing the business needs/requirements in measurable goals reviewing of the current operations financial analysis of the costs and benefits including a budget stakeholder analysis, including users, and support personnel for the project project charter including costs, tasks, deliverables, and schedule

[edit] Planning and design

After the initiation stage, the project is planned to an appropriate level of detail (see example of a flow-chart).[19] The main purpose is to plan time, cost and resources adequately to estimate the work needed and to effectively manage risk during project execution. As with the Initiation process group, a failure to adequately plan greatly reduces the project's chances of successfully accomplishing its goals. Project planning generally consists of[22]

determining how to plan (e.g. by level of detail or rolling wave); developing the scope statement; selecting the planning team; identifying deliverables and creating the work breakdown structure; identifying the activities needed to complete those deliverables and networking the activities in their logical sequence; estimating the resource requirements for the activities; estimating time and cost for activities; developing the schedule; developing the budget; risk planning; gaining formal approval to begin work.

Additional processes, such as planning for communications and for scope management, identifying roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting are also generally advisable. For new product development projects, conceptual design of the operation of the final product may be performed concurrent with the project planning activities, and may help to inform the planning team when identifying deliverables and planning activities.

[edit] Executing

Executing process group processes[19] Executing consists of the processes used to complete the work defined in the project plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan and other frameworks that might be applicable to the type of project at hand.

[edit] Monitoring and controlling

Monitoring and controlling process group processes[19] Monitoring and controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project. The key benefit is that project performance is observed and measured regularly to identify variances from the project management plan. Monitoring and controlling includes:[23]

Measuring the ongoing project activities ('where we are'); Monitoring the project variables (cost, effort, scope, etc.) against the project management plan and the project performance baseline (where we should be);

Identify corrective actions to address issues and risks properly (How can we get on track again); Influencing the factors that could circumvent integrated change control so only approved changes are implemented

In multi-phase projects, the monitoring and control process also provides feedback between project phases, in order to implement corrective or preventive actions to bring the project into compliance with the project management plan. Project maintenance is an ongoing process, and it includes:[20]

Continuing support of end-users Correction of errors Updates of the software over time

Monitoring and controlling cycle In this stage, auditors should pay attention to how effectively and quickly user problems are resolved. Over the course of any construction project, the work scope may change. Change is a normal and expected part of the construction process. Changes can be the result of necessary design modifications, differing site conditions, material availability, contractor-requested changes, value engineering and impacts from third parties, to name a few. Beyond executing the change in the field, the change normally needs to be documented to show what was actually constructed. This is referred to as change management. Hence, the owner usually requires a final record to show all changes or, more specifically, any change that modifies the tangible portions of the finished work. The record is made on the contract documents usually, but not necessarily limited to, the design drawings. The end product of this effort is what the industry terms as-built drawings, or more simply, as built. The requirement for providing them is a norm in construction contracts. When changes are introduced to the project, the viability of the project has to be re-assessed. It is important not to lose sight of the initial goals and targets of the projects. When the changes accumulate, the forecasted result may not justify the original proposed investment in the project.

[edit] Closing

Closing process group processes.[19] Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned. This phase consists of:[20]

Project close: Finalize all activities across all of the process groups to formally close the project or a project phase Contract closure: Complete and settle each contract (including the resolution of any open items) and close each contract applicable to the project or project phase.

[edit] Project controlling and project control systems

Project controlling should be established as an independent function in project management. It implements verification and controlling function during the processing of a project in order to reinforce the defined performance and formal goals.[24] The tasks of project controlling are also:

the creation of infrastructure for the supply of the right information and its update the establishment of a way to communicate disparities of project parameters the development of project information technology based on an intranet or the determination of a project key performance index system (KPI) divergence analyses and generation of proposals for potential project regulations[25] the establishment of methods to accomplish an appropriate the project structure, project workflow organization, project control and governance creation of transparency among the project parameters[26]

Fulfillment and implementation of these tasks can be achieved by applying specific methods and instruments of project controlling. The following methods of project controlling can be applied:

investment analysis costbenefit analyses value benefit Analysis expert surveys simulation calculations risk-profile analyses surcharge calculations milestone trend analysis cost trend analysis target/actual-comparison[27]

Project control is that element of a project that keeps it on-track, on-time and within budget.[23] Project control begins early in the project with planning and ends late in the project with postimplementation review, having a thorough involvement of each step in the process. Each project should be assessed for the appropriate level of control needed: too much control is too time consuming, too little control is very risky. If project control is not implemented correctly, the cost to the business should be clarified in terms of errors, fixes, and additional audit fees. Control systems are needed for cost, risk, quality, communication, time, change, procurement, and human resources. In addition, auditors should consider how important the projects are to the financial statements, how reliant the stakeholders are on controls, and how many controls exist. Auditors should review the development process and procedures for how they are implemented. The process of development and the quality of the final product may also be assessed if needed or requested. A business may want the auditing firm to be involved throughout the process to catch problems earlier on so that they can be fixed more easily. An auditor can serve as a controls consultant as part of the development team or as an independent auditor as part of an audit. Businesses sometimes use formal systems development processes. These help assure that systems are developed successfully. A formal process is more effective in creating strong controls, and auditors should review this process to confirm that it is well designed and is followed in practice. A good formal systems development plan outlines:

A strategy to align development with the organizations broader objectives Standards for new systems Project management policies for timing and budgeting Procedures describing the process Evaluation of quality of change

Software prototyping

Software prototyping, refers to the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

A prototype typically simulates only a few aspects of the final solution, and may be completely different from the final product. Prototyping has several benefits: The software designer and implementer can get valuable feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in the prototyping have been in development and debate since its proposal in the early 1970s.[6]

Types of prototyping
Software prototyping has many variants. However, all the methods are in some way based on two major types of prototyping: Throwaway Prototyping and Evolutionary Prototyping.

[edit] Throwaway prototyping

Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system. Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements.[7] The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded. Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work. it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements, and the subsequent construction of a valid and usable system from the user's perspective via conventional software development models. [8] Prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance, interaction and timing. One method of creating a low fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not look at all like it. Another method to

easily build high fidelity Throwaway Prototypes is to use a GUI Builder and create a click dummy, a prototype that looks like the goal system, but does not provide any functionality. Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the usage of storyboards, animatics or drawings. These are non-functional implementations but show how the system will look. SUMMARY:-In this approach the prototype is constructed with the idea that it will be discarded and the final system will be built from scratch. The steps in this approach are: 1. 2. 3. 4. 5. 6. Write preliminary requirements Design the prototype User experiences/uses the prototype, specifies new requirements Repeat if necessary Write the final requirements Develop the real products

[edit] Evolutionary prototyping

Evolutionary Prototyping (also known as breadboard prototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built. When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt. "evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood."[5] This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase. For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment changeswe often try to define a system using our most familiar frame of reference--where we are now. We make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered.[9] Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.

"It is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed versionThe user may decide that a 'flawed' system is better than no system at all."[7] In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system. To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest.[10]

[edit] Incremental prototyping

The final product is built as separate prototypes. At the end the separate prototypes are merged in an overall design.

[edit] Extreme prototyping

Extreme Prototyping as a development process is used especially for developing web applications. Basically, it breaks down web development into three phases, each one based on the preceding one. The first phase is a static prototype that consists mainly of HTML pages. In the second phase, the screens are programmed and fully functional using a simulated services layer. In the third phase the services are implemented. The process is called Extreme Prototyping to draw attention to the second phase of the process, where a fully functional UI is developed with very little regard to the services other than their contract.

Component Reliability Importance in System Reliability Analysis

Once the reliability of a system has been determined, engineers are often faced with the task of identifying the component(s) that cause the most problems to the system in order to prioritize improvements in the design and channel resources and efforts of system improvement to the areas that will have the most impact on the system's performance. In simple systems such as a series system, it is easy to identify the weak components. In more complex systems, however, this becomes quite a difficult task. Identifying the weakest component is an exercise that is based on understanding both the reliability of each component and the roles the components play reliability-wise in the system, which is determined by their location in the reliability block diagram (RBD). For complex systems, the analyst needs a mathematical approach that will provide the means of identifying and quantifying the importance of each component in the system. (Note: the cost of improving the reliability of the component is not considered. Cost of improvement is covered in the Reliability Allocation section of the online Life Data Analysis Reference.) In this article, BlockSim is used to generate plots that assist in understanding the reliability importance of each component in the analyzed system.

Using reliability importance measures is one method of identifying the relative importance of each component in a system with respect to the overall reliability of the system. The reliability importance, IR, of component i in a system of n components is given by Leemis [1].

Eqn. (1) Where: Rs is the system reliability Ri is the component reliability

CASE
CASE (computer-aided software engineering) is the use of a computer-assisted method to organize and control the development of software, especially on large, complex projects involving many software components and people. Using CASE allows designers, code writers, testers, planners, and managers to share a common view of where a project stands at each stage of development. CASE helps ensure a disciplined, check-pointed process. A CASE tool may portray progress (or lack of it) graphically. It may also serve as a repository for or be linked to document and program libraries containing the project's business plans, design requirements, design specifications, detailed code specifications, the code units, test cases and results, and marketing and service plans.

CASE originated in the 1970s when computer companies were beginning to borrow ideas from the hardware manufacturing process and apply them to software development (which generally has been viewed as an insufficiently disciplined process). Some CASE tools supported the concepts of structured programming and similar organized development methods. More recently, CASE tools have had to encompass or accommodate visual programming tools and object-oriented programming. In corporations, a CASE tool may be part of a spectrum of processes designed to ensure quality in what is developed. (Many companies have their processes audited and certified as being in conformance with the ISO 9000 standard.)

Various Object ModelsA structural (static) object model defines the static structure of the system by defining classes and their associations with each other. The structural (static) object model is defined using class diagrams. A behavioural (dynamic) object model defines the time-dependent structure of the system by defining objects and their interactions with each other. The behavioural (dynamic) object model is defined using sequence diagrams, also known as message trace diagrams, collaboration diagrams, also known as object message diagrams, and state transition diagrams. The structural (static) and behavioural (dynamic) models for a given system are interdependent. The behavioural (dynamic) model expresses

system behaviour, showing how the system effects required behaviour. The structural (static) model provides the infrastructure upon which behavioural (dynamic) models are built. The behavioural (dynamic) model describes the sequences of messages that allow collaborating objects to communicate, while the structural (static) model describes the communication paths that those messages use.