ISO/CEI 12207 standard. Definitions: Process, activity, task. Type of processes: Primary, support, organizational. Short description. Chapter01.pdf - pagini 5-8

3. PROCESSES, ACTIVITIES AND TASKS IN A SW PROJECT3.1 ISO/CEI 12207: 1995 STANDARD

The multitude and the complexity of the problems related to the developmentof a SW product implied the necessity of a systematical approach andstandardization.

The result was ISO/CEI 12207:1995 Standard having as main purpose toestablish for SW industry:o A common frameworko A well defined terminology3.2 DEFINITIONS

Definitions: In accordance with this standard a SW PROJECT consists in:

(1) Processes – an assembly of resources and interdependent activitiesoriented to a well defined purpose.

(2) Activities – are parts of a process consisting in types of actionsthrough which, process resources are used for project purpose.

(3) Tasks – are components of activities consisting in one or an assemblyof actionso A task can be related with a person or a group of persons havingthe responsibility of their accomplishmento 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 SWservice

(4) Utilization Process – defines the activities through which anorganization utilizes a system, a product or a SW service

(5) Maintenance Process – defines the activities through which anorganization supplies maintenance service for a system, a productor a SW service3.5 SUPPORT PROCESSES

SUPPORT PROCESSES are processes which support other processes. Theycontribute 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 SWdeveloping process.o That presumes user documentation as well as documents related todeveloping process: plans, reports, specifications, internalstandards, associated documents, internal procedures.

(2) SW Configuration Management Process (SCM) – consists inadministrative and technical procedures whicho 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 SWcomponentso Establish product versionso 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 activitieswhich assure in an objective manner thato The realized SW product fulfill the specified requirements

o The implied processes comply with a set of established plans andprocedures

(4) Testing Process (*) – defines the assembly of activities having aspurpose the verification of the products resulted from developingactivities, which satisfy imposed requirements and conditions.o The verification has different degrees of depth depending on theactivity whose product is tested

(5) Validation Process (*) – defines the assembly of activities whichverifies if a SW product which is in a final phase, satisfies the plannedutilization requirements (covers the user’s needs resulted from the analyzeprocess)

(6) Common Analyze Process (*) – is the process of analyze/evaluationof 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 orsupplier)o It focuses on either the analyze of SW product requirements or themeasurement of the “pulse” of the project

(7) Audit Process (*) – contains the activities oriented to certify theconformity with norms, requirements, schedules, and statements of thecontract 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 activityor task, and not at the end, as in the case of test or validationprocesso (2) The auditing part has no direct responsibilities in the impliedproducts and processes, element that differentiates the auditingprocess from the common analysis one.

(8) Problems Solving Process (*) – includes activities concerninganalyze 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 QualityAssurance Process3.6 ORGANIZATIONAL PROCESSES

ORGANIZATIONAL PROCESSES are processes related to themanagement, 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 anyprocess.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 andmaintaining the professional level of the personal.o The main effort is directed to improve the knowledge and toincrease the qualification of the personal.

(4) Improving Process – consists in the set of activities oriented todefinition, evaluation, measurement, control and improvement of anyprocesssummary

Standardul ISO/CEI 12207. Process, task, activities. Primary, Secondary. Organisational processes. Chapter01.pdf - pagini 5-8

Stuff de mai sus ^^

Standardul ISO/CEI 12207. Development proces activities. Chapter01.pdf - pagini 8-10

4. DEVELOPMENT PROCESS It belongs to the Primary Processes Is the main part of the entire SW project implying the highest support

from theother processes

Consists in a number of specific activities It is directed and controlled by the Management Process (O)

4.1 DEVELOPMENT PROCESS ACTIVITIES (1) Process Initiation – presuming:

(a) Selection and utilization of a life cycle model in accordance with thedimension, the complexity and the application domain of the SW productto be developed

(b) Elaboration of the Project Development Plan based onDocumentation Process (S) specifications, consisting in: Standards, methods and specific tools used in development.

Usually these are outputs of the Infrastructure Process (P) Factorization of the process actions in tasks, Identification of the knowledge and the aptitudes

necessary for tasks achievement Establishing the tasks scheduling Identifying the persons responsible with the carry out of

each task, based on estimation of the necessary skills. If the team have to be trained, this is performed as part of the

Training Process (O) Identification of the Development Process outputs, their

scheduling, and specification or referring the ConfigurationManagement Process (S) if necessary Identification of the deliverable outputs of the Development

Process (P) and specification of their characteristics (2) SW and System Requirements Analyze

The output of the activity is the document named Specification (ProblemSpecification, SPEC). This document is conform with Documentation Process (S) and includes: System and SW features and capabilities Security, ergonomic and business requirements Organizational requirements Interface requirements with user, other components, other existing

SW systems Exploitation and maintenance requirements User documentation requirements This activity is part of the Common Analyze Process (S), because usually

is developed not a single solution but a class of solutions solving themultitude of the problem requirements, from which the optimum solutionhad to be selected Defining Validation Tests Plan which elaboration is considered part of

this activity (3) System Architecture Design – consists in elaboration of a set of

documentsreferring to: The HW components of the system and their interconnection modalities SW configuration elements and their assignation to the HW components

Manual operations allowed by the system User and SW configuration elements Interfaces High level architecture of the SW configuration elements (their

components), interfaces between components and the general structure oftheir data base (if necessary) Preliminary version of the user and administration manuals Preliminary version of the Integration Test Plan. (4) Detailed SW Design – consists in elaboration of a set of documents

whichdetails the basic design. It consists in: Detailed project of each SW component identified in the design phase.

That presumes: Component decomposition in SW units (the level of detail

reaching classes in OO approach), The specification of the role, of the interface, as well as the

specific life cycle for each unit. The detailed design must allow the direct codification of the

components without other supplementary information. Detailed project of the structure of the data basis. The SW Units’ Test Plan designated to test SW units Up-dating of the Integration Test Plan (5) Codification – refers to the codification of the SW components (6) Test of the written code – it’s named also SW Qualification Test. It

isaccomplished on the base of the SW Units’ Test Plan The results of the tests are documented as Test Reports Encountered problems (bugs) are solved based on Problems Solving

