SOFTWARE ENGG UNIT-1 PPT HDFC life cycle and web apps.pptx

SOFTWARE ENGINEERING
UNIT-I: BASIC CONCEPTS IN SOFTWARE ENGINEERING AND SOFTWARE PROJECT MANAGEMENT
Basic concepts: abstraction versus decomposition, evolution of software engineering
techniques, Software development life cycle (SDLC) models: Iterative waterfall model,
Prototype model, Evolutionary model, Spiral model, RAD model, Agile models, software
project management: project planning, project estimation, COCOMO, Halstead’s
Software Science, project scheduling, staffing, Organization and team structure, risk
management, configuration management.
BASIC CONCEPTS IN SOFTWARE ENGINEERING AND SOFTWARE PROJECT MANAGEMENT
Software engineering is an engineering approach for software development. We can
alternatively view it as a systematic collection of past experience. The experience is
arranged in the form of methodologies and guidelines. A small program can be written
without using software engineering principles. But if one wants to develop a large
software product, then software engineering principles are indispensable to achieve a
good quality software cost effectively. These definitions can be elaborated with the
help of a building construction analogy.

BASIC CONCEPTS: ABSTRACTION & DECOMPOSITION
The principle of abstraction implies that a problem can be simplified by omitting irrelevant
details. In other words, the main purpose of abstraction is to consider only those aspects of
the problem that are relevant for certain purpose and suppress other aspects that are not
relevant for the given purpose. Once the simpler problem is solved, then the omitted
details can be taken into consideration to solve the next lower level abstraction, and so on.
Abstraction is a powerful way of reducing the complexity of the problem.
FIG: Hierarchy of abstraction

The other approach to tackle problem complexity is decomposition. In this technique, a
complex problem is divided into several smaller problems and then the smaller problems are
solved one by one. However, in this technique any random decomposition of a problem into
smaller parts will not help. The problem has to be decomposed such that each component of
the decomposed problem can be solved independently and then the solution of the different
components can be combined to get the full solution. A good decomposition of a problem as
shown in fig.1.5 should minimize interactions among various components. If the different
subcomponents are interrelated, then the different components cannot be solved separately
and the desired reduction in complexity will not be realized.
Fig: Decomposition of a large problem into a set of smaller problems

EVOLUTION OF SOFTWARE ENGINEERING TECHNIQUES
Software Evolution is a term which refers to the process of developing software
initially, then timely updating it for various reasons, i.e., to add new features or to
remove obsolete functionalities etc. The evolution process includes fundamental
activities of change analysis, release planning, system implementation and releasing a
system to customers.
The cost and impact of these changes are accessed to see how much system is affected
by the change and how much it might cost to implement the change. If the proposed
changes are accepted, a new release of the software system is planned. During release
planning, all the proposed changes (fault repair, adaptation, and new functionality) are
considered.
A design is then made on which changes to implement in the next version of the system.
The process of change implementation is an iteration of the development process where
the revisions to the system are designed, implemented and tested.

Software development life cycle (SDLC) models:
A software life cycle model (also called process model) is a descriptive and diagrammatic
representation of the software life cycle. A life cycle model represents all the activities
required to make a software product transit through its life cycle phases. It also captures
the order in which these activities are to be undertaken. In other words, a life cycle model
maps the different activities performed on a software product from its inception to
retirement. Different life cycle models may map the basic development activities to phases
in different ways. Thus, no matter which life cycle model is followed, the basic activities
are included in all life cycle models though the activities may be carried out in different
orders in different life cycle models. During any life cycle phase, more than one activity
may also be carried out. For example, the design phase might consist of the structured
analysis activity followed by the structured design activity.
Different software life cycle models
Many life cycle models have been proposed so far. Each of them has some advantages as
well as some disadvantages. A few important and commonly used life cycle models are as
follows:
1. Classical Waterfall Model
2. Iterative Waterfall Model
3. Prototyping Model
4. Evolutionary Model
5. Spiral Model

