1. ISO/CEI 12207 standard. Definitions: Process, activity, task. Type of processes: Primary, support, organizational. Short description. ISO/CEI 12207: 1995 STANDARD The multitude and the complexity of the problems related to the development of a SW product implied the necessity of a systematical approach and standardization. The result was ISO/CEI 12207:1995 Standard having as main purpose to establish for SW industry: o A common framework o A well defined terminology 3.2 DEFINITIONS Definitions: In accordance with this standard a SW PROJECT consists in: (1) Processes – an assembly of resources and interdependent activities oriented to a well defined purpose. (2) Activities – are parts of a process consisting in types of actions through which, process resources are used for project purpose. (3) Tasks – are components of activities consisting in one or an assembly of actions o A task can be related with a person or a group of persons having the responsibility of their accomplishment o For any task must be established or estimate A resources allocation A time horizon A cost 3.3 TYPES OF PROCESSES (1) PRIMARY PROCESSSES (P) (2) SUPPORT PROCESSSES (S) (3) ORGANIZATIONAL PROCESSSES (O) 3.4 PRIMARY PROCESSSES PRIMARY PROCESSES are the processes deserving the main parts (actors) of a SW project: acquisition, supplier, developer, operator (user) and

maintainer of the product ISO/CEI 12207:1995 STANDARD defines 5 Primary Processes: (1) Acquisition Process – defines the activities through which an organization acquires a system, a product or a SW service (2) Supplying Process – defines the activities through which an organization supplies a system, a product or a SW service (3) Development Process – consists in activities through which an organization defines and elaborates a system, a product or a SW service (4) Utilization Process – defines the activities through which an organization utilizes a system, a product or a SW service (5) Maintenance Process – defines the activities through which an organization supplies maintenance service for a system, a product or a SW service 3.5 SUPPORT PROCESSES SUPPORT PROCESSES are processes which support other processes. They contribute to the success and the quality of a SW project. ISO/CEI 12207:1995 STANDARD defines 8 Support Processes: (1) Documentation Process – includes the activities concerning the definition and recording of all information resulted from the SW developing process. o That presumes user documentation as well as documents related to developing process: plans, reports, specifications, internal standards, associated documents, internal procedures. (2) SW Configuration Management Process (SCM) – consists in administrative and technical procedures which o Identify, define and establish the SW configuration elements (components, modules, units, files, data structures) o Control the storage, the handling and the delivery of the SW components o Establish product versions o Establish state of the components (functionalities, disfunctionalities, errors)

o Control the modifications on passing from a version to another (Control Versions Management) (3) Quality Assurance Process (QA) – defines the assembly of activities which assure in an objective manner that o The realized SW product fulfill the specified requirements o The implied processes comply with a set of established plans and procedures (4) Testing Process (*) – defines the assembly of activities having as purpose the verification of the products resulted from developing activities, which satisfy imposed requirements and conditions. o The verification has different degrees of depth depending on the activity whose product is tested (5) Validation Process (*) – defines the assembly of activities which verifies if a SW product which is in a final phase, satisfies the planned utilization requirements (covers the user’s needs resulted from the analyze process) (6) Common Analyze Process (*) – is the process of analyze/evaluation of the state of a process or product. o It’s a periodical process which involve the parts implied in project (usually the developer, the beneficiary and the purchaser or supplier) o It focuses on either the analyze of SW product requirements or the measurement of the “pulse” of the project (7) Audit Process (*) – contains the activities oriented to certify the conformity with norms, requirements, schedules, and statements of the contract for a product or a SW process. o In principle, these activities are similar with those realized by test, validation or analyze processes, with the following differences: o (1) They are accomplished during the development of the activity or task, and not at the end, as in the case of test or validation process o (2) The auditing part has no direct responsibilities in the implied products and processes, element that differentiates the auditing

