1. 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 PROJECT
3.1 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

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

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

4. 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
summary
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 the
other 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 the
dimension, the complexity and the application domain of the SW product
to be developed

5. (b) Elaboration of the Project Development Plan based on
Documentation 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 Configuration
Management 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 (Problem
Specification, 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 the
multitude of the problem requirements, from which the optimum solution
had 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
documents
referring to:
The HW components of the system and their interconnection modalities
SW configuration elements and their assignation to the HW components

6. 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 of
their 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
which
details 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
is
accomplished 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
SW
elements 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)

7. (9) SW Installing – presume installation and configuration of the SW
product on
the 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 user
and 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 outline
presented in this course.
o Use it if you’ll find it helpful, but by all means modify it to suit your
needs, even your temperament. After all, you have to live with it.
• The Project Plan is divided into the following sections, which are
summarized in succeeding paragraphs:
o (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

8. o (9) Installation and Operation Plan
o (10) Resources and Deliverables Plan
o (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 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.
o (7) It summarizes the entire plan by giving a capsule description of the
detailed plan elements that follow the Overview.
1.1 OBJECTIVE
The 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 DETAIL
Give a brief description of the objectives of each of the remaining sections of
the 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 one
presented in this course or another.
„h For each phase of the Life cycle describe the primary and the secondary
objectives.
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 Test
Phase, you should all be talking about the same thing.
o Unfortunately this rarely happens on a project, and that’s a crime. It
leads to much confusion and misunderstanding that could easily be
avoided.
2.1 OBJECTIVE
The objective of this section is to define the programming development effort in terms of
a series of time-slices called “phase”.
2.2 DISCUSSION
Define your development cycle and, briefly, each phase making up the cycle. Include an
illustration but include calendar dates. Establish basic definitions
and points out that the remaining sections of the plan are tied to these definitions. If you
are planning multiple releases, show how they are scheduled in a series of overlapping,
essentially identical, development cycles.
2.3 DETAIL
For each phase list primary and secondary objectives and define each objective as
rigorously as possible

9. 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
7.3.4 Test Plan
„h This section describes the tools, procedures, and responsibilities for
conducting 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 of
managementˇ¦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 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.
„h The Documentation Plan is a gathering place in the Project Plan for the
descriptions 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.

10. 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 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 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
„h 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.
„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 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.

11. 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, and
techniques to project activities in order to meet or exceed stakeholder needs and
expectations from a project.”
The manager’s job is:
o (1) To plan an activity
o (2) To see that it is carried out.
But from the instant the project begins, he must contend with the fact that humans
tend not to solve problems until they become crises.
o Only a crisis seems worthy of real attention
o Whether it’s a strike deadline, an international diplomatic standoff, a human
injustice, nothing gets resolved until something overflows.
o And of course, computer programs don’t get serious attention until the
deadline 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 to
solve 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 been
asked 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 multimedia
products), so teams can delete features if they fall too far
behind.
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 projects
based on these metrics:
o (1) Wideband-Delphi Method
o (2) Fuzzy-Logic Method
o (3) Standard-Component Method
Wideband-Delphi Method
„h The Wideband-Delphi estimating method was originated by the Rand
Corporation and refined by Boehm.
o (1) It calls for several engineers to individually produce estimates.

12. o (2) Then uses a Delphi process to converge on a consensus
estimate.
„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 project
tasks and estimate size.
„h (4) The estimates are given to the estimate moderator, who
tabulates the results and returns them to the experts, as illustrated in
figure 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 defined
and their size estimates.
„h (7) The cycle continues at step 3 until the estimates converge to
with an acceptable range
For reasonably large programs, the estimators make simultaneous
estimates for several product components.
o At the end of the estimating process, these estimates are combined
to produce the total final estimate.
• The estimating process is run by a moderator who should always be
careful 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 skilled
moderator can facilitate very informative discussions.
o The person who made a particularly high or low estimate is
sometimes willing to explain why that value was picked.
o The resulting discussions often shed light on the problem and
surprisingly often convince the other engineers to change their
estimates.
o While confidentiality will often become a non-issue, the decision to
reveal 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 the
functions implemented by the SW product to be developed.
„h There are 2 categories of function oriented metrics:
o (1) Functional points oriented metrics

13. o (2) Feature points oriented metrics
„h There are also some specific estimation methods based on these
metrics:
o (1) Function-Point Method
o (2) Characteristic-Point Method
o (3) Proxy-Based Method
Caracteristic-Point Method
„h The metrics based on characteristic points was proposed by C.A. Jones
The 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 characteristic
point.
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 (Table
4.3.2.3.a.).
„X There are versions of method in which weights differs function
of program complexity (simple, average, complex)
„X The determined Total can be adjusted in a similar manner as in
functional point method:
o (5) Establish the weights of the 14 influence factors.
o (6) Calculate the value of the complexity adjustment factor (SIFSum
of 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

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

15. 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.
• In most situations is recommended choose (b) over (a).
The real impor tance, ho wever, is not in the exact number of boxes on the
organization char t nor their titles but:
o (1) The PM (projec t manager) must account for all jobs that have to be done
and do it in a w or kable w ay.
o (2) PM must be sure that every member of the organization kno ws both his
and other people ¦s objectives.ˇ
„h The remainder of this section describes the functions of the various groups sho wn in
Figure 6.2.1.a. (b) and ends by considering some typical numbers of people in
the various roles
Team Organization. Chief Program mer Team
„h The team approach is a w ay of organizing around a group of specialists.
o The embodiment of the approach in program ming is called the Chief
Program mer Team.
„h IBM ¦s Harlan Mills, originator of the concept, co mpares the Chief Program mer Teamˇ
to a surgical team, w here a chief surgeon plans and performs an operation w i th vital
help and backup from highly skilled assistants, both surgeons and nonsurgeons.
o What follo ws is an overvie w of ho w this idea is put into practice.
2.2.1 Ho w It Works
„h The core of a Chief Program mer Team w ould normally be three people:
o (1) Chief programmer.
o (2) Backup program mer.
o (3) Technical librarian.
„h (1) The Chief Programmer
o Chief programmer is the technical manager responsible for the development
of the program system.
o This person w ill normally w ri te at least the critical "system" modules X that is,ˇ
the portion of the program system exercising con trol over, and interfacing
w i th, all the lo wer-level " wor king" modules.
o Depending on the to tal size and co mplexity of the job, he and the backup
might w ri te the entire program system.
„X Where others are involved, the chief program mer assigns w or k to the m
and integrates all their modules w i th his o wn.
o The chief progra mmer is the main interface w i th the customer, at least in

16. technical mat ters
„X There may be a managerial counterpart w ho handles non-technical
tasks.
„h (2) The backup program mer
o Assists in any w ay assigned by the chief program mer,
„X His prima ry func tion is to understand all facets of the system as w ell as
the chief program mer does.
„X His second function is to be ready at any ti me to take over as chief
program mer.
o The backup program mer is nor mally assigned specific portions of the system
to design, code, and test, as w ell as other duties for example, preparation of
a test plan.
„h (3) The technical librarian (configurator)
o The technical librarian is a different person from the "general librarian" w ho
runs the project ¦s general library and has the nor mal responsibility usuallyˇ
associated w i th a library.
o The technical librarian is responsible for running the Development Support
Library or to manage the SW Configuration Tool used by the organization
(CVS - Control Version System, Continuous, ClearCase, CM Synergy, et c).
„X This person is a full and vital me mber of the team, not on part-ti me loan
from some where else.
o The librarian s duties include preparing machine inputs as directed by theˇĄ
program mers, submit ting and picking up co mputer runs; and filing all outputs.
„h This team of three may be augmented by other people, such as:
o (1) Programmers w ho are specialists in a given area.
o (2) Less senior program mers w ho code a specific portion of the syste m
designed by the chief or the backup program mer.
„X There is no sure limit to the size of such a team, but six to eight, by
consensus and experience thus far, seems to be the top of the range.
„h The idea of the Chief Program mer Team w as born as a result of the search for
bet ter, more efficient w ays of producing co mplex programs free of errors.
o Mam mo th undertakings, such as IBM ¦s OS/360, had made clear that w aysˇ
must be found to dramatically improve the quality and to reduce the cost in
future soft ware development efforts.
o The thrust of the team concept is that those goals of quality and efficiency
can be achieved through a very tight, disciplined organization of a small
number of highly mo tivated people very experienced and skilled in all aspec ts
of program development, from analysis do wn through design, code, test, and
documentation.
o In keeping the number of people small, the human com munication problems
(and therefore the program com munication problems) could be drastically
reduced.
„X Just co mpare the possible interfaces among, say, six people as
opposed to thir ty!
„h But simply choosing top people and organizing them in a small group is not enough.
They need bet ter tools w i th w hich to w or k:
o (1) Development Suppor t Library or SW Configuration tools.
o (2) Top-do wn developmen t, including design, code, test and documentation
tools.
o (3) Struc tured progra mming, Object oriented technologies, or UML tools.
o (4) These kind of tools are no w recom mended, of course, w ha tever the

17. organizational stru c ture is.
„h As the Chief Program mer Team concept is tried by more and more organizations, it
w ill inevitably be refined and w ill lead to other ideas and tools.
o One natural outgro w th is the use of a " tea m of teams," w h ere a large problem
is broken do wn in a hierarchical manner, and major subsystems assigned to
individual teams w hich are responsible to a "higher-level" team, w hich is in
turn responsible for the system as a w hole.
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 procedures
describing how to handle any conceivable change.
o Think about the critical items over which you really need control, and leave the
rest 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 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 documents fine pieces of work in 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
„h If w e agree on controlling change against the Problem Specification and the Design
Specification, w e can no w consider a simple control mechanism that you can tailor
to fit your needs.
„h Whenever an individual sees a need for a change that he thinks may affect one of
the baselines the folo wing steps are to be acco mplished:
o (1) He proposes a formal change.
o (2) The Analysis and Design Group analyzes the proposed change and
recom mends adoption or rejec tion.

18. o (3) The reco mmendation is then submit ted to the Change Control Board
w hich makes its decision, subject to override by either you or the custo mer.
o (4) The Analysis and Design Group documents the decision, and the
change, if adopted, is implemented.
No w let ¦s take a closer look at ho w this procedure might w o r k.ˇ
Actually the fucking procedure w or ks in these steps:
(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 the
investigator 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 or
would 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 project
groups.
o At periodic meetings (say, once a week) the board should consider all
scheduled 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 operate
democratically by voting on each issue or (b) whether it will allow the chairman
to 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 change
should 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 should
be 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 impact
estimated, and formally approved by the customer.
o It is always the customerˇ¦s right to override any decision by the board, as
result, appropriate contract changes are negotiated.

19. (7) Implementing a change.
Depending on the boardˇ¦s recommendation for a Type 1 change, two
concluding 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, and
the 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 the
customer for approval.
„X (5) When the customer approves it in writing, the investigator finally
distributes 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 take
over the new system.
Didn't fine this is the next best thing
Test 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 executive
program.
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 are
gradually replaced as their "real" counterparts emerge from module test.
o The stubs may do little more than record and print an indication that they have
been 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 the
system.
o As stubs are replaced by real modules, the program system begins to take
shape.
(2) In top-down testing, the test executive is essentially the code for the higherlevel
("system") modules.

20. Some test executives contain special test aids that are removed during the final
stages of integration test.
o (1) One such test aid may be a trace program to keep track of sequences of
events within the system for later analysis.
o (2) Another aid is a program to provide displays or "snapshots," of key
computer 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 to
development of a full multiprocessing capability.
A test executive can be complex, but as a rule it should be kept simple for two
reasons:
o (1) First, its value lies partly in having it ready early, before the "real" executive
program is finished. If you put too much into the test executive, it won’t be
ready much sooner than the real one.
o (2) Second, the more complex you make the executive, the tougher it will be
to separate its problems, or bugs, from those of the modules that you are
trying to test.
The contract. The contract template. Types of contracts. (S3)
Chapter03 - pagini 9-13
The Contract
„h It ¦s absolutely necessary. Half the horror stories about program mingˇ
involve either
bad contrac ts or no contra c t at all.
„h A contract is an agreement bet ween you and a customer that you w ill
do a ce r tain
job w i thin specific constraints for so mu ch money.
„X Don ¦t operate on the basis of verbal agreements or casual me mos,ˇ
even if
your customer happens to be your buddy do wn the hall and you both
w or k for
the same organization.
„X Within your co mpany, you may call your document a §letter ofˇ
understanding ¨ˇ
or something similar, w hich sounds friendlier than §contrac t. ¨ˇ ˇ
„h In any case, you need a formal w ri t ten state ment clearly sho wing
w ha t the
customer w an ts and w ha t you agree to provide.
„h Operating w i thout such an agreement is lunacy for both parties, as
many
soft ware project managers and just as many customers have found out.
1.5.1 Contract Template

21. „h Usually a contrac t have to cover the follo wing essentials elements:
„h (1) Scope of the w o r k.
„h What is the job to be done?
„h If the job definition is too vague, maybe you need t w o contra cts:
„h One to define the job
„h One to w rite programs.
„h (2) Schedule and deliverables.
„h What specific items (programs, documents) are to be delivered to the
customer?
„h When are they to be delivered?
„h Where are they to be delivered?
„h In w ha t form (disket tes, CDs, drafts or clean documen ts)?
„h Ho w many copies?
„h (3) Key people.
„h Who is authorized to approve changes and accept the finished
produc t?
„h (4) Revie w schedule.
„h When and ho w shall the custo mer be given revie ws and reports of
progress?
„h What is required of the customer if he disapproves of a report?
„h (5) Change control procedures.
„h What w ill be the mechanism for dealing w i th items the custo mer
demands,
w hi ch you consider changes to the original w o r k scope?
„h (6) Testing constraints.
„h Where and under w hose con trol w ill co mputer or other test ti me be
obtained?
„h During w hich w or k shifts?
„h Exactly w hat priority w ill your testers have?
„h (7) Accep tance cri teria.
„h What are the specific quantitative criteria to be used in judging
w he ther your
finished produc t is acceptable?
„h (8) Additional constraints.
„h Are there ite ms w hich may be peculiar to your w or king environment?
„h Are you to use customer personnel? If so, w ha t control do you have
over
them?
„h Are there special data security problems?
„h Is the customer required to supply test data? If so, w hat kinds of
data, in
w ha t form, w hen, and ho w clean?

22. „h (9) Price.
„h What is your price for doing the job?
„h Is it fixed or variable?
„h If variable, under w hat circumstances?
„h All of these items and more w ill be addressed in much or less detail in
the contra ct.
„h The last item, price, is handled in a good many different w ays
depending on the type
of contrac t agreed upon.
„h Here is a brief summa ry of formal con trac t types.
1.5.2 Types of Prices
„h (1) Firm Fixed Price (FFP)
o (a) The price is set and not subjec t to change even if you have
estimated
badly.
o (b) This is the most risky type of con trac t to use on a programming job.
o (c) It should never be used w i thout at least a very clear statement of
w or k, no
fuzzy areas, no dangling definitions.
o (d) Many a projec t has experienced severe losses operating under such
a
contrac t.
„h (2) Fixed Price w i th Escalation (FP-E)
o (a) The price is set
o (b) Some allo wan ce is made for both up ward and do wn ward
adjustmen ts in
case ce r tain things happen, for example, labor rates or material costs
change.
„h (3) Fixed Price Incentive (FPI)
o (a) A target price is set
o (b) Some formulas are established that allo w the contractor:
„h (1) A higher percentage of profit if the con trac tor exceeds selected
targets, (such as cost)
„h (2) A lo wer percentage of profit (even a loss) if the contrac tor misses
the selected targets.
„h (4) Cost Shared (CS)
o (a) This type of contrac t reimburses the contrac tor for part or all of his
costs
but allo ws no profit, or fee.
o (b) It ¦s used either:ˇ
„h (1) For research w o r k w i th nonprofit organizations
„h (2) In joint projects bet ween the customer and the contractor w here

23. there is anticipated benefit to the contra ctor.
„X For example, the job may result in a product for w hi ch the
contrac tor w ill have the exclusive right to sell.
„h (5) Cost Plus Incentive Fee (CPIF)
o (a) The contra ctor w ill be paid all his costs plus a fee
o (b) The fee varies depending on:
„h (1) Ho w close the contrac tor co mes to meeting the established target
costs
„h (2) Ho w w ell he does in other areas spelled out in the contract.
o (c) The criteria w hich determine the fee must be objec tive and
measurable
„h (6) Cost Plus A ward Fee (CPAF).
o (a) Is similar w i th CPIF
o (b) The difference is the criteria w hi ch are more subjective and are
w eighed
by a Board of Review.
„h (7) Cost Plus Fixed Fee (CPFF)
o (a) The contra ctor is paid allo wable costs and a set fee.
„h (8) Time & Materials (T &M)
o (a) The contra ctor is paid for labor hours actually w o rked and the cost
of
ma terials used.
„h (9) Labor Hour (LH)
o (a) Labor hours are paid for, but nothing else.
„h (10) Level of Effort (LOF)
o (a) Is similar w i th Labor Hours type of contrac t
o (b) The effort is paid, but nothing else.
„h Conclusions:
o (1) The last t wo contract types (Labor hours and Level of effort) are
pret ty
mu ch risk-free for the contractor. He provides people to do as the
customer
direc ts.
o (2) The other contrac t types involve varying degrees of risk for the
contrac tor
and the customer.
o (3) When the deliverable product can be w ell defined in advance, the
contrac tor may propose a fixed price and a high fee.
o (4) When the end product is poorly defined or subject to change, a cost
type
of contrac t is appropriate, from the contrac tor ¦s point of view. His profitˇ
is lo wer, but so is his risk.

24. Ciclul de viata al unui proiect software. Principii.
Modele Chapter01.pdf - pagini 11-14
LIFE CYCLES IN A SW PROJECT DEVELOPMENT PROCESS
„h Regardless of ho w soft ware developmen t is achieved, it must proceed
through ce r tain steps or development phases
„h After soft ware is developed it must be supported (i.e., main tained).
o The co mbination of soft ware development phases and support
ac tivities phases is referred to as the Soft ware Life Cycle(*) SWLC or
SWPLC (Soft ware Project Life Cycle)
„h (*)Definition: SW Life Cycle is the abstra ct description of the
struc tured,
me thodological development and modification process typically sho wing
the
main stages in producing and maintaining executable soft ware V (Johnˇ
McDermid, §The Soft ware Engineer ¦s Reference Book ¨)ˇ ˇ ˇ
o SW Life Cycle is part of SW Development Process (P), in fact is an
ac tivity of the men tioned process
„h There are a number of soft ware development techniques
organizations can
use, each having a different impac t on soft ware costs
„h In prac ti ce, the logic of te mporal organization of the activities during
the SW
Project Development Process (P) imposed the development of some
te mplates (models) for project life cycles (PLC ¦s) applicable to differentˇ
types
of projects.
„h The most kno wn life cycle models are:
THE WATERFALL LIFE CYCLE
„h WATERFALL LIFE CYCLE V is the classical linear model, the oldestˇ
life cycle.
Applicable to:
o Lo w co mplexity projects
o Very w ell initial defined requirements
5.2 THE §V ¦ LIFE CYCLEˇ ˇ
o §V ¨ LIFE CYCLE V also a linear cycle. Requires:ˇ ˇ ˇ
„X A set of very w ell initial specified requirements
„X An user w i th disposability to collaborate and to participate
effectively to the project specification process

25. 5.3 THE PROTOTYPING
o PROTOTYPING V recom mended in the case of projects in w hi ch theˇ
client can ¦t parti cipate, or is not interested in producing a list of w ellˇ
defined requirements
„X Analyze and even design activities are iterative
„X The result is an §obtaining-validation-correc tion ¨ cycleˇ ˇ
applicable to product proto type
„X Requires specific rapid and efficient prototypes developing tools
„X It can be used as a preliminary development cycle, follo wed by
another type of cycle for the finally produc t development
5.4. EVOLUTIONARY MODEL
„h Based on versions
„h Each version is derived quickly
„h This process is named iteration
„h Each version is send to the customer w hich analyze it an supplies
feed back
„h Each iteration is based on a Waterfall Life Cycle
„h RUP (Rational Development Process) is based on this model
5.5 THE SPIRAL LIFE CYCLE (BOEHM)
o SPIRAL LIFE CYCLE (Boehm) V recom mended for projects:ˇ
„X With high development risks
„X With high co mplexity
„X Which requires very special technologies
„X For w hich is not precisely kno wn the modality of solving
customer requirements
„X Are very expensive
„X Spiral Cycle can be considered as a repetition of linear cycles,
each ne w cycle added to the spiral, adding in the same time
ne w facilities to the produc t
5.6 FORMAL SYSTEM DEVELOPMENT
Uses ma thematical me thods
Formal specification based on Step wise Refinement
Formal approach, no tests are necessary
Useful for non-interac tive syste ms, but require experts

26. 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 generic soft ware process
used as a frame wor k for many systems currently being developed or
supported
o IEEE/EIA 12207 defines a set of recom mended development activities
and docu mentation alternatives for soft ware intensive syste ms.
o This standard is co mpatible w i th a number of different soft ware
development me thods, including the w a terfall model.
o IEEE/EIA 12207 defines a standard soft ware hierarchy and an
associated te r minology (commonly used for co mplex DOD soft ware
and other co mplex MIS systems)
Metode de estimare a dimensiunilor proiectelor SW.
Principii. Prezentati metoda Wideband-Delphy -
Chapter04_1 pagini 24-25
Size Estimating Methods
To measure SW projec ts different me trics are used.
o (1) Size oriented me trics Mainly consisting in esti mation of the number
of source line of
code.
o (2) Function oriented me trics Mainly consisting in estimating of the
co mplexity of the
functions realized by the soft ware produc t resulted from the
development process.
Size oriented metrics use as measure the number of source line of code
or the number of delivered source instructions.
Classical me thods for size estimation of the SW projects based on these
me trics:
o (1) Wideband-Delphi Method
o (2) Fuzzy-Logic Method
o (3) Standard-Component Method
Wideband-Delphi Method
The Wideband-Delphi estimating me thod w as originated by the Rand
Corporation 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 consensus estimate.
The procedure is essentially as follo ws

27. (1) A group of experts is each given the program’s specifications and an
estimation form.
(2) The me mbers of the group meet to discuss projec t goals,
assumptions, and esti mation issues.
(3) The me mbers of the group then each anonymously list projec t tasks
and estimate size.
(4) The estimates are given to the estimate moderator, w ho tabulates
the results and returns them to the experts
For each expert only personal estimate is identified All other’s estimates
are anonymous.
There is also identified the median estimation.
(5) The experts meet to discuss the anonymous results.
(6) The experts each eventually revie w the tasks they have defined and
their size estimates.
(7)The cycle continues at step 3 until the estimates converge to
w i thin an accep table range.
(8)
Metode de estimare a costurilor bazate pe
decompozitie. Descrieti o astfel de metoda -
Chapter04_2 pagini 16-19
Decomposition Models
Decomposition models partition the project in small tasks (elements)
w hi ch are separately evaluated.
In this ca tegory are included evaluation models as:
o (1) Effort Estimation Model (EE Model).
o (2) Line of Code Model (LOC Model).
o (3) Functional Point 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 subtasks
corresponding 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)

28. 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 total
cost.
Advantages:
(1) The phase costs of each feature can be clearly emphasized.
o This thing is very important because in many situations the costs
differ 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
results
which are affected by a reduced error coefficient.
Disadvantages:
(1) The method requires evaluators with significant experience and a
high
degree 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 characterize
from 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 the
development process.
Summary
Fuzzy-logic Method
Putnam 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

29. prior products. [Putnam].
• For example, you could break the sizes of all your organization’s
previously developed products into ranges and subranges size
categories
With sufficient data, these gross size ranges can be subdivided into more
detailed categories (subranges)
• One problem with the fuzzy logic method is that the size of major
programming applications has historically grown by about an order of
magnitude every 10 years.
• Reasonably accurate estimates of the very largest category are thus
particularly important.
• Unfortunately, any gross sizing method will not likely be of much help in
estimating a new program that is much larger than anything you have
previously built.
• To handle this situation, you would have to subdivide the new product into
smaller components and estimate each component.