CLASSICAL WATERFALL MODEL
The classical waterfall model is intuitively the most obvious way to develop software. Though
the classical waterfall model is elegant and intuitively obvious, it is not a practical model in the
sense that it can not be used in actual software development projects. Thus, this model can be
considered to be a theoretical way of developing software. But all other life cycle models are
essentially derived from the classical waterfall model. So, in order to be able to appreciate
other life cycle models it is necessary to learn the classical waterfall model.
Classical waterfall model divides the life cycle into the following phases
• Feasibility Study
• Requirements Analysis and Specification
• Design
• Coding and Unit Testing
• Integration and System Testing
• Maintenance

Activities in each phase of the life cycle
Activities undertaken during feasibility study: -
• At first project managers or team leaders try to have a rough understanding of what is
required to be done by visiting the client side.
• After they have an overall understanding of the problem they investigate the different
solutions that are possible.
• Based on this analysis they pick the best solution and determine whether the solution is
feasible financially and technically.
Activities undertaken during requirements analysis and specification:-
• The aim of the requirements analysis and specification phase is to understand the exact
requirements of the customer and to document them properly. This phase consists of two
distinct activities, namely
1.Requirements gathering and analysis, and 2. Requirements specification
• The customer requirements identified during the requirements gathering and analysis
activity are organized into a SRS document. The important components of this document
are functional requirements, the nonfunctional requirements, and the goals of
implementation.
Activities undertaken during design: -
The goal of the design phase is to transform the requirements specified in the SRS document
into a structure that is suitable for implementation in some programming language. In technical
terms, during the design phase the software architecture is derived from the SRS document.
Two distinctly different approaches are available: the traditional design approach and the
object-oriented design approach.

Activities undertaken during coding and unit testing:-
• The purpose of the coding and unit testing phase (sometimes called the implementation
phase) of software development is to translate the software design into source code.
• During this phase, each module is unit tested to determine the correct working of all the
individual modules
Activities undertaken during integration and system testing: -
• During the integration and system testing phase, the modules are integrated in a planned
manner.
• The different modules making up a software product are almost never integrated in one
shot.
• Finally, when all the modules have been successfully integrated and tested, system testing
is carried out.
• System testing usually consists of three different kinds of testing activities:
• α – testing: It is the system testing performed by the development team.
• β – testing: It is the system testing performed by a friendly set of customers.
• acceptance testing: It is the system testing performed by the customer himself after
the product delivery to determine whether to accept or reject the delivered product.
Activities undertaken during maintenance: -
Maintenance involves performing any one or more of the following three kinds of activities:
• Correcting errors that were not discovered during the product development phase. This is
called corrective maintenance.
• Improving the implementation of the system, and enhancing the functionalities of the
system according to the customer’s requirements. This is called perfective maintenance.
• Porting the software to work in a new environment.

Shortcomings of the classical waterfall model
The classical waterfall model is an idealistic one since it assumes that no development error is
ever committed by the engineers during any of the life cycle phases. However, in practical
development environments, the engineers do commit a large number of errors in almost every
phase of the life cycle. The source of the defects can be many: oversight, wrong assumptions,
use of inappropriate technology, communication gap among the project engineers, etc. These
defects usually get detected much later in the life cycle.
PROTOTYPE MODEL
A prototype is a toy implementation of the system. A prototype usually exhibits limited
functional capabilities, low reliability, and inefficient performance compared to the actual
software. A prototype is usually built using several shortcuts. The shortcuts might involve
using inefficient, inaccurate, or dummy functions. A prototype usually turns out to be a very
crude version of the actual system.
Need for a prototype in software development
There are several uses of a prototype. An important purpose is to illustrate the input data
formats, messages, reports, and the interactive dialogues to the customer. This is a valuable
mechanism for gaining better understanding of the customer’s needs:
• how the screens might look like
• how the user interface would behave
• how the system would produce outputs
Another reason for developing a prototype is that it is impossible to get the perfect product
in the first attempt. The experience gained in developing the prototype can be used to
develop the final product.

SOFTWARE ENGG UNIT-1 PPT HDFC life cycle and web apps.pptx