process from the common analysis one. (8) Problems Solving Process (*) – includes activities concerning analyze and solving of the problems (non­conformities, functional errors, unexpected situations) Obs. The processes marked with (*) (Testing, Validation, Common Analyze, Audit, Problem Solving) can be utilized as techniques for the Quality Assurance Process 3.6 ORGANIZATIONAL PROCESSES ORGANIZATIONAL PROCESSES are processes related to the management, infrastructure, training, and improving ISO/CEI 12207:1995 STANDARD defines 4 Organizational Processes: (1) Management Process – defines the basic activities related to the management of any process (2) Infrastructure Process – consists in all the activities concerning establishing, achieving and maintaining the infrastructure of any process. o By infrastructure we mean hardware, software, tools, techniques, standards and facilities for development, exploitation and maintenance (3) Training Process – specifies the set of activities for training and maintaining the professional level of the personal. o The main effort is directed to improve the knowledge and to increase the qualification of the personal. (4) Improving Process – consists in the set of activities oriented to definition, evaluation, measurement, control and improvement of any process 2. The contract. The contract template. Types of contracts. The Contract It’s absolutely necessary. Half the horror stories about programming involve either bad contracts or no contract at all. A contract is an agreement between you and a customer that you will do a certain job within specific constraints for so much money.

Don’t operate on the basis of verbal agreements or casual memos, even if your customer happens to be your buddy down the hall and you both work for the same organization. Within your company, you may call your document a “letter of understanding” or something similar, which sounds friendlier than “contract.” In any case, you need a formal written statement clearly showing what the customer wants and what you agree to provide. Operating without such an agreement is lunacy for both parties, as many software project managers and just as many customers have found out. Contract Template

Usually a contract have to cover the following essentials elements: (1) Scope of the work.

What is the job to be done? If the job definition is too vague, maybe you need two contracts: One to define the job One to write programs.

(2) Schedule and deliverables. What specific items (programs, documents) are to be delivered to the customer? When are they to be delivered? Where are they to be delivered? In what form (diskettes, CDs, drafts or clean documents)? How many copies?

(3) Key people. Who is authorized to approve changes and accept the finished product?

(4) Review schedule. When and how shall the customer be given reviews and reports of progress?

What is required of the customer if he disapproves of a report? (5) Change control procedures.

What will be the mechanism for dealing with items the customer demands, which you consider changes to the original work scope?

(6) Testing constraints. Where and under whose control will computer or other test time be obtained? During which work shifts? Exactly what priority will your testers have?

(7) Acceptance criteria. What are the specific quantitative criteria to be used in judging whether your finished product is acceptable?

(8) Additional constraints. Are there items which may be peculiar to your working environment? Are you to use customer personnel? If so, what control do you have over them? Are there special data security problems? Is the customer required to supply test data? If so, what kinds of data, in what form, when, and how clean?

(9) Price. What is your price for doing the job? Is it fixed or variable? If variable, under what circumstances? All of these items and more will be addressed in much or less detail in the contract. The last item, price, is handled in a good many different ways depending on the type of contract agreed upon. Here is a brief summary of formal contract types.

The last two contract types (Labor hours and Level of effort) are pretty

much risk­free for the contractor. He provides people to do as the customer

directs. o (2) The other contract types involve varying degrees of risk for the contractor and the customer.

(1) Firm Fixed Price (FFP)

o (a) The price is set and not subject to change even if you have estimated badly. o (b) This is the most risky type of contract to use on a programming job. o (c) It should never be used without at least a very clear statement of work, no fuzzy areas, no dangling definitions. o (d) Many a project has experienced severe losses operating under such a contract. (2) Fixed Price with Escalation (FP­E) o (a) The price is set o (b) Some allowance is made for bothupwardanddownward adjustments in case certain things happen, for example, labor rates or material costs change. (3) Fixed Price Incentive (FPI) o (a) A target price is set o (b) Some formulas are established that allow the contractor: (1) A higher percentage of profit if the contractor exceeds selected targets, (such as cost) (2) A lower percentage of profit (even a loss) if the contractor misses the selected targets.

(4) Cost Shared (CS) o (a) This type of contract reimburses the contractor for part or all of his costs but allows no profit, or fee o (b) It’s used either:

(1) For research work with nonprofit organizations (2) In joint projects between the customer and the contractor where there is anticipated benefit to the contractor. For example, the job may result in a product for which the

contractor will have the exclusive right to sell..

(5) Cost Plus Incentive Fee (CPIF) o (a) The contractor will be paid all his costs plus a fee o (b) The fee varies depending on: (1) How close the contractor comes to meeting the established target costs (2) How well he does in other areas spelled out in the contract. o (c) The criteria which determine the fee must be objective and measurable

