UNIT-I:

Conventional Software Management: The waterfall model, conventional software

Management performance.
Evolution of Software Economics: Software Economics, pragmatic software cost
estimation.
Improving Software Economics: Reducing Software product size, improving software
processes, improving team effectiveness, improving automation, Achieving required quality,
peer inspections..
The old way and the new: The principles of conventional software Engineering, principles
of modern software management, transitioning to an iterative process.

software project management

some key ideas about the planning, monitoring and control of software
projects. Projects to produce software are worthwhile only if they satisfy real needs and so we will
examine how we can identify the stakeholders in a project and their objectives. Identifying those
objectives and checking that they are met is the basis of a successful project

Conventional software economics provides a benchmark of performance for conventional software

management principles.

 Thebestthingaboutsoftwareisitsflexibility:Itcanbeprogrammedtodoalmostanything.
 Theworstthingaboutsoftwareis -
characteristichasmadeitdifficulttoplan,monitors,andcontrolsoftwaredevelopment.

WATERFALLMODEL

Waterfall model is the simplest model of software development paradigmin linear

manner.That is, when the first phase is finished then only the second phase will start and so
on.

waterfall model as the source of the "conventional" softwareprocess.

conventionalsoftwaremanagement

This model assumes that everything is carried out and taken place perfectly as planned in the
previous stage. The sequential nature of model does not allow us go back and undo or redo
our actions.

Communication
This is the first step where the user initiates the request for a desired software product. He
contacts the service provider and tries to negotiate the terms. He submits his request to the
service providing organization in writing.

Requirement Gathering

This step onwards the software development team works to carry on the project. The team
holds discussions with various stakeholders from problem domain and tries to bring out as
much information as possible on their requirements. The requirements are contemplated and
segregated into user requirements, system requirements and functional requirements. The
requirements are collected using a number of practices as given -

 studying the existing or obsolete system and software,

 conducting interviews of users and developers,
 referring to the database or
 collecting answers from the questionnaires.

Feasibility Study

After requirement gathering, the team comes up with a rough plan of software process. At
this step the team analyzes if a software can be made to fulfill all requirements of the user and
if there is any possibility of software being no more useful. It is found out, if the project is
financially, practically and technologically feasible for the organization to take up. There are
many algorithms available, which help the developers to conclude the feasibility of a
software project.

System Analysis

At this step the developers decide a roadmap of their plan and try to bring up the best
software model suitable for the project. System analysis includes Understanding of software
product limitations, learning system related problems or changes to be done in existing
systems beforehand, identifying and addressing the impact of project on organization and
personnel etc. The project team analyzes the scope of the project and plans the schedule and
resources accordingly.

Software Design

Next step is to bring down whole knowledge of requirements and analysis on the desk and
design the software product. The inputs from users and information gathered in requirement
gathering phase are the inputs of this step. The output of this step comes in the form of two
designs; logical design and physical design. Engineers produce meta-data and data
dictionaries, logical diagrams, data-flow diagrams and in some cases pseudo codes.

Coding

This step is also known as programming phase. The implementation of software design starts
in terms of writing program code in the suitable programming language and developing error-
free executable programs efficiently.
Testing

An estimate says that 50% of whole software development process should be tested. Errors
may ruin the software from critical level to its own removal. Software testing is done while
coding by the developers and thorough testing is conducted by testing experts at various
levels of code such as module testing, program testing, product testing, in-house testing and
testing the product at user’s end. Early discovery of errors and their remedy is the key to
reliable software.

Integration

Software may need to be integrated with the libraries, databases and other program(s). This
stage of SDLC is involved in the integration of software with outer world entities.

Implementation

This means installing the software on user machines. At times, software needs post-
installation configurations at user end. Software is tested for portability and adaptability and
integration related issues are solved during implementation.

Operation and Maintenance

This phase confirms the software operation in terms of more efficiency and less errors. If
required, the users are trained on, or aided with the documentation on how to operate the
software and how to keep the software operational. The software is maintained timely by
updating the code according to the changes taking place in user end environment or
technology. This phase may face challenges from hidden bugs and real-world unidentified
problems.

CONVENTIONALSOFTWAREMANAGEMENTPERFORMANCE

BarryBoehm's"IndustrialSoftwareMetricsisagood,objectivecharacterizationofthestateofsoft
ware development.