EVOLUTIONARY MODEL
This model has many of the features of the incremental model, the evolutionary model can
also be viewed as an extension of the waterfall model, but it incorporates a major paradigm
shift that has been widely adopted in many recent life cycle models. Due to obvious reasons,
the evolutionary software development process is sometimes referred to as design a little,
build a little, test a little, deploy a little model. This means that after the requirements have
been specified, the design, build, test, and deployment activities are iterated.
Advantages: The evolutionary model of
development has several advantages. Two
important advantages of using this model are the
following:
• Effective elicitation of actual customer
requirements
• Easy handling change requests
Disadvantages: The main disadvantages of the
successive versions model are as follows:
• Feature division into incremental parts can be
non-trivial
• Ad hoc design
Applicability of the evolutionary model: The
evolutionary model is normally useful for very
large products, where it is easier t o find modules
for incremental implementation

SPIRAL MODEL
The diagrammatic representation of this model appears like a spiral with many loops. The
exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of
the software process, the innermost loop might be concerned with feasibility study. The next
loop with requirements specification, the next one with design, and so on. Each phase in this
model is split into four sectors (or quadrants).
First quadrant (Objective Setting):
• During the first quadrant, it is needed to
identify the objectives of the phase.
• Examine the risks associated with these
objectives.
Second Quadrant (Risk Assessment and
Reduction)
• A detailed analysis is carried out for each
identified project risk.
• Steps are taken to reduce the risks. For
example, if there is a risk that the
requirements are inappropriate, a prototype
system may be developed.

Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving the identified risks.
Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the customer and plan the next iteration around the
spiral.
• Progressively more complete version of the software gets built with each iteration around
the spiral.
Circumstances to use spiral model
The spiral model is called a meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks. However,
this model is much more complex than the other models – this is probably a factor deterring
its use in ordinary projects.
RAD MODEL
The rapid application development (RAD) model was proposed in the early nineties in an
attempt to overcome the rigidity of the waterfall model (and its derivatives) that makes it
difficult to accommodate any change requests from the customer. It proposed a few radical
extensions to the waterfall model. This model has the features of both prototyping and
evolutionary models.
The major goals of the RAD model are as follows:
To decrease the time taken and the cost incurred to develop software systems. To limit the
costs of accommodating change requests. T o reduce the communication gap between the
customer and the developers.

RAD Model or Rapid Application Development
model is a software development process based on
prototyping without any specific planning. In RAD
model, there is less attention paid to the planning and
more priority is given to the development tasks. It
targets at developing software in a short span of time.
SDLC RAD modeling has following phases:
•Business Modeling: On basis of the flow of
information and distribution between various business
channels, the product is designed
•Data Modeling: The information collected from
business modeling is refined into a set of data objects
that are significant for the business
•Process Modeling: The data object that is declared
in the data modeling phase is transformed to achieve
the information flow necessary to implement a
business function
•Application Generation: Automated tools are used for the construction of the software, to
convert process and data models into prototypes
•Testing and Turnover: As prototypes are individually tested during every iteration, the
overall testing time is reduced in RAD.

Advantages of RAD Model Disadvantages of RAD Model
•Flexible and adaptable to changes •It can’t be used for smaller projects
•It is useful when you have to reduce the
overall project risk
•Not all application is compatible with
RAD
•It is adaptable and flexible to changes
•When technical risk is high, it is not
suitable
•It is easier to transfer deliverables as
scripts, high-level abstractions and
intermediate codes are used
•If developers are not committed to
delivering software on time, RAD
projects can fail
Rapid Application Development Advantages and Disadvantages
AGILE MODELS.
The agile software development model was proposed in the mid-1990s to overcome the
serious shortcomings of the waterfall model of development identified above. The meaning
of Agile is swift or versatile. "Agile process model" refers to a software development
approach based on iterative development. Agile methods break tasks into smaller iterations,
or parts do not directly involve long term planning.

A few popular agile SDLC models are the following:
1. Crystal 2.Atern (formerly Dynamic Software Development Method) 3.Feature-driven
development 4.Scrum 5.Extreme programming (XP) 6.Lean development & Unified process
1.CRYSTAL: There are three concepts of this method-
1.Chartering: Multi activities are involved in this phase such as making a
development team, performing feasibility analysis, developing plans, etc.
2.Cyclic delivery: under this, two more cycles consist, these are:
1. Team updates the release plan.
2. Integrated product delivers to the users.
3.Wrap up: According to the user environment, this phase performs
deployment, post-deployment.