(6) Cost Plus Award Fee (CPAF). o (a) Is similar with CPIF o (b) The difference is the criteria which are more subjective and are weighed by a Board of Review.

(7) Cost Plus Fixed Fee (CPFF) o (a) The contractor is paid allowable costs and a set fee.

(8) Time & Materials (T&M) o (a) The contractor is paid for labor hours actually worked and the cost of materials used.

(9) Labor Hour (LH) o (a) Labor hours are paid for, but nothing else.

(10) Level of Effort (LOF) o (a) Is similar with Labor Hours type of contract o (b) The effort is paid, but nothing else.

3. Project plan outline. Short description of the contents of the Project Plan Sections.

Project Plan Outline

The toughest part of any writing job is getting started. That is the reason for is recommended to start with a predefined Project Plan Outline.

It should be: o (1) A model published in literature [Me81], [Kr99], o (2) A model developed in your organization based on your history and experience. Use it as a starter, modify it to suit your situation, and you’re on the way. Starting with the Project Plan Outline has many advantages: o (1) You won’t waste time trying to decide how to break up the planning job. o (2) This outline has built­in credibility because it has been contributed to by many experienced programming managers. o (3) Having any outline to use as a starter helps reduce the number of rewrites, saving hundreds of man­hours later. Project Plan Sections.:

(1) Overview o (2) Phase Plan o (3) Organization Plan o (4) Test Plan o (5) Change Control Plan o (6) Documentation Plan o (7) Training Plan o (8) Review and Reporting Plan o (9) Installation and Operation Plan o (10) Resources and Deliverables Plan o (11) Index 7.3.1 Overview The overview section of the plan has some important purposes: o (1) First, it assumes that the reader knows nothing about the project and it introduces him to the job and to the customer.

o (2) Second, it describes the general organization of the plan. o (3) Presents the assumptions and restrictions on which the plan is based. o (4) Establishes a gross schedule for the project. o (5) Refers for short to technical aspects. o (6) Makes a risk analyze of the project. 7.3.2 Phase Plan The objective of this section is to define the development cycle for the project. The Phase Plan serves as a foundation for subsequent plan elements. o It is highly recommended to adopt a development cycle as the one presented in this course or another. For each phase of the Life cycle describe the primary and the secondary objectives. o The Phase Plan should end with a chart similar to fig. 7.3.2.a but with dates included. o (7) It summarizes the entire plan by giving a capsule description of the detailed plan elements that follow the Overview. 7.3.3 Organization Plan Organization Plan element should define: o (1) The organization during the various phases of the project. o (2) The specific responsibilities of each group within the organization. The outline of the Phase Plan is presented in fig. 7.3.3.a. o (1) It presents first the groups and their general responsibilities. o (2) For each phase of the development cycle, the specific organization and groups' responsibilities are detailed. 7.3.4 Test Plan This section describes the tools, procedures, and responsibilities for conducting all testing levels on the project. (Fig. 7.3.4.a.) The Test Plan should clearly define:

o (1)The levels of test (for example, “module test,” “integration test,” “system test,” “acceptance test,” “site test). o (2) Responsibility for executing each level. o (3) Machine support required for each level. o (4) Support programs or tools required. o (5) The reporting of test results. For each test level the Test Plan must define: o (1) The test objectives. o (2) The test responsibility. o (3) The test procedures. o (4) The test entry criteria. o (5) The test exit criteria. o (6) The test tools. 7.3.5 Change Control Plan. Controlling changes in the developing program system is one of management’s most vital functions. This section defines: o (1) The kinds of changes to be controlled. o (2) The mechanism for effecting that control. 7.3.6 Documentation Plan. This is a key section, but it’s usually missing. Its intent is to control the gush of paper that inevitably accompanies most projects. o One important cause of our so often getting buried under paper is that we don’t take the time to define the documents we want to use on the project. o As a result, whenever a project member needs to write something, he dreams up his own format and suddenly there is a new kind of document to file and keep track of. The Documentation Plan is a gathering place in the Project Plan for the descriptions of all paper work to be used during the project.