Process (S) (7) System integration – presumes activities related to integration of the

SWelements with HW elements and with the other existing systems

(8) Integration test – known also under the name of System Qualification Test Presumes verification of the correctness of the system functionality as a

hole. Based on the Integration Test Plan. The results of the tests are documented as Test Reports Encountered problems (bugs) are solved based on Problems Solving

Process (S)

(9) SW Installing – presume installation and configuration of the SW product onthe target environment. The typical tasks of this activity are: Elaboration of the Installing Plan which refers to: Specification of the necessary actions and resources Sharing responsibilities between developer and purchaser (user) Establishing the conditions for data migration if an old existing

system is replaced Effective installing of the system in accordance with the Installing Plan The events and results of the installing process are registered in specific

documents in accordance with Documentation Process (10) Validation System Support – is given by the developer to the

system userand consists in: Assistance in validation tests execution Validation of the system conformity with specified requirements The test results are registered in specific documents in accordance with

Documentation Process (S) Any encountered problem is fixed in accordance with Problems Solving

Process (S) The successfully end of this activity, usually presume the end of the

Development Process (P)

Project plan outline. Short description of the contents of the Project Plan Sections. Chapter04_2 pagini 73-77

7.3 A Project Plan Outline• Metzger tried many different structures before settling on the outlinepresented in this course.o Use it if you’ll find it helpful, but by all means modify it to suit yourneeds, even your temperament. After all, you have to live with it.• The Project Plan is divided into the following sections, which aresummarized in succeeding paragraphs:o (1) Overviewo (2) Phase Plano (3) Organization Plano (4) Test Plano (5) Change Control Plano (6) Documentation Plano (7) Training Plano (8) Review and Reporting Plan

o (9) Installation and Operation Plano (10) Resources and Deliverables Plano (11) Index

Overview The overview section of the plan has some important purposes:

o (1) First, it assumes that the reader knows nothing about the projectand 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 isbased.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.o (7) It summarizes the entire plan by giving a capsule description of thedetailed plan elements that follow the Overview.1.1 OBJECTIVEThe objective of this section is to summarise the entire Project plan .1.2 DISCUSSION„h Set the stage. Identify the customer and his experience in the field.Describe in one or two paragraphs the job to be done.1.3 DETAILGive a brief description of the objectives of each of the remaining sections ofthe Project Plan.

7.3.2 Phase Plan„h The objective of this section is to define the development cycle for the project.„h The Phase Plan serves as a foundation for subsequent plan elements.o It is highly recommended to adopt a development cycle as the onepresented in this course or another.„h For each phase of the Life cycle describe the primary and the secondaryobjectives.o The Phase Plan should end with a chart The Phase Plan provides you with a base, a point of reference.o For example, when you and your people talk about the System TestPhase, you should all be talking about the same thing.o Unfortunately this rarely happens on a project, and that’s a crime. Itleads to much confusion and misunderstanding that could easily beavoided.2.1 OBJECTIVEThe objective of this section is to define the programming development effort in terms ofa series of time-slices called “phase”.2.2 DISCUSSIONDefine your development cycle and, briefly, each phase making up the cycle. Include anillustration but include calendar dates. Establish basic definitionsand points out that the remaining sections of the plan are tied to these definitions. If youare planning multiple releases, show how they are scheduled in a series of overlapping,essentially identical, development cycles.2.3 DETAILFor each phase list primary and secondary objectives and define each objective asrigorously as possible

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

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 specificorganization

7.3.4 Test Plan„h This section describes the tools, procedures, and responsibilities forconducting all testing levels on the project

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.„h Controlling changes in the developing program system is one ofmanagementˇ¦s most vital functions.„h This section defines:o (1) The kinds of changes to be controlled.o (2) The mechanism for effecting that control. (fig. 7.3.5.a.).

7.3.6 Documentation Plan.„h This is a key section, but itˇ¦s usually missing.„h Its intent is to control the gush of paper that inevitably accompanies mostprojects.o One important cause of our so often getting buried under paper is thatwe donˇ¦t take the time to define the documents we want to use on theproject.o As a result, whenever a project member needs to write something, hedreams up his own format and suddenly there is a new kind ofdocument to file and keep track of.„h The Documentation Plan is a gathering place in the Project Plan for thedescriptions of all paper work to be used during the project. (fig.7.3.6.a).

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 trainingrequired, the responsibility 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 becommunicated 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 assessthe quality of the products they are developing.

7.3.9 Installation and Operation Plan„h This describes the procedure for getting your finished, ˇ§acceptedˇ¨ programsystem installed and operating properly in its intended environment, perhapsat some missile defense site, perhaps in the computing center down the hall.„h The outline of this plan is presented in fig. 7.3.9.a.„h The plan contains to chapters:o (1) Installation.o (2) Operation.„h Even the simplest of programs can become snarled in such problems as howto 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 associatedwith 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 deliverunder 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 theyshould be gathered in one place to make them easier to find and easier tochange.

7.3.11 Plan Index• It’s one of the most effective way to make your Project Plan much moreattractive and usable to the reader.

Manager's Job: Assign the work (persons, domains). Working hours (normal, supplementary, flexy-time, dead-line) Context of using, advantages, disadvantages. Chapter03

Definition: Project management is “the application of knowledge, skills, tools, andtechniques to project activities in order to meet or exceed stakeholder needs andexpectations from a project.”

The manager’s job is:o (1) To plan an activityo (2) To see that it is carried out.

But from the instant the project begins, he must contend with the fact that humanstend not to solve problems until they become crises.o Only a crisis seems worthy of real attentiono Whether it’s a strike deadline, an international diplomatic standoff, a humaninjustice, nothing gets resolved until something overflows.o And of course, computer programs don’t get serious attention until thedeadline is terrifyingly close at hand or the customer is threatening to sue!o It’s practically a law: ”A problem must reach crisis proportions before we act tosolve it.”Managers allow team members to set their own schedules,but only after the developers have analyzed tasks in detail(for example, half-day to three-day chunks) and have beenasked to personally commit to the schedules they set. Managers then “fix” project resources by limiting the

number of people they allocate to each project. Managers also try to limit the time spent on projects,