2. ATERN:DSDM is a rapid application development strategy for software development
and gives an agile project distribution structure. The essential features of DSDM are that
users must be actively connected, and teams have been given the right to make decisions.
The techniques used in DSDM are:
1.Time Boxing
2.MoSCoW Rules
3.Prototyping
The DSDM project contains seven stages:
4.Pre-project
5.Feasibility Study
6.Business Study
7.Functional Model Iteration
8.Design and build Iteration
9.Implementation
10.Post-project
3. FEATURE-DRIVEN DEVELOPMENT: This method focuses on "Designing and
Building" features. In contrast to other smart methods, FDD describes the small steps of the
work that should be obtained separately per function.
4. SCRUM: SCRUM is an agile development process focused primarily on ways to
manage tasks in team-based development conditions.

There are three roles in it, and their responsibilities are:
•Scrum Master: The scrum can set up the master team, arrange the meeting and remove
obstacles for the process.
•Product owner: The product owner makes the product backlog, prioritizes the delay and is
responsible for the distribution of functionality on each repetition.
•Scrum Team: The team manages its work and organizes the work to complete the sprint or
cycle.
5. EXTREME PROGRAMMING (XP): This type of methodology is used when
customers are constantly changing demands or requirements, or when they are not sure
about the system's performance.
6. LEAN DEVELOPMENT & UNIFIED PROCESS: Lean software development
methodology follows the principle "just in time production." The lean method
indicates the increasing speed of software development and reducing costs.
Lean development can be summarized in seven phases.
a.Eliminating Waste b.Amplifying learning c.Defer commitment (deciding as
late as possible) d.Early delivery e.Empowering the team f.Building Integrity
g.Optimize the whole

When to use the Agile Model?
•When frequent changes are required.
•When a highly qualified and experienced team is available.
•When a customer is ready to have a meeting with a software team all the time.
•When project size is small.
Advantage(Pros) of Agile Method:
1.Frequent Delivery
2.Face-to-Face Communication with clients.
3.Efficient design and fulfils the business requirement.
4.Anytime changes are acceptable.
5.It reduces total development time.
Disadvantages(Cons) of Agile Model:
6.Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.
7.Due to the lack of proper documentation, once the project completes and the developers
allotted to another project, maintenance of the finished project can become a difficulty.

SOFTWARE PROJECT MANAGEMENT:
project planning:
Once a project is found to be feasible, software project managers undertake project planning.
Project planning is undertaken and completed even before any development activity starts.
Project planning consists of the following essential activities:
• Estimating the following attributes of the project:
Project size: What will be problem complexity in terms of the effort and time required to
develop the product?
Cost: How much is it going to cost to develop the project?
Duration: How long is it going to take to complete development?
Effort: How much effort would be required?
The effectiveness of the subsequent planning activities is based on the accuracy of these
estimations.
• Scheduling manpower and other resources
• Staff organization and staffing plans
• Risk identification, analysis, and abatement planning
• Miscellaneous plans such as quality assurance plan, configuration management plan, etc.

PROJECT ESTIMATION:
Estimation of various project parameters is a basic project planning activity. The important
project parameters that are estimated include: project size, effort required to develop the
software, project duration, and cost. These estimates not only help in quoting the project cost
to the customer, but are also useful in resource planning and scheduling. There are three
broad categories of estimation techniques:
• Empirical estimation techniques • Heuristic techniques • Analytical estimation techniques
a. Empirical Cost Estimation: Empirical estimation techniques are based on making an
educated guess of the project parameters. While using this technique, prior experience
with development of similar products is helpful.
b. Heuristics Techniques: Heuristic techniques assume that the relationships among the
different project parameters can be modeled using suitable mathematical expressions.
Once the basic (independent) parameters are known, the other (dependent) parameters
can be easily determined by substituting the value of the basic parameters in the
mathematical expression.
c. Analytical Estimation Techniques: Analytical estimation techniques derive the required
results starting with basic assumptions regarding the project. Thus, unlike empirical and
heuristic techniques, analytical techniques do have scientific basis. Halstead’s software
science is an example of an analytical technique. Halstead’s software science can be used
to derive some interesting results starting with a few simple assumptions.