7.3.7 Training Plan. Generally, there are two categories of training required on a project: o (1) Internal ­ training your own people. o (2) External ­ training the customer and others. Training is often awarded little or no space in a plan, but this omission can be serious on some jobs. o The Training Plan defines all the kinds of internal and external training required, the res ponsibility for each, and the resources required 7.3.8 Review and Reporting Plan The objective of this plan element is to define how project status will be communicated by: o Oral project reviews. o Written reports. o Structured walk­through. o Inspections. Structure Walk­through's and inspections are discussed in detail later. o They are not intended as a means of reporting status to management, but they are an important means of helping project members assess the quality of the products they are developing. 7.3.9 Installation and Operation Plan This describes the procedure for getting your finished, “accepted” program system installed and operating properly in its intended environment, perhaps at some missile defense site, perhaps in the computing center down the hall. The outline of this plan is presented in fig. 7.3.9.a. The plan contains to chapters: o (1) Installation. o (2) Operation. Even the simplest of programs can become snarled in such problems as how to convert from an existing, perhaps manual, system to the new,

computerized system. 7.3.10 Resources and Deliverables Plan. This plan element brings together in one place the critical details associated with your plan: o (1) Manpower. o (2) Computer time. o (3) Other resources. o (4) Delivery schedules ­ A summary of all items that you are to deliver under your contract. o (5) Milestone chart ­ A summary of project milestones. o (6) Budget. The outline of this plan is presented in fig. 7.3.10.a. These data are among the most frequently changed or consulted, so they should be gathered in one place to make them easier to find and easier to change. 7.3.11 Plan Index It’s one of the most effective way to make your Project Plan much more attractive and usable to the reader. 8 Writing Acceptance Criteria Discussion of acceptance testing will be included under the Acceptance Phase in Chapter 8. But the actual work of preparing for acceptance begins here, in the Definition Phase. What deserves particular emphasis now is that the criteria for acceptance must be agreed to early and in writing. Don’t labor through an entire project without knowing exactly what conditions your product must satisfy in order to be acceptable to the customer.

4. Manager's Job: Assign the work (persons, domains). Working hours (normal, supplementary, flexy­time, dead­line) Context of using, advantages, disadvantages. The manager’s job is: o (1) To plan an activity o (2) To see that it is carried out. The manager’s job is the promotion of excellence. o Simply getting a task done, meeting deadlines, living within budgets, rewarding workers fairly, pleasing the customer, maintaining personal and company integrity, etc. — these are essential, but not enough. The manager should always: o Be looking for ways to provide an excellent product. o At the same time ensure the personal satisfaction and career growth of his people. o Those things go hand­in­hand; An excellent product will enhance the careers of its makers. Growing and satisfied people will produce a better product. Persons Assignment The solution is simple. First, assign a specific person for any job. o The idea that a busy executive can be acting manager of a major project in his spare time is ridiculous. o Better to appoint a slightly less qualified person to the job full time than to assign the job to an acting manager who can’t devote enough time to do the job justice. Now suppose that you have been assigned as manager of a project or proposal effort. o (1) You must first gain an understanding of the job.

o (2) Then make an attempt at breaking up the job and assigning pieces of it to individuals. But this is not enough. o (3) You must write down a description of each person’s job. No exception! Write it down! o (4) Then give a copy of all assignments to everyone. The first thing that will happen is that half your crew will come storming in to complain that someone else’s job assignment bites into their territory. If you’re lucky, someone will come in and point out that nobody’s assignment covers area X. o (5) After you’ve had a couple days of complaints, and people have chewed on the assignments enough, set up a meeting to talk over the problems that have been brought you. o (6) Then rewrite the assignments, pass them out again, and wait the second round of blasts. o (7) It may take a couple of repetitions, some of the meetings may be uncomfortable, but soon you’ll have job descriptions that don’t overlap and do cover what needs to be done. Domains Assignment An alternate approach is: o (1) To assign work by topic only, and let each one write his own work description. o (2) Then you alter them in whatever way you see fit, and pass them out. Normal Working Hours Allocation Working Hours are allocated to tasks, based on: o (1) A priori estimation of the tasks size. o (2) A pre­established schedule. Every programmer, manager or other implied people must have an evidence of the personal working time.