(especially for applications like Office and multimediaproducts), so teams can delete features if they fall too farbehind. However, cutting features to save schedule time is not

always possible with operating systems projects in which: Reliability is more important than features Many features are closely coupled and cannot easily

be deleted individually...... fuck

Size estimation methods. Describe a size oriented method + function oriented method. Chapter04_1

There are some classical methods for size estimation of the SW projectsbased on these metrics:o (1) Wideband-Delphi Methodo (2) Fuzzy-Logic Methodo (3) Standard-Component Method

Wideband-Delphi Method„h The Wideband-Delphi estimating method was originated by the RandCorporation and refined by Boehm.o (1) It calls for several engineers to individually produce estimates.

o (2) Then uses a Delphi process to converge on a consensusestimate.„h The procedure is essentially as follows [Humphrey 89]:„h (1) A group of experts is each given the program ¦s specificationsˇand an estimation form.„h (2) The members of the group meet to discuss project goals,assumptions, and estimation issues.„h (3) The members of the group then each anonymously list projecttasks and estimate size.„h (4) The estimates are given to the estimate moderator, whotabulates the results and returns them to the experts, as illustrated infigure 4.3.1.1.a:„h For each expert only personal estimate is identified.„h All other ¦s estimates are anonymous.ˇ„h There is also identified the median estimation.„h (5) The experts meet to discuss the anonymous results.„h (6) The experts each eventually review the tasks they have definedand their size estimates.„h (7) The cycle continues at step 3 until the estimates converge towith an acceptable range

For reasonably large programs, the estimators make simultaneousestimates for several product components.o At the end of the estimating process, these estimates are combinedto produce the total final estimate.• The estimating process is run by a moderator who should always becareful never to reveal the source of any individual estimate.• The appropriate attitude is that no one knows the right answer.o Everyone has a partial view.o The purpose of the Delphi process is to share those views.• By encouraging the participants to discuss the project tasks, a skilledmoderator can facilitate very informative discussions.o The person who made a particularly high or low estimate issometimes willing to explain why that value was picked.o The resulting discussions often shed light on the problem andsurprisingly often convince the other engineers to change theirestimates.o While confidentiality will often become a non-issue, the decision toreveal any estimator’s identity must be left up to that estimator.• This method can produce quite accurate estimates.• It also often provides:o (1) A solid foundation from which to start the work.o (2) The commitment of the engineer

4.3.2 Function Oriented Metrics„h Function Oriented Metrics consists in estimating of the complexity of thefunctions implemented by the SW product to be developed.„h There are 2 categories of function oriented metrics:o (1) Functional points oriented metrics

o (2) Feature points oriented metrics„h There are also some specific estimation methods based on thesemetrics:o (1) Function-Point Methodo (2) Characteristic-Point Methodo (3) Proxy-Based Method

Caracteristic-Point Method„h The metrics based on characteristic points was proposed by C.A. JonesThe method is not very much different from function-point method.„h In fact there are three differences:o (1) Function-points are substituted with characteristic points.o (2) The associated weights have different values.o (3) A new parameter is added: algorithms with weight 3.„h The characteristic-point method ¦s steps are:ˇo (1) Estimate the basic count associated to the each characteristicpoint.o (2) Multiply each counter with its weight.o (3) Calculate the Total for each characteristic point.o (4) Calculate de general Total by summing the partial totals (Table4.3.2.3.a.).„X There are versions of method in which weights differs functionof program complexity (simple, average, complex)„X The determined Total can be adjusted in a similar manner as infunctional point method:o (5) Establish the weights of the 14 influence factors.o (6) Calculate the value of the complexity adjustment factor (SIFSumof Influence Factors) as sum of the 14 influence factors.o (7) Calculate the value of the Adjusted Total :Adjusted Total =Total*(0.65 + 0.01*SIF)

Organization Modalities. Conventional organization, Team organization, Chief programmer organization. Chapter06_1 - pagini 7-10, 37-39

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 levelsbetween the project manager, and the people who do the technical work.• The choice of (a) or (b) depends on project manager's strengths and weaknessesand 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 heftynumber), 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 hecan concentrate on the important problems that arise, then (b) might be thechoice. In that case the project manager has four managers reporting to him.

• Either way the project has many managers (seven or eight besides projectmanager), 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 ofmanagers to workers is not so bad as it looks.• In most situations is recommended choose (b) over (a).

The rea l impor tan ce, ho wever, i s no t in t he exa c t nu mber o f boxes on theorganiza t ion cha r t nor t he i r t i t l es bu t :o (1) The PM (pro jec t manager) mus t a c coun t for a l l jobs tha t have t o be doneand do i t in a w o r kab le w ay.o (2) PM mus t be sure t ha t every me mber o f t he o rganiza t ion kno ws bo th hisand o ther people ¦s ob je c t ives.ˇ„ h The re mainder o f t h i s sec t ion descr ibes the func t ions o f t he var ious g roups sho wn inFigure 6.2.1.a. (b) and ends by consider ing some t yp i ca l nu mbers o f people int he var ious ro les

Team Organiza t ion. Chie f Progra m mer Team„ h The tea m approach is a w ay o f o rgan izing around a g roup o f spe c ia l is ts.o The embodimen t o f t he approach in p rogram ming is ca l led t he Chie fProgra m mer Team.„h IBM ¦s Ha r lan Mi l l s, or ig ina tor o f t he con cep t, co mpares t he Chie f Program mer Teamˇt o a surg i ca l t ea m, w here a ch ie f su rgeon p lans and perfo r ms an opera t ion w i t h v i ta lhelp and backup f ro m h igh ly sk i l led ass is tan ts, bo th surgeons and nonsurgeons.o Wha t fo l lo ws is an overv ie w o f ho w t h is idea is pu t in to pra c t i ce.2.2.1 Ho w I t Works„h The core o f a Chie f Progra m mer Team w ou ld no r ma l ly be t h ree people:o (1) Chie f progra m mer.o (2) Bac kup program mer.o (3) Techni ca l l ib ra r ian.„h (1) The Chie f Progra m mero Chie f progra m mer is t he te chni ca l manager respons ib le for t he developmen to f t he p rogra m sys te m.o Th is person w i l l no r ma l ly w r i t e a t leas t t he c r i t i ca l "sys te m " modules X t ha t is,ˇt he po r t i on o f t he p rogram sys te m exer c i s ing con t ro l over, and in ter fa c ingw i t h, a l l t he lo wer-level " wo r k ing" m odules.o Depending on t he to ta l s ize and co mplex i ty o f t he job, he and the bac kupmigh t w r i t e t he en t i re p rog ram sys te m.„X Where o thers are involved, t he ch ie f program mer ass igns w o r k to t he mand in t egra tes a l l t he i r modules w i t h h is o wn.o The ch ie f prog ra m mer is t he ma in in ter fa ce w i t h t he cus to mer, a t leas t in