COCOMO: (Constructive Cost Estimation Model) was proposed by Boehm [1981].
According to Boehm, software cost estimation should be done through three stages: Basic
COCOMO, Intermediate COCOMO, and Complete COCOMO.
1. Basic COCOMO Model The basic COCOMO model gives an approximate estimate of the
project parameters. The basic COCOMO estimation model is given by the following
expressions:
Effort = a1 х (KLOC)a 2 PM
Tdev = b1 x (Effort)b 2 Months Where • KLOC is the estimated size of the
software product expressed in Kilo Lines of Code, • a1, a2, b1, b2 are constants for each
category of software products, • Tdev is the estimated time to develop the software, expressed
in months, • Effort is the total effort required to develop the software product, expressed in
person months (PMs).
2.Intermediate COCOMO Model: The basic COCOMO model assumes that effort and
development time are functions of the product size alone. The intermediate COCOMO model
recognizes this fact and refines the initial estimate obtained using the basic COCOMO
expressions by using a set of 15 cost drivers (multipliers) based on various attributes of
software development.
In general, the cost drivers can be classified as being attributes of the following items:
Product: The characteristics of the product that are considered include the inherent
complexity of the product, reliability requirements of the product, etc.
Computer: Characteristics of the computer that are considered include the execution speed
required, storage space required etc.
Personnel: The attributes of development personnel that are considered include the
experience level of personnel, programming capability, analysis capability, etc.

Complete COCOMO model: The complete COCOMO model considers the differences in
characteristics of the subsystems and estimates the effort and development time as the sum
of the estimates for the individual subsystems. The cost of each subsystem is estimated
separately. This approach reduces the margin of error in the final estimate.
The following development project can be considered as an example application
of the complete COCOMO model. A distributed Management Information System (MIS)
product for an organization having offices at several places across the country can have the
following sub-components:
a. Database part b. Graphical User Interface (GUI) part c. Communication part
HALSTEAD’S SOFTWARE SCIENCE:
Halstead’s software science is an analytical technique to measure size, development effort,
and development cost of software products. Halstead used a few primitive program
parameters to develop the expressions for over all program length, potential minimum
value, actual volume, effort, and development time.
For a given program, let:
• η1 be the number of unique operators used in the program,
• η2 be the number of unique operands used in the program,
• N1 be the total number of operators used in the program,
• N2 be the total number of operands used in the program.

Length and Vocabulary :The length of a program as defined by Halstead, quantifies total
usage of all operators and operands in the program. Thus, length N = N1 +N2. Halstead’s
definition of the length of the program as the total number of operators and operands roughly
agrees with the intuitive notation of the program length as the total number of tokens used in
the program.
The program vocabulary is the number of unique operators and operands used in the
program. Thus, program vocabulary η = η1 + η2.
Program Volume: The length of a program (i.e. the total number of operators and operands
used in the code) depends on the choice of the operators and operands used.
Thus, while expressing program size, the programming language used must be
taken into consideration:
V = Nlog2η
Potential Minimum Volume: The potential minimum volume V* is defined as the volume of
most succinct program in which a problem can be coded. The minimum volume is obtained
when the program can be expressed using a single source code instruction.
Thus, if an algorithm operates on input and output data d1, d2, … dn, the most
succinct program would be f(d1, d2, … dn); for which η1 = 2, η2 = n. Therefore, V* = (2 +
η2)log2(2 + η2).
Effort and Time The effort required to develop a program can be obtained by dividing the
program volume with the level of the programming language used to develop the code. Thus,
effort E = V/L, where E is the number of mental discriminations required to implement the
program and also the effort required to read and understand the program. Thus, the
programming effort E = V²/V* (since L = V*/V) varies as the square of the volume. Experience
shows that E is well correlated to the effort needed for maintenance of an existing program.