First and second level managers must have the evidence of the working time for theirs teams as basis for control. Project Manager must to have an image of the total working time spent on project development as basis for control. 5.6.2 Supplementary Working Hours If you’re relatively new to the computer programming business, perhaps you have not yet taken part in panic projects where everything was late and management had to resort to that ultimate remedy: scheduled overtime. It's hard to demonstrate that there is a much worse waste of resources than this. o There is a natural temptation to think that by working a given set of people 25% more hours a week, 25% more work will get done; Some managers even think that crash overtime efforts help to bring the troops together and that develops a strong feeling of camaraderie. Flexy­Time Technique There is something else to consider about working hours. Various companies have experimented with the idea of letting employees set their own hours. o (1) Generally, the total time to be worked each day is set, but starting and ending times are allowed to float. o (2) This can be further liberalized by setting a number of hours for, say, an entire week, and leaving the specific days or hours up to the individual. Dead­Line Technique Carried a step further, hours might be eliminated as a measure of work or worth. The means of measurement or control might be that the employees complete a given task by some predetermined date. o This is dead­line technique.

Subiect 2 2. Size estimation methods. Describe a size oriented method + function

oriented method. 4. Organization Modalities. Conventional organization, Team organization,

Chief programmer organization. Organization Modalities There are a number of basic ways of organizing people to do a job: o (1) Functional organization. o (2) Job­shop organization. o (3) Project organization. (1) Functional organization o The Project Manager borrows people from groups of specialists within the company. o Each specialist is on loan to PM to do his part of the job, and then he’s gone — on loan to the next manager who needs his skills. This arrangement gives the project manager, little control because the man on loan is likely to be more concerned with his home organization than with your project. Typically, PM has little or no say about whom he get, and he can be frustrated by substitutions made before his job is finished. o Perhaps worse than that there will be little or no continuity of people on job. o In the worst case: The analysts come, they analyze, they leave. The designers come, they design, they leave. And the same for the programmers. (2) Job­shop organization o The program system is broken up into several major subsystems. o A manager and his group is assigned with total responsibility for developing

that subsystem—analysis, design, programming, the works. Here the big problem is that nobody has his eye on the system because the managers are concerned only with the subsystems. o A job­shop arrangement works if there are to be done a number of relatively small, unrelated jobs (in other words, not a system). If you’re a manager accustomed to a job­shop organization and are about to manage the development of a system, remember that what worked before may not work now. (3) Project organization o Neither functional nor job­shop organization is appropriate for producing a system. The kind of organization needed here is project organization. o What is implied in any such arrangement is: (1) The people involved devote their efforts to a single project. (2) They are all under the control of a single project manager. o Project organization may take many forms. Every company has its rules about lines of authority, degree of autonomy, reporting to outside management, and so on. Ignoring such considerations, we may discuss project organization in terms of two quite different approaches: (1) Conventional organization. (2) Team organization. Conventional Organization Figure 6.2.1.a illustrates two conventional ways to organize a medium size project. The only real difference between (a) and (b) is the number of management levels between the project manager, and the people who do the technical work. The choice of (a) or (b) depends on project manager's strengths and weaknesses

and those of the managers who are available to him. o (1) If the project manager is technically strong, able to absorb much detail, and can handle as many as seven managers reporting to him (a hefty number), then (a) might well be the choice. The danger here is that the project manager may become swamped in details, lose sight of broader project objectives, and lose control. o (2) If the project manager prefers to delegate more responsibility so that he can concentrate on the important problems that arise, then (b) might be the choice. In that case the project manager has four managers reporting to him. Either way the project has many managers (seven or eight besides project manager), and that may horrify the boss ­ "Where are the workers!?". o (1) In fact, these managers are not paperwork shufflers. o (2) Since they are very much involved in technical decisions, the ratio of managers to workers is not so bad as it looks. Team Organization. Chief Programmer Team The team approach is a way of organizing around a group of specialists. o The embodiment of the approach in programming is called the Chief Programmer Team. IBM’s Harlan Mills, originator of the concept, compares the Chief Programmer Team to a surgical team, where a chief surgeon plans and performs an operation with vital help and backup from highly skilled assistants, both surgeons and nonsurgeons. o What follows is an overview of how this idea is put into practice. 2.2.1 How It Works The core of a Chief Programmer Team would normally be three people: o (1) Chief programmer. o (2) Backup programmer. o (3) Technical librarian.