t e chni ca l ma t te rs„X There may be a m anager ia l coun te rpa r t w h o handles non-t e chni ca lt asks.„h (2) The bac kup p rogra m mero Assis t s in any w ay ass igned by t he ch ie f progra m mer,„X His pr i ma ry func t ion is t o unders tand a l l face ts o f t he sys te m as w e l l ast he ch ie f progra m mer does.„X His se cond func t ion is t o be ready a t any t i me t o t ake over as ch ie fp rogra m mer.o The bac kup p rogram mer is no r mal ly ass igned spe c i f i c po r t i ons o f t he sys te mt o design, code, and t es t , as w e l l as o ther du t ies for exa mple, prepara t ion o fa t es t p lan.„h (3) The te chni ca l l ib rar ian (conf igura tor)o The te chni ca l l ib rar ian is a d i f fe ren t person f ro m the "genera l l ib rar ian" w h oruns the pro je c t ¦s genera l l ib ra ry and has the no r ma l responsib i l i t y usual lyˇassoc ia ted w i t h a l ib ra ry.o The te chni ca l l ib rar ian is respons ib le for runn ing t he Develop men t Suppo r tL ibra ry or t o manage the SW Conf igura t ion Tool used by t he o rganiza t ion(CVS - Cont ro l Vers ion Sys te m, Con t inuous, ClearCase, CM Synergy, e t c).„X Th is person is a fu l l and v i t a l me mber o f t he t ea m, no t on pa r t-t i me loanf rom some w here e lse.o The l ib rar ian s du t ies inc lude p repar ing ma chine inpu ts as d i re c ted by t heˇĄprogra m mers, submi t t i ng and p ic k ing up co mpu ter runs; and f i l ing a l l ou tpu ts.„ h Th is tea m o f t h ree may be augmen ted by o ther people, such as:o (1) Progra m mers w h o a re spe c ia l is t s in a g iven area.o (2) Less senior p rogra m mers w ho code a spe c i f i c po r t ion o f t he sys te mdes igned by t he ch ie f or t he backup progra m mer.„X There is no sure l im i t t o t he s ize o f such a t ea m, bu t s i x t o e igh t, byconsensus and exper ien ce t hus far, seems t o be t he t op o f t he range.„h The idea o f t he Chie f Program mer Team w a s bo rn as a resu l t o f t he search forbe t ter, m ore e f f i c ien t w ays o f produ c ing co mplex progra ms f ree o f e r ro rs.o Mam mo th unde r ta k ings, such as IBM ¦s OS/360, had made c lear t ha t w aysˇmus t be found to dra ma t i ca l ly i mprove t he qual i t y and t o redu ce t he cos t infu tu re sof t wa re developmen t e f fo r t s.o The th rus t o f t he t ea m con cep t is t ha t t hose goals o f qual i t y and e f f i c iencycan be ach ieved t h rough a ve ry t i gh t , d is c ip l ined o rganiza t ion o f a sma l lnumber o f h igh ly mo t iva ted people ve ry exper ienced and sk i l led in a l l aspec tso f progra m develop men t, f rom ana lys is do wn th rough design, code, t es t , anddocu men ta t ion.o In keeping t he nu mber o f people smal l, t he hu man co m munica t ion problems(and therefore the progra m co m munica t ion prob lems) cou ld be d ras t i ca l lyredu ced.„X Jus t co mpare the poss ib le in te r faces a mong, say, s i x people asopposed to th i r t y!„ h Bu t s imp ly choosing t op people and o rganizing t he m in a smal l g roup is no t enough.They need be t ter t oo ls w i th w h i ch t o w o r k:o (1) Developmen t Suppo r t L ibra ry or SW Conf igura t ion t oo ls.o (2) Top-do wn develop men t, inc lud ing design, code, t es t and docu men ta t iont oo ls.o (3) St ruc tu red prog ra m ming, Objec t or ien ted te chnologies, or UML t oo ls.o (4) These k ind o f t oo ls a re no w re co m mended, o f cou rse, w ha tever t he

organiza t iona l s t ru c tu re is.„ h As t he Chie f Program mer Team con cep t is t r ied by more and more o rganiza t ions, i tw i l l inev i t ab ly be re f ined and w i l l lead t o o ther ideas and t oo ls.o One na tu ra l ou t g ro w t h is t he use o f a " tea m o f t ea ms," w h e re a la rge prob le mis b roken do wn in a h iera rch i ca l manner, and ma jor subsys te ms ass igned t oindiv idua l t ea ms w h i ch are responsib le t o a "h igher-leve l " t ea m, w h i ch is int u rn responsib le for t he sys te m as a w h o le.

Change control. Baseline documents. Control procedures. Chapter06_1 pagini 41-46

Change Control• Choose your change control procedure thoughtfully.o Too much control will suffocate you; too little and you will drift.• Don’t build a change control empire in which there are volumes of proceduresdescribing how to handle any conceivable change.o Think about the critical items over which you really need control, and leave therest for day-to-day management action.3.1 Baseline Documents• First, you must decide what to control against, that is, what are the things you wantto 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 documents fine pieces of work in the firstplace and set up your procedures to control changes to them, then it’s hard to gowrong.o Conversely, if your baseline documents are shallow and poorly done, or if youfall 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 andare used to guide production of the program system.o If you are responsible for maintenance or for more versions of the systembeyond the initial delivery, then (3) The Delivered Program System becomesa new baseline.o In other words, in working on a second or third or n-th version of the programsystem, you may use the last delivery as the baseline.• Here, however, we will discuss only a single-delivery development cycle