1. Findingandfixingasoftwareproblemafterdeliverycosts100timesmorethanfindingandfi
xingtheproblem in early designphases.
2. Youcancompresssoftwaredevelopmentschedules25%ofnominal,butnomore.
3. For every$1youspendondevelopment,you willspend$2onmaintenance.
4. Softwaredevelopmentandmaintenancecostsareprimarilyafunctionofthenumberof
sourcelinesofcode.
5. Variationsamongpeopleaccountforthebiggestdifferencesinsoftwareproductivity.
6. Theoverallratioofsoftwaretohardwarecostsisstillgrowing.
7. Onlyabout 15%ofsoftwaredevelopmenteffortisdevotedtoprogramming.
Evolution of Software Economics
SOFTWAREECONOMICS :
Most software cost models can be abstracted into a function of five basic parameters:
size, process, personnal,environment,andrequiredquality.
1. The size of the end product (in human-generated components), which is
 typically quantified in termsof the numberof source instructions or the
numberof function points required todevelop therequiredfunctionality

2. The process used to produce the end product, in particular the ability of the
process to avoid non-value-adding activities(rework,bureaucratic
delays,communicationsoverhead)

3. Thecapabilitiesofsoftwareengineeringpersonnal,andparticularlytheirexperience
withthecomputerscienceissuesandtheapplicationsdomainissues ofthe project
4. Theenvironment,whichismadeupof the
toolsandtechniquesavailabletosupportefficientsoftware
developmentandtoautomatetheprocess
5. The required quality of the product, including its features, performance,

reliability, and adaptability therelationshipsamong theseparametersand

theestimated cost canbewrittenasfollows:

Effort=(Personnal)(Environment)(Quality)(Sizeprocess)

Three generations of basic technology advancement in tools, components, and processes.

Softwareunitcosts(pickyourfavorite:perSLOC,perfunctionpoint,percomponent)realizedbyan
organization.
Thethreegenerationsofsoftwaredevelopmentaredefinedas follows:

1) Conventional: (1960s and 1970s), Organizations used custom tools, custom

processes,and virtually all custom components built in primitive languages.
Project performance was highlypredictableinthatcost,schedule,and
qualityobjectives
2) Transition:( 1980s and 1990s), software engineering. Organization used more-
repeatable processes and off-the-shelf tools,andmostly custom componentsbuilt-in
higher-levellanguages.Someof thecomponentswere availableascommercial
products,includingtheoperatingsystem,databasemanagementsystem,networking,andgr
aphicaluserinterface.
3) Modernpractices: (2000)andlater, softwareproduction.The
useofmanagedandmeasuredprocesses,integratedautomationenvironments
PRAGMATIC SOFTWARE COST ESTIMATION
One critical problem in software cost estimation is a lack of well-documented case
studies of projects that used an iterative development approach. Software industry has
inconsistently defined metrics or atomic units of measure.
It is hard enough to collect a homogeneous set of project data within
one organization; it is extremely difficult to homogenize data across different organizations
with different processes, languages, domains, and so on.
There have been many debates among developers and vendors of software cost estimation
models and tools

1. Which cost estimation model to use?

2. Whether to measure software size in source lines of code or function points.
3. What constitutes a good estimate?
Thereareseveralpopularcostestimationmodels(suchasCOCOMO,CHECKPOINT,ESTIMACS,KnowledgeP
lan, Price-S, ProQMS, SEER, SLIM, SOFTCOST, and SPQR/20), CO COMO is also one of themost open
and well-documented cost estimation models.

Agoodsoftwarecostestimatehasthefollowingattributes:
 Itisconceivedandsupportedbytheprojectmanager,architectureteam,developmentte
am,andtestteamaccountableforperformingthework.
 Itisacceptedbyallstakeholdersasambitiousbutrealizable.
 Itis basedonawell-definedsoftwarecostmodelwithacrediblebasis.
 Itisbasedonadatabaseofrelevantprojectexperiencethatincludessimilarprocesses,si
milartechnologies,similarenvironments,similarquality requirements,and
similarpeople.
 Itisdefinedinenoughdetail
sothatitskeyriskareasareunderstoodandtheprobabilityofsuccessisobjectivelyasses
sed

Improving Software Economics

Software estimation is needed to be based on very careful analysis and should be

supported by all. Software economics improvements should come from reducing size,
improving software processes, improving team effectiveness, improving automation through
software environments, and achieving the required quality.

Improving Team Effectiveness :

Describes the process that just uses the lowest amount of inputs to develop or
create the greatest or highest amount of outputs
A team is vulnerable whenever it is out of balance. Some of the true statements of team
management are given below:

 With the help of the engineering team that is nominal or are not expert
 system that is poorly architected will experience many difficulties.