The programmer’s time T = E/S, where S the speed of mental discriminations. The value of S
has been empirically developed from psychological reasoning, and its recommended value
for programming applications is 18.
Length Estimation : Even though the length of a program can be found by calculating the
total number of operators and operands in a program, Halstead suggests a way to determine
the length of a program using the number of unique operators and operands used in the
program. Using this method, the program parameters such as length, volume, cost, effort, etc.
can be determined even before the start of any programming activity. His method is
summarized below.
Halstead assumed that it is quite unlikely that a program has several identical parts
– in formal language terminology identical substrings – of length greater than η (η being the
program vocabulary). In fact, once a piece of code occurs identically at several places, it is
made into a procedure or a function. Thus, it can be assumed that any program of length N
consists of N/ η unique strings of length η. Now, it is standard combinatorial result that for
any given alphabet of size K, there are exactly Kr different strings of length r.
Thus. N/η ≤ ηη Or, N ≤ ηη+1

PROJECT SCHEDULING
Project-task scheduling is an important project planning activity. It involves
deciding which tasks would be taken up when. In order to schedule the
project
activities, a software project manager needs to do the following:
1. Identify all the tasks needed to complete the project.
2. Break down large tasks into small activities.
3. Determine the dependency among different activities.
4. Establish the most likely estimates for the time durations necessary to
complete the activities.
5. Allocate resources to activities.
6. Plan the starting and ending dates for various activities.
7. Determine the critical path. A critical path is the chain of activities that
determines the duration of the project.

WORK BREAKDOWN STRUCTURE
Work Breakdown Structure (WBS) is used to decompose a given task set
recursively into small activities. WBS provides a notation for
representing the major tasks need to be carried out in order to solve a
problem. The root of the tree is labeled by the problem name. Each node
of the tree is broken down into smaller activities that are made the
children of the node. Each activity is recursively decomposed into
smaller sub-activities until at the leaf level, the activities requires
approximately two weeks to develop.
While breaking down a task into smaller tasks, the manager has to make
some hard decisions. If a task is broken down into large number of very
small activities, these can be carried out independently. Thus, it
becomes possible to develop the product faster (with the help of
additional manpower).

ACTIVITY NETWORKS AND CRITICAL PATH METHOD
WBS representation of a project is transformed into an activity network by
representing activities identified in WBS along with their
interdependencies. An activity network shows the different activities
making up a project, their estimated durations, and interdependencies. Each
activity is represented by a rectangular node and the duration of the activity
is shown alongside each task.

Critical Path Method (CPM)
From the activity network representation following analysis can be made.
The minimum time (MT) to complete the project is the maximum of all
paths from start to finish. The earliest start (ES) time of a task is the
maximum of all paths from the start to the task. The latest start time is the
difference between MT and the maximum of all paths from this task to
the finish. The earliest finish time (EF) of a task is the sum of the earliest
start time of the task and the duration of the task. The latest finish (LF)
time of a task can be obtained by subtracting maximum of all paths from
this task to finish from MT. The slack time (ST) is LS – EF and
equivalently can be written as LF – EF. The slack time (or float time) is
the total time that a task may be delayed before it will affect the end time
of the project. The slack time indicates the “flexibility” in starting and
completion of tasks. A critical task is one with a zero slack time. A path
from the start node to the finish node containing only critical tasks is
called a critical path.

GANTT CHART
Gantt charts are mainly used to allocate resources to activities. The
resources allocated to activities include staff, hardware, and software.
Gantt charts (named after its developer Henry Gantt) are useful for
resource planning. A Gantt chart is a special type of bar chart where each
bar represents an activity. The bars are drawn along a time line. The length
of each bar is proportional to the duration of time planned for the
corresponding activity.
Gantt charts are used in software project management are actually an
enhanced version of the standard Gantt charts. In the Gantt charts used
for software project management, each bar consists of a white part and
a shaded part. The shaded part of the bar shows the length of time each
task is estimated to take. The white part shows the slack time, that is,
the latest time by which a task must be finished.