Cont ro l Procedures„h I f w e agree on con t ro l l ing change agains t t he Proble m Spec i f i ca t ion and the DesignSpec i f i ca t ion, w e can no w cons ider a s imp le con t ro l me chanism t ha t you can t a i lo rt o f i t your needs.„h Whenever an ind iv idual sees a need for a change tha t he th in ks may a f fe c t one oft he basel ines the fo lo w ing s teps are t o be a c co mpl ished:o (1) He p roposes a fo r mal change.o (2) The Analys is and Design Group analyzes t he proposed change andre co m mends adop t ion or re je c t ion.

o (3) The re co m menda t ion is t hen sub mi t t ed to t he Change Con t ro l Boardw h i ch m akes i t s de c is ion, sub jec t t o over r ide by e i t her you or t he cus to mer.o (4) The Analys is and Design Group docu men ts t he dec is ion, and thechange, i f adop ted, is i mp le men ted. No w le t ¦s t ake a c loser loo k a t ho w t h is procedure m igh t w o r k.ˇA c tua l ly t he fuc k ing procedure w o r ks in t hese s teps:

(1) Proposing a change.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.(2) Investigation.

o All proposed changes are investigated by the Analysis and Design Group.o One investigator is assigned to any given proposed change. The investigator scans the proposal to get an idea of its importance

and impact, and then schedules it for a decision at a future meeting(usually the next scheduled meeting) of the Change Control Board.o If the change is urgent, a special meeting may be called as soon as theinvestigator has enough information to make a recommendation.

(3) Kinds of changes.The investigator may put the change into either of two categories:„X Type 1 - if the change affects either of the baseline documents orwould cause a cost, schedule, or other impact.„X Type 2 if the change affects neither baseline and has negligible cost,schedule, or other impact. (4)Change Control Board.o The board should be comprised of representatives from various projectgroups.o At periodic meetings (say, once a week) the board should consider allscheduled change proposals.o The board discusses each change and decides how to dispose of it.o Project Manager will have to decide whether: (a) the board will operatedemocratically by voting on each issue or (b) whether it will allow the chairmanto make the decision after hearing the arguments.

(5)Types of recommendations.o If the board agrees with the investigator that a change is a Type 2, the changeshould be automatically accepted and no further board action is necessary.„X It is treated following the Bug Fixing Procedure.o If it is a Type 1, it must recommend to you how to dispose of the change.There are two possibilities:„X Acceptance of the change and an indication when the change shouldbe made (immediately or in some future version of the program).„X Rejection of the change. (6) Customer directed changes.o Some changes will be insisted on by the customer.o They must still be investigated, considered by the board, their cost and impactestimated, and formally approved by the customer.o It is always the customerˇ¦s right to override any decision by the board, asresult, appropriate contract changes are negotiated.

(7) Implementing a change.

Depending on the boardˇ¦s recommendation for a Type 1 change, twoconcluding actions are possible:o If the board recommends rejection, the proposal is logged as closed.o If the board recommends adoption,„X (1) The investigator writes up a summary of the change, its cost, andthe schedule for making the change.„X (2) The package is then given to PM (Project Manager) for signature.„X (3) PM signs it.„X (4) If there is a cost or schedule impact, PM sends the package to thecustomer for approval.„X (5) When the customer approves it in writing, the investigator finallydistributes to all concerned a written description of the change.„X (6) Now the change can be implemented by the programmers.

The above is a formal procedure.

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 as critical as 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 takeover the new system.

Didn't fine this is the next best thingTest Executives

Most program systems include some form of control program, or test executive. (1) In bottom-up testing

o A test executive is a modified version of the eventual full executiveprogram.o It begins as a simplified, perhaps only a skeletal form of the ultimate program.o It’s written early to provide a framework for integration testing.o Some test executives contain "dummy" modules or "stubs," that aregradually replaced as their "real" counterparts emerge from module test.o The stubs may do little more than record and print an indication that they havebeen invoked. For example they may perform some simple operation in imitation of

what the real module will do when it is eventually inserted it into thesystem.o As stubs are replaced by real modules, the program system begins to takeshape.

(2) In top-down testing, the test executive is essentially the code for the higherlevel("system") modules.

Some test executives contain special test aids that are removed during the finalstages of integration test.o (1) One such test aid may be a trace program to keep track of sequences ofevents within the system for later analysis.o (2) Another aid is a program to provide displays or "snapshots," of keycomputer registers or storage areas at strategic times. This kind of test aids are called Debuggers and they usually are part of

the Program Developing Tools.o An example of a test executive used in the early stages of development of"real-time" systems is a non-real-time version of the system’s control program.Similarly, a single-processor control program is often written prior todevelopment of a full multiprocessing capability.

A test executive can be complex, but as a rule it should be kept simple for tworeasons:o (1) First, its value lies partly in having it ready early, before the "real" executiveprogram is finished. If you put too much into the test executive, it won’t beready much sooner than the real one.o (2) Second, the more complex you make the executive, the tougher it will beto separate its problems, or bugs, from those of the modules that you aretrying to test.

The contract. The contract template. Types of contracts. (S3) Chapter03 - pagini 9-13

T he Con t ra c t„h I t ¦s absolu te l y necessa ry. Hal f t he hor ror s tor ies abou t p rogram mingˇ invo lve e i therbad c on t ra c ts or no con t ra c t a t a l l.„ h A con t ra c t is an agreemen t be t ween you and a cus to mer tha t you w i l l do a c e r ta injob w i t h in spec i f i c cons t ra in ts for so mu ch m oney.„X Don ¦t opera te on t he bas is o f verbal ag reemen ts or c asual me mos,ˇ even i fyour cus to mer happens t o be your buddy do wn t he hal l and you bo th w o r k fort he same organiza t ion.„X Wi th in your c o mpany, you may c a l l your docu men t a §le t te r o fˇ unders tanding ¨̌or some th ing s i m i lar, w h i ch sounds f r iendl ier t han §con t ra c t. ¨ˇ ˇ„h In any c ase, you need a fo r mal w r i t t en s ta te men t c lea r l y sho w ing w ha t t hec us to mer w an ts and w ha t you agree to prov ide.„h Opera t ing w i t hou t such an agreemen t is lunacy for bo th pa r t ies, as manysof t w a re pro je c t m anagers and jus t as m any cus to mers have found ou t.1.5.1 Con t ra c t Templa te