Boehm (1981) have suggested and offered five staffing principles generally to examine how
to staff a software project. These principles are given below:

1. The principle of top talent: Use better and fewer people.

2. The principle of job matching: Fit the tasks to the skills and motivation
of the people available.
3. The principle of career progression: An organization does best in the
long run by helping its people to self-actualize.
4. The principle of team balance: Select people who will complement and
harmonize with one another.
5. The principle of phaseout: Keeping a misfit on the team doesn't benefit
anyone.
Improving Automation through Software Environments :
many software tools that are available in the market that helps in automating the
development and maintenance of the artifacts. Some of these tools can be
planning tools, requirement management tools, visual modeling tools, quality
assurance tools, and many more. The development environment should also
support requirement management, document automation, host/target programming
tools, testing, and feature/defect tracking, etc. All of the tools should allow the
designer or the developer to easily traverse between various artifacts.

The principles of conventional software Engineering

There are many explanations and descriptions of engineering software “the old
way”. After many years of experience regarding software development, the software industry
has learned and understood many lessons and formulated or created many principles.
Some of these principles are given below :

1. Create or Make Quality –

Quality of software must be measured or quantified and mechanisms put into
place to motivate towards achieving the goal.
2. Large or high-quality software is possible –
There are several techniques that have been given a practical explanation to raise and
increase and quality includes involving customer, prototyping, simplifying design,
conducting inspections, and hiring good and best people.
3. Give end-products to Customers early –
To determine and identify their real and realistic needs is to give product to users.
4. Determine problem or issue before writing and needs or requirements
5. Evaluate all Design Alternatives –
we must examine and understand various architecture and algorithms.
6. Use an appropriate and correct process model –
extent to which all requirements and needs are understood in a good manner.
7. Use different languages for various phases
8. Rather than Good technology, Good management is more important
9. Understanding priorities of customers –
It is simply possible that customer would tolerate 90 percent of performance that is
delivered late only if they could have 10 percent of it on time.
10. Design for update or change –
We should update or accommodate change architecture, components, and
specification techniques that we generally use.
11. Without documentation, design is not a design
12. Rather than Good technology, Good management is more important

principles of modern software management

 There are some modern principles for the development of
software. To develop a proper software one should follow the following 10
Principles of software development:

Architecture first approach:

In this approach over the main aim is to build a strong architecture for our
software
Iterative life cycle process:
An iterative life cycle process we repeated the process again and again to
eliminate the risk factors.An iterative life cycle we mainly have four steps
requirement gathering, design, implementation, and testing. All these steps
are repeated again and again until we mitigate the risk factor.
component Based Approach:
In component-based approach is a widely used and successful approach in
which we reuse the previously defined functions for the software
development.
Change Management system:
change management is to improve the quality of software by performing
necessary changes. All changes implemented are then tested and certified.
Round Trip Engineering:
In round trip engineering, the main characteristic is automatic update of
artifacts.
Model Based Evolution:
A model-based approach supports the evolution of graphics and textual
notions.
Objective Quality Control:
To improve the quality of our software. It involves Quality management plan,
Quality metrics, Quality checklist, Quality baseline, and Quality Improvement
measures.
Evolving levels of details
We must plan an incremental realize in which we have an evolving level of
use case, architecture, and details.
Establish a configurable process:
Establish a configurable process that is economically scalable.
Demonstration Based approach:
In this approach, we mainly focus on demonstration. It helps in the increase
of productivity and quality of our software by representing a clear description
about problem domain, approaches used and the solution.

Transitioning to an iterative process

Modern software development processes have moved away from the

conventional waterfall model, in which each stage of the development process is
dependent on completion of the previous stage.
The economic benefits inherent in transitioning from the conventional
waterfall model to an iterative development process are significant but difficult
to quantify.
consider the process exponent parameters of the COCOMO II
Application Precedentedness –
In understanding how to plan and execute project of software development,
the main critical experience is Domain experience.
Process flexibility
Development of modern software is characterized by such a broad solution
space and so many interrelated concerns that there is a paramount need for
continuous incorporation of changes. These changes may be inherent in the
problem understanding, the solution space, or the plans.
Architecture Risk Resolution –
Architecture is generally developed or established and stabilized by project
team before development of components that usually make up whole suite of
applications components.
Team Cohesion –
successful teams and cohesive teams share common objectives and priorities
Software Process Maturity –
For Software Process Assessment, Capability Maturity Model (CMM) is
Software Engineering Institute which is well-accepted benchmark. A highly
mature process is allowed through an integrated environment