PERT CHART
PERT (Project Evaluation and Review Technique) charts consist of a
network of boxes and arrows. The boxes represent activities and the
arrows represent task dependencies. PERT chart represents the statistical
variations in the project estimates assuming a normal distribution. Thus, in
a PERT chart instead of making a single estimate for each task,
pessimistic, likely, and optimistic estimates are made. The boxes of PERT
charts are usually annotated with the pessimistic, likely, and optimistic
estimates for every task. Since all possible completion times between the
minimum and maximum duration for every task has to be considered,
there are not one but many critical paths, depending on the permutations
of the estimates for each task. This makes critical path analysis in PERT
charts very complex. A critical path in a PERT chart is shown by using
thicker arrows.
Gantt chart representation of a project schedule is helpful in planning the
utilization of resources, while PERT chart is useful for monitoring the
timely progress of activities. Also, it is easier to identify parallel activities
in a project using a PERT chart. Project managers need to identify the
parallel activities in a project for assignment to different engineers.

STAFFING:
S/w Project Managers usually take the responsibility of choosing their team..
Therefore, they need to identify good software engineers for the success of the
project. However, experiments have revealed that there exists a large variability
of productivity between the worst and the best s/w engineers. Therefore,
choosing good s/w engineers is crucial to the success of a project.
Characteristics of a good software engineer
The attributes that good software engineers should posses are as follows:
• Exposure to systematic techniques, i.e. familiarity with software
engineering principles.
• Good technical knowledge of the project areas (Domain knowledge).
• Good programming abilities.
• Good communication skills. These skills comprise of oral, written, and
interpersonal skills.
• High motivation.
• Sound knowledge of fundamentals of computer science.
• Intelligence.
• Ability to work in a team.
• Discipline, etc.

ORGANIZATION AND TEAM STRUCTURE
Usually every software development organization handles several
projects at any time. Software organizations assign different teams of
engineers to handle different software projects. Each type of organization
structure has its own advantages and disadvantages so the issue “how is
the organization as a whole structured?” must be taken into consideration
so that each software project can be finished before its deadline.

FUNCTIONAL FORMAT VS. PROJECT FORMAT
There are essentially two broad ways in which a software development
organization can be structured: functional format and project format. In the
project format, the project development staff are divided based on the
project for which they work. In the functional format, the development
staff are divided based on the functional group to which they belong. The
different projects borrow engineers from the required functional groups for
specific phases to be undertaken in the project and return them to the
functional group upon the completion of the phase.
The main advantages of a functional organization are:
• Ease of staffing
• Production of good quality documents
• Job specialization
• Efficient handling of the problems associated with manpower turnover.

TEAM STRUCTURES
Team structure addresses the issue of organization of the individual project
teams. There are some possible ways in which the individual project teams
can be organized. There are mainly three formal team structures: chief
programmer, democratic, and the mixed team organizations although
several other variations to these structures are possible. Problems of
different complexities and sizes often require different team structures for
chief solution.
CHIEF PROGRAMMER TEAM
In this team organization, a senior engineer provides the technical
leadership and is designated as the chief programmer. The chief
programmer partitions the task into small activities and assigns them to
the team members. He also verifies and integrates the products
developed by different team members.

Democratic Team
The democratic team structure, as the name implies, does not enforce any formal team
hierarchy (as shown in fig. 12.3). Typically, a manager provides the administrative
leadership. At different times, different members of the group provide technical leadership.

MIXED CONTROL TEAM ORGANIZATION
The mixed team organization, as the name implies, draws upon the ideas
from both the democratic organization and the chief-programmer
organization. This team organization incorporates both hierarchical
reporting and democratic set up.

RISK MANAGEMENT
A software project can be affected by a large variety of risks. In order to
be able to systematically identify the important risks which might affect a
software project, it is necessary to categorize risks into different classes.
The project manager can then examine which risks from each class are
relevant to the project. There are three main categories of risks which can
affect a software project:
Project Risks:Project risks concern varies forms of budgetary, schedule,
personnel, resource, and customer-related problems. An Important
project risk is schedule slippage. Since, software is intangible, it is very
difficult to monitor and control a software project.
Technical risks: Technical risks concern potential design,
implementation, interfacing, testing, and maintenance problems.
Technical risks also include ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and technical
obsolescence. Most technical risks occur due to the development team’s
insufficient knowledge about the project.