„h Usua l ly a c on t ra c t have t o cover t he fo l lo w ing essen t ia ls e le men ts:„h (1) Scope o f t he w o r k.„h What is t he job t o be done?„h I f t he job def in i t ion is t oo vague, maybe you need t w o con t ra c t s:„h One t o de f ine t he job„h One t o w r i t e progra ms.„h (2) Schedule and del iverables.„h What spec i f i c i te ms (progra ms, docu men ts) a re t o be del ivered t o t hec us to mer?„h When are t hey t o be del ivered?„h Where a re they t o be del ivered?„h In w ha t fo r m (diske t tes, CDs, d raf ts or c lean docu men ts)?„h Ho w m any cop ies?„h (3) Key peop le.„h Who is au thor ized t o approve changes and ac cep t t he f in ished produc t?„h (4) Revie w schedu le.„h When and ho w shal l t he cus to mer be given rev ie ws and repo r t s o fprogress?„h What is requ i red o f t he c us to mer i f he d isapproves o f a repo r t?„h (5) Change con t ro l p ro cedures.„h What w i l l be t he me chanis m for deal ing w i t h i te ms t he c us to mer demands,w h i ch you cons ider changes t o the or ig ina l w o r k scope?„h (6) Tes t ing cons t ra in ts.„h Where and under w h ose c on t ro l w i l l c o mpu ter or o ther t es t t i me beob ta ined?„h During w h i ch w o r k sh i f t s?„h Exac t ly w ha t pr ior i t y w i l l your tes te rs have?„h (7) Ac cep tan ce c r i te r ia.„h What are t he spec i f i c quan t i ta t ive c r i t e r ia t o be used in judging w he ther yourf in ished produc t is a c cep table?„h (8) Addi t ional c ons t ra in ts.„h Are the re i te ms w h i ch m ay be pecu l iar t o your w o r k ing envi ronmen t?„h Are you t o use cus to mer personnel? I f so, w ha t c on t ro l do you have overt he m?„h Are the re spec ia l da ta secur i t y p roblems?„h Is t he cus to mer requi red t o supp ly t es t da ta? I f so, w ha t k inds o f da ta, inw ha t fo r m, w h en, and ho w c lean?

„h (9) Pri ce.„h What is your pr i ce for do ing t he job?„h Is i t f i xed or var iab le?„h I f var iab le, under w ha t c i r cu ms tan ces?„h A l l o f t hese i te ms and m ore w i l l be addressed in mu ch or less de ta i l in t he con t ra c t .„h The las t i te m, pr i ce, is handled in a good many d i f fe ren t w ays depending on t he t ypeo f con t ra c t ag reed upon.„h Here is a br ie f su m ma ry o f fo r mal c on t ra c t t ypes.1.5.2 Types o f Pr i ces„h (1) Fi r m Fixed Pri ce (FFP)o (a) The pr i ce is se t and no t subjec t t o change even i f you have es t i ma tedbad ly.o (b) Th is is t he m os t r is ky t ype o f c on t ra c t t o use on a progra m ming job.o (c) I t shou ld never be used w i t hou t a t leas t a ve ry c lear s ta te men t o f w o r k, nofuzzy areas, no dangl ing def in i t ions.o (d) Many a pro jec t has exper ienced severe losses opera t ing under such ac on t ra c t .„h (2) Fixed Pr i ce w i t h Escala t ion (FP-E)o (a) The pr i ce is se to (b) Some a l lo wan ce is m ade for bo th up ward and do wn w ard adjus t men ts inc ase ce r ta in t h ings happen, for exa mple, labor ra tes or ma ter ia l cos tschange.„h (3) Fixed Pr i ce Incen t ive (FPI)o (a) A t a rge t pr i ce is se to (b) Some fo r mulas are es tab l ished t ha t a l lo w t he c on t ra c to r:„h (1) A h igher per cen tage o f p rof i t i f t he c on t ra c to r ex ceeds selec tedta rge ts, (such as cos t)„h (2) A lo wer per cen tage o f p ro f i t (even a loss) i f t he c on t ra c to r m issesthe selec ted t a rge ts.„h (4) Cos t Shared (CS)o (a) Th is t ype o f c on t ra c t re imburses t he c on t ra c tor for pa r t or a l l o f h is c os tsbu t a l lo ws no pro f i t , or fee.o (b) I t ¦s used e i the r:ˇ„h (1) For research w o r k w i t h nonprof i t o rgan iza t ions„h (2) In jo in t p ro je c ts be t ween t he cus to mer and t he con t ra c tor w he re

t here is an t i c ipa ted benef i t t o the con t ra c tor.„X For exa mple, the job may resul t in a produc t for w h i ch t hec on t ra c to r w i l l have t he exc lus ive r igh t to se l l.„ h (5) Cos t Plus Incen t ive Fee (CPIF)o (a) The con t ra c tor w i l l be paid a l l h is c os ts p lus a feeo (b) The fee var ies depending on:„h (1) Ho w c lose t he c on t ra c to r c o mes t o mee t ing t he es tabl ished t a rge tc os ts„h (2) Ho w w e l l he does in o ther a reas spel led ou t in t he con t ra c t .o (c) The c r i t e r ia w h i ch de te r m ine t he fee mus t be objec t ive and measurab le„h (6) Cos t Plus A ward Fee (CPAF).o (a) Is s im i lar w i t h CPIFo (b) The di f fe ren ce is t he c r i t e r ia w h i ch are more subjec t ive and are w e ighedby a Board o f Review.„h (7) Cos t Plus Fixed Fee (CPFF)o (a) The con t ra c tor is pa id al lo wab le cos ts and a se t fee.„h (8) T i me & Ma ter ia ls (T &M)o (a) The con t ra c tor is pa id for labor hours ac tual ly w o r ked and the c os t o fma ter ia ls used.„h (9) Labor Hour (LH)o (a) Labor hours are paid for, bu t no th ing e lse.„h (10) Level o f Effo r t (LOF)o (a) Is s im i lar w i t h Labor Hours t ype o f con t ra c to (b) The e f fo r t is paid, bu t no th ing e lse.„h Conc lus ions:o (1) The las t t w o con t ra c t t ypes (Labor hours and Level o f e f fo r t ) a re pre t t ymu ch r is k-f ree for t he con t ra c tor. He prov ides people t o do as t he c us to merdi re c ts.o (2) The o ther c on t ra c t t ypes involve va ry ing degrees o f r is k for the c on t ra c to rand t he cus to mer.o (3) When t he del iverable produ c t c an be w e l l de f ined in advance, t hec on t ra c to r m ay propose a f i xed pr i ce and a h igh fee.o (4) When t he end produc t is poor ly def ined or sub je c t t o change, a cos t t ypeo f con t ra c t is appropr ia te, f ro m the con t ra c tor ¦s poin t o f v iew. His prof i tˇ is lo wer, bu t so is h is r isk.