The Chief Programmer o Chief programmer is the technical manager responsible for the development of the program system. o This person will normally write at least the critical "system" modules — that is, the portion of the program system exercising control over, and interfacing with, all the lower­level "working" modules. o Depending on the total size and complexity of the job, he and the backup might write the entire program system. Where others are involved, the chief programmer assigns work to them and integrates all their modules with his own. o The chief programmer is the main interface with the customer, at least in technical matters There may be a managerial counterpart who handles non­technical tasks. Subiect 4 2. Change control. Baseline documents. Control procedures Change Control The most important function of Analysis and Design Group is to carry out the change control procedures which will be described later. This means: o (1) Investigating proposed changes. o (2) Recommending adoption or rejection. o (3) Documenting the results. The group acts as a filter. o It relieves other project members, particularly the programmers, from much of the burden of digging into a proposed change and tracking down the consequences of making the change. On many projects the investigation of a change proposal falls on the programmer.

The programmer is constantly sidetracked from his main job to run down this or that idea suggested by the customer or by someone in his own organization. o When a person is doing something as logic­oriented as programming, every interruption means a loss of efficiency. When the interruption ends, he must say, "Now, where was I?" In addition to the wasted time backtracking, he may well end up with a bug at the point of interruption. Very often the frustration of constant interruption causes the programmer to give a hasty answer and to agree to the change just to get the problem off his back so that he can get on with his programming. Baseline Documents First, you must decide what to control against, that is, what are the things you want to use as foundations, or baselines. Metzger recommends two baseline documents: o (1) The Problem Specification. o (2) The Design Specification. If you put your effort into making these two documentsfinepieces of workin the first place and set up your procedures to control changes to them, then it’s hard to go wrong. o Conversely, if your baseline documents are shallow and poorly done, or if you fall to control changes to them, it’s hard to go right. There is a third kind of baseline you may need to consider. o The two mentioned above are established early in the development cycle and are used to guide production of the program system. o If you are responsible for maintenance or for more versions of the system beyond the initial delivery, then (3) The Delivered Program System becomes a new baseline.

o In other words, in working on a second or third or n­th version of the program system, you may use the last delivery as the baseline. Here, however, we will discuss only a single­delivery development cycle. Control Procedures If we agree on controlling change against the Problem Specification and the Design Specification, we can now consider a simple control mechanism that you can tailor to fit your needs. Whenever an individual sees a need for a change that he thinks may affect one of the baselines the folowing steps are to be accomplished: o (1) He proposes a formal change. o (2) The Analysis and Design Group analyzes the proposed change and recommends adoption or rejection. o (3) The recommendation is then submitted to the Change Control Board which makes its decision, subject to override by either you or the customer. o (4) The Analysis and Design Group documents the decision, and the change, if adopted, is implemented. Now let’s take a closer look at how this procedure might work. (1) Proposing a change. o Anyone, either in your organization or the customer’s can propose a change. To do so, a simple Change Proposal form is filled out that describes the need for the change, and, if possible, the way to make the change. o As a rule, a programmer proposes a change only if he thinks one of the baselines might be affected. A Change Proposal is not submitted every time a piece of detailed design for a module is slightly altered. o There is one kind of change that falls outside this formal control procedure, but it must be mentioned in passing: Suppose a programmer wants to make a change to one of the modules already submitted for integration test. The change affects neither the Problem Specification nor the

Design Specification, but it does affect the detailed design — the Coding Specification for the module. The change might be to correct a late­found bug or to improve a piece of code. Whether or not to accept the change in this case should be up to whoever is in charge of integration testing involving that module. If the change makes sense, it should be accepted only in the form of a new copy of the program module, a corrected Coding Specification, and an updated module identification. No change should ever be accepted without a change in the module identifier. Every time you let one through you lose a little more control. Subiect 3 4. The Testing Phase; Test Plan; Test Execution; Types of tests THE SYSTEM TEST PHASE The system test phase is the phase toughest to sell. Both managers and programmers resist it, and yet it’s ascriticalas any period on the project. The system test phase objectives are: o (1) The main objective is: To subject the programmers’ products to a thorough set of tests neither designed nor executed by the programmers. Run in as nearly a live environment as possible with a minimum of simulation. o (2) A second objective is to begin training the customer to be ready to take over the new system.