Business risks: This type of risks include risks of building an excellent
product that no one wants, losing budgetary or personnel commitments, etc.
Risk assessment:
The objective of risk assessment is to rank the risks in terms of their
damage causing potential. For risk assessment, first each risk should be
rated in two ways:
• The likelihood of a risk coming true (denoted as r).
• The consequence of the problems associated with that risk (denoted
as s). Based on these two factors, the priority of each risk can be
computed:
p = r * s
Where, p is the priority with which the risk must be handled, r is the
probability of the risk becoming true, and s is the severity of damage
caused due to the risk becoming true. If all identified risks are prioritized,
then the most likely and damaging risks can be handled first and more
comprehensive risk abatement procedures can be designed for these risks.

Risk containment
After all the identified risks of a project are assessed, plans must be made
to contain the most damaging and the most likely risks. Different risks
require different containment procedures. In fact, most risks require
ingenuity on the part of the project manager in tackling the risk.
There are three main strategies to plan for risk containment:
Avoid the risk: This may take several forms such as discussing with the
customer to change the requirements to reduce the scope of the work,
giving incentives to the engineers to avoid the risk of manpower turnover,
etc.
Transfer the risk: This strategy involves getting the risky component
developed by a third party, buying insurance cover, etc.
Risk reduction: This involves planning ways to contain the damage due
to a risk. For example, if there is risk that some key personnel might
leave, new recruitment may be planned.
Risk leverage: To choose between the different strategies of handling a
risk, the project manager must consider the cost of handling the risk and
the corresponding reduction of risk. For this the risk leverage of the
different risks can be computed.

Risk leverage is the difference in risk exposure divided by the cost of
reducing the risk. More formally,
risk leverage = (risk exposure before reduction – risk exposure after
reduction) / (cost of reduction)
SOFTWARE CONFIGURATION MANAGEMENT
The results (also called as the deliverables) of a large software
development effort typically consist of a large number of objects, e.g.
source code, design document, SRS document, test document, user’s
manual, etc. These objects are usually referred to and modified by a
number of software engineers through out the life cycle of the software.
The state of all these objects at any point of time is called the
configuration of the software product. The state of each deliverable
object changes as development progresses and also as bugs are detected
and fixed.

Necessity of software configuration management
•Inconsistency problem when the objects are replicated
•Problems associated with concurrent access
•Providing a stable development environment
•System accounting and maintaining status information
•Handling variants
Software Configuration Management Activities
Configuration management is carried out through two principal activities:
• Configuration identification involves deciding which parts of the system
should be kept track of
• Configuration control ensures that changes to a system happen
smoothly.
Configuration identification
The project manager normally classifies the objects associated with a
software development effort into three main categories: controlled,
precontrolled, and uncontrolled.

CONFIGURATION CONTROL
Configuration control is the process of managing changes to
controlled objects. Configuration control is the part of a configuration
management system that most directly affects the day-to-day
operations of developers. The configuration control system prevents
unauthorized changes to any controlled objects. In order to change a
controlled object such as a module, a developer can get a private
copy of the module by a reserve operation. Configuration
management tools allow only one person to reserve a module at a
time. Once an object is reserved, it does not allow any one else to
reserve this module until the reserved module is restored. Thus, by
preventing more than one engineer to simultaneously reserve a
module, the problems associated with concurrent access are solved.

The CCB is usually constituted from among the development team
members. For every change that needs to be carried out, the CCB reviews the
changes made to the controlled object and certifies several things about the
change:
1. Change is well-motivated.
2. Developer has considered and documented the effects of the change.
3. Changes interact well with the changes made by other developers.
4. Appropriate people (CCB) have validated the change, e.g. someone has
tested the changed code, and has verified that the change is consistent with
the requirement.
----## END OF UNIT-1 ##----

SOFTWARE ENGG UNIT-1 PPT HDFC life cycle and web apps.pptx

More Related Content

Similar to SOFTWARE ENGG UNIT-1 PPT HDFC life cycle and web apps.pptx (20)

Recently uploaded (20)

SOFTWARE ENGG UNIT-1 PPT HDFC life cycle and web apps.pptx