Ciclul de viata al unui proiect software. Principii. Modele Chapter01.pdf - pagini 11-14

LIFE CYCLES IN A SW PROJECT DEVELOPMENT PROCESS„h Regard less o f ho w sof t wa re develop men t is ach ieved, i t mus t p roceedth rough ce r ta in s teps or develop men t phases„h Af te r sof t w a re is developed i t mus t be suppo r ted (i.e., ma in ta ined).o The c o mb ina t ion o f sof t w a re develop men t phases and suppo r tac t iv i t ies phases is refe r red t o as t he Sof t wa re L i fe Cycle(*) SWLC orSWPLC (Sof t wa re Pro je c t L i fe Cycle)„h ( *)Def in i t ion: SW Li fe Cycle is t he abs t ra c t des cr ip t ion o f t he s t ru c tu red,me thodolog i ca l develop men t and modi f i ca t ion pro cess t yp i ca l l y sho w ing t hema in s tages in produc ing and m ain ta in ing execu tab le sof t w a re V (JohnˇM cDer m id, §The Sof t w a re Engineer ¦s Reference Book ¨)ˇ ˇ ˇo SW Li fe Cycle is pa r t o f SW Developmen t Process (P), in fac t is anac t iv i t y o f t he m en t ioned pro cess„h There are a nu mber o f so f t wa re developmen t t e chn iques o rganiza t ions canuse, each having a di f fe ren t impa c t on sof t w a re c os ts„h In prac t i ce, t he log i c o f t e mpora l o rganiza t ion o f t he ac t iv i t ies dur ing t he SWProje c t Developmen t Process (P) imposed the developmen t o f somete mpla tes (mode ls) for pro jec t l i fe cyc les (PLC ¦s) appl i cab le t o d i f fe ren tˇ t ypeso f p ro jec t s.„h The m os t kno wn l i fe cyc le models are:

THE WATERFALL L IFE CYCLE„h WATERFALL LIFE CYCLE V is t he c lass i ca l l inear model, t he o ldes tˇ l i fe cyc le.Appl i cab le t o:o Lo w c o mplex i ty p ro jec t so Very w e l l in i t ia l def ined requi remen ts

5.2 THE §V ¦ L IFE CYCLEˇ ˇo §V ̈LIFE CYCLE V a lso a l inear cyc le. Requi res:ˇ ˇ ˇ„X A se t o f ve ry w e l l in i t ia l spec i f ied requi re men ts„X An user w i th d isposab i l i t y t o co l labora te and t o par t i c ipa teef fe c t ive ly t o t he pro jec t spec i f i ca t ion pro cess

5.3 THE PROTOTYPINGo PROTOTYPING V re co m mended in t he case o f p ro je c ts in w h i ch t heˇc l ien t c an ¦t pa r t i c ipa te, or is no t in te res ted in produ c ing a l is t o f w e l lˇdef ined requi remen ts„X Ana lyze and even design a c t iv i t ies are i te ra t ive„X The resul t is an §obta in ing-va l ida t ion-c o r re c t ion ¨ cyc leˇ ˇappl i cab le to produc t p ro to type„X Requi res spec i f i c rap id and e f f i c ien t p ro to types develop ing t oo ls„X I t can be used as a pre l im ina ry develop men t cyc le, fo l lo wed byano ther t ype o f cyc le for the f ina l ly p roduc t develop men t

5.4. EVOLUTIONARY MODEL„h Based on vers ions„h Each vers ion is der ived quic k l y„h Th is pro cess is na med i te ra t ion„h Each vers ion is send t o the cus to mer w h i ch ana lyze i t an supp l iesfeed bac k„h Each i te ra t ion is based on a Water fa l l L i fe Cycle„h RUP (Ra t ional Developmen t Process) is based on t h is model

5.5 THE SPIRAL LIFE CYCLE (BOEHM)o SPIRAL LIFE CYCLE (Boehm) V re co m mended for pro jec t s:ˇ„X Wi th high developmen t r is ks„X Wi th high co mplex i t y„X Which requ i res ve ry spec ia l t e chnolog ies„X For w h i ch is no t p re c ise ly kno wn t he moda l i t y o f so lv ingc us to mer requi remen ts„X Are ve ry expens ive„X Spi ra l Cycle c an be c ons idered as a repe t i t ion o f l inear cyc les,each ne w cyc le added t o the spi ra l, adding in t he same t i mene w fac i l i t ies to t he produc t

5.6 FORMAL SYSTEM DEVELOPMENT Uses ma the ma t i ca l m e thods

Formal spec i f i ca t ion based on Step w ise Ref ine men t

Formal approach, no t es ts are necessa ry

Usefu l for non-in terac t ive sys te ms, bu t requi re expe r t s

5.7 IEEE/EIA 12207 “STANDARD FOR INFORMATION TECHNOLOGY -SOFTWARE LIFE CYCLE PROCESSES

IEEE/EIA 12207 “STANDARD FOR INFORMATION TECHNOLOGY -

SOFTWARE LIFE CYCLE PROCESSES” is a gener i c sof t w a re pro cessused as a f ra me w or k for m any sys te ms c u r ren t ly be ing developed orsuppor t edo IEEE/EIA 12207 def ines a se t o f re co m mended developmen t ac t iv i t iesand docu men ta t ion a l te rna t ives for sof t w a re in tensive sys te ms.o Th is s tandard is co mpa t ib le w i t h a number o f d i f fe ren t sof t w a redevelopmen t me thods, inc lud ing t he w a ter fa l l m ode l.o IEEE/EIA 12207 def ines a s tandard sof t w a re h ie rarchy and anassoc ia ted t e r minology (co m mon ly used for c o mplex DOD sof t w a reand o ther co mplex MIS sys te ms)

Metode de estimare a dimensiunilor proiectelor SW. Principii. Prezentati metoda Wideband-Delphy - Chapter04_1 pagini 24-25

Size Est ima t ing Me thodsTo measure SW pro jec ts di f fe ren t m e t r i cs are used.o (1) Size or ien ted m e t r i cs Main ly cons is t ing in es t i ma t ion o f t he number o f sour ce l ine ofc ode.o (2) Func t ion or ien ted m e t r i cs Main ly cons is t ing in es t i ma t ing o f t he c o mplex i t y o f t hefunc t ions rea l ized by t he sof t w a re produc t resul ted f rom the developmen t pro cess.Size or ien ted m e t r i cs use as measure t he number o f sour ce l ine o f code or the nu mber o f de l ivered sour ce ins t ru c t ions.Classi ca l m e thods for s ize es t i ma t ion o f t he SW pro jec t s based on t hese me t r i cs:o (1) Wideband-Delphi Me thodo (2) Fuzzy-Logi c Me thodo (3) Standard-Componen t Me thod

Wideband-Delphi Me thodThe Wideband-Delphi es t i ma t ing m e thod w as or ig ina ted by t he RandCorpora t ion and ref ined by Boehm.o (1) I t ca l ls for severa l eng ineers t o ind iv idual ly p roduce es t i ma tes.o (2) Then uses a Delphi pro cess t o converge on a consensus es t i ma te.The pro cedure is essen t ia l l y as fo l lo ws

(1) A g roup o f expe r t s is each g iven t he progra m’s spec i f i ca t ions and an es t i ma t ion fo r m.(2) The me mbers o f t he g roup m ee t to d iscuss pro jec t goals, assump t ions, and es t i ma t ion issues.(3) The me mbers o f t he g roup t hen each anony mous ly l is t p ro jec t t as ks and es t i ma te s ize.(4) The es t i ma tes are given t o t he es t i ma te m odera tor, w ho t abula tes t he resul t s and re tu rns t he m to t he expe r t sFor each expe r t on ly personal es t i ma te is iden t i f ied Al l o ther’s es t i ma tes are anony mous.There is a lso iden t i f ied t he median es t i ma t ion.(5) The expe r t s m ee t to d iscuss t he anony mous resul t s.(6) The expe r t s each even tual ly rev ie w the t as ks t hey have def ined and t he i r s ize es t i ma tes.

(7)The cyc le c on t inues a t s tep 3 un t i l t he es t i ma tes c onverge t o w i t h in an ac cep table range.

(8)

Metode de estimare a costurilor bazate pe decompozitie. Descrieti o astfel de metoda - Chapter04_2 pagini 16-19

Deco mposi t ion Models Decomposi t ion m odels par t i t ion t he pro je c t in smal l t as ks (elemen ts)

w h i ch are separa te ly evalua ted. In t h is ca tego ry are inc luded evalua t ion models as:

o (1) Effo r t Es t i ma t ion Model (EE Model).o (2) L ine o f Code Model (LOC Model).o (3) Func t iona l Poin t Model (FP Model).

Effort Estimation Model (EE Model)• EE Model (Effort Estimation Model) is a decomposition model.• EE Model construction consists in the following steps:o (1) The project is decomposed in functional tasks (features). The functional tasks are those corresponding to project

features.o (2) Each functional task is then decomposed in subtaskscorresponding to project development life cycle phases. The subtasks corresponding to life cycle phases are:

analyze, preliminary design, detailed design, codification,test. (Fig. 5.5.1.1.a)

o (3) The costs for each subtask of each feature are estimated(usually in hours).o (4) Then are determined features’ costs, phases’ costs and totalcost.Advantages:

(1) The phase costs of each feature can be clearly emphasized.

o This thing is very important because in many situations the costsdiffer from a phase to another.o For example, usually,cost_analyze>cost_designer>cost_coder>cost_test>cost_delivery(in money man*day)

(2) The evaluation method is simple, very efficient and achieves to resultswhich are affected by a reduced error coefficient.Disadvantages:

(1) The method requires evaluators with significant experience and a highdegree of professionalism.

Metode de estimare a dimensiunilor proiectelor SW. Principii. Prezentati metoda Fuzzy-Logic Chapter04_1 pagini 25-27

Size Estimating Methods• To measure SW projects different metrics are used.• A metric for a SW project is in fact a method permitting to characterizefrom quantitative point of view the product.o In other words a metric permits a quantitative estimate a SW project.• There are 2 categories of metrics used in SW project evaluation:o (1) Size oriented metrics Mainly consisting in estimation of the number of source line of

code.o (2) Function oriented metrics Mainly consisting in estimating of the complexity of the

functions realized by the software product resulted from thedevelopment process.Summary

Fuzzy-logic MethodPutnam describes the fuzzy-logic estimating method where:o (1) Estimators assess a planned product.o (2) Then roughly judge how its size compares with historical data on

prior products. [Putnam].

• For example, you could break the sizes of all your organization’spreviously developed products into ranges and subranges sizecategories

With sufficient data, these gross size ranges can be subdivided into moredetailed categories (subranges)

• One problem with the fuzzy logic method is that the size of majorprogramming applications has historically grown by about an order ofmagnitude every 10 years.• Reasonably accurate estimates of the very largest category are thusparticularly important.• Unfortunately, any gross sizing method will not likely be of much help inestimating a new program that is much larger than anything you havepreviously built.• To handle this situation, you would have to subdivide the new product intosmaller components and estimate each component.