1.

Intodduction and Basic of Software Modelling

Software Development Life Cycle Process

SDLC is a process that defines the various stages involved in the development of software for
delivering a high-quality product. SDLC stages cover the complete life cycle of a software i.e. from
inception to retirement of the product.

Purpose:
Purpose of SDLC is to deliver a high-quality product which is as per the customer’s requirement.

SDLC has defined its phases as, Requirement gathering, Designing, Coding, Testing, and
Maintenance. It is important to adhere to the phases to provide the Product in a systematic manner.

For Example, A software has to be developed and a team is divided to work on a feature of the
product and is allowed to work as they want. One of the developers decides to design first whereas
the other decides to code first and the other on the documentation part.
This will lead to project failure because of which it is necessary to have a good knowledge and
understanding among the team members to deliver an expected product.

SDLC Cycle
SDLC Cycle represents the process of developing software.

Below is the diagrammatic representation of the SDLC cycle:

SDLC Phases
Given below are the various phases:
 Requirement gathering and analysis
 Design
 Implementation or coding
 Testing
 Deployment
 Maintenance
#1) Requirement Gathering and Analysis
During this phase, all the relevant information is collected from the customer to develop a product
as per their expectation. Any ambiguities must be resolved in this phase only.

Business analyst and Project Manager set up a meeting with the customer to gather all the
information like what the customer wants to build, who will be the end-user, what is the purpose of
the product. Before building a product a core understanding or knowledge of the product is very
important.

For Example, A customer wants to have an application which involves money transactions. In this
case, the requirement has to be clear like what kind of transactions will be done, how it will be done,
in which currency it will be done, etc.
Once the requirement gathering is done, an analysis is done to check the feasibility of the
development of a product. In case of any ambiguity, a call is set up for further discussion.
Once the requirement is clearly understood, the SRS (Software Requirement Specification)
document is created. This document should be thoroughly understood by the developers and also
should be reviewed by the customer for future reference.

#2) Design
In this phase, the requirement gathered in the SRS document is used as an input and software
architecture that is used for implementing system development is derived.

#3) Implementation or Coding

Implementation/Coding starts once the developer gets the Design document. The Software design is
translated into source code. All the components of the software are implemented in this phase.

#4) Testing
Testing starts once the coding is complete and the modules are released for testing. In this phase,
the developed software is tested thoroughly and any defects found are assigned to developers to get
them fixed.

Retesting, regression testing is done until the point at which the software is as per the customer’s
expectation. Testers refer SRS document to make sure that the software is as per the customer’s
standard.

#5) Deployment
Once the product is tested, it is deployed in the production environment or first (UAT) User
Acceptance Testing is done depending on the customer expectation.
In the case of UAT, a replica of the production environment is created and the customer along with
the developers does the testing. If the customer finds the application as expected, then sign off is
provided by the customer to go live.

#6) Maintenance
After the deployment of a product on the production environment, maintenance of the product i.e.
if any issue comes up and needs to be fixed or any enhancement is to be done is taken care by the
developers.

Software Development Life Cycle Models

A software life cycle model is a descriptive representation of the software development cycle. SDLC
models might have a different approach but the basic phases and activity remain the same for all the
models.

#1) Waterfall Model

Waterfall Model is the very first model that is used in SDLC. It is also known as the linear sequential
model.
In this model, the outcome of one phase is the input for the next phase. Development of the next
phase starts only when the previous phase is complete.

 First, Requirement gathering and analysis is done. Once the requirement is freeze then only
the System Design can start. Herein, the SRS document created is the output for the
Requirement phase and it acts as an input for the System Design.
  In System Design Software architecture and Design, documents which act as an input for the
next phase are created i.e. Implementation and coding.
 In the Implementation phase, coding is done and the software developed is the input for the
next phase i.e. testing.
 In the testing phase, the developed code is tested thoroughly to detect the defects in the
software. Defects are logged into the defect tracking tool and are retested once fixed. Bug
logging, Retest, Regression testing goes on until the time the software is in go-live state.
 In the Deployment phase, the developed code is moved into production after the sign off is
given by the customer.
 Any issues in the production environment are resolved by the developers which come under
maintenance.

Advantages of the Waterfall Model:

 Waterfall model is the simple model which can be easily understood and is the one in which
all the phases are done step by step.
 Deliverables of each phase are well defined, and this leads to no complexity and makes the
project easily manageable.
Disadvantages of Waterfall model:
 Waterfall model is time-consuming & cannot be used in the short duration projects as in this
model a new phase cannot be started until the ongoing phase is completed.
 Waterfall model cannot be used for the projects which have uncertain requirement or
wherein the requirement keeps on changing as this model expects the requirement to be
clear in the requirement gathering and analysis phase itself and any change in the later
stages would lead to cost higher as the changes would be required in all the phases.
#3) Prototype Model
The prototype model is a model in which the prototype is developed prior to the actual software.

Prototype models have limited functional capabilities and inefficient performance when compared
to the actual software. Dummy functions are used to create prototypes. This is a valuable
mechanism for understanding the customers’ needs.

Software prototypes are built prior to the actual software to get valuable feedback from the
customer. Feedbacks are implemented and the prototype is again reviewed by the customer for any
change. This process goes on until the model is accepted by the customer.

Once the requirement gathering is done, the quick design is created and the prototype which is
presented to the customer for evaluation is built.

Customer feedback and the refined requirement is used to modify the prototype and is again
presented to the customer for evaluation. Once the customer approves the prototype, it is used as a
requirement for building the actual software. The actual software is build using the Waterfall model
approach.

Advantages of Prototype Model:

 Prototype model reduces the cost and time of development as the defects are found much
earlier.
 Missing feature or functionality or a change in requirement can be identified in the
evaluation phase and can be implemented in the refined prototype.
 Involvement of a customer from the initial stage reduces any confusion in the requirement
or understanding of any functionality.
Disadvantages of Prototype Model:
 Since the customer is involved in every phase, the customer can change the requirement of
the end product which increases the complexity of the scope and may increase the delivery
time of the product.
#4) Spiral Model
The Sprial Model  includes iterative and prototype approach.
Spiral model phases are followed in the iterations. The loops in the model represent the phase of the
SDLC process i.e. the innermost loop is of requirement gathering & analysis which follows the
Planning, Risk analysis, development, and evaluation. Next loop is Designing followed by
Implementation & then testing.
Spiral Model has four phases:
 Planning
 Risk Analysis
 Engineering
 Evaluation

(i) Planning:
The planning phase includes requirement gathering wherein all the required information is gathered
from the customer and is documented. Software requirement specification document is created for
the next phase.

(ii) Risk Analysis:

In this phase, the best solution is selected for the risks involved and analysis is done by building the
prototype.

For Example, the risk involved in accessing the data from a remote database can be that the data
access rate might be too slow. The risk can be resolved by building a prototype of the data access
subsystem.
(iii) Engineering:
Once the risk analysis is done, coding and testing are done.

(iv) Evaluation:
Customer evaluates the developed system and plans for the next iteration.

Advantages of Spiral Model:

 Risk Analysis is done extensively using the prototype models.
 Any enhancement or change in the functionality can be done in the next iteration.
Disadvantages of Spiral Model:
 The spiral model is best suited for large projects only.
 The cost can be high as it might take a large number of iterations which can lead to high time
to reach the final product.
 
#5) Iterative Incremental Model 

Incremental Model is a process of software development where requirements divided into multiple
standalone modules of the software development cycle. In this model, each module goes through
the requirements, design, implementation and testing phases. Every subsequent release of the
module adds function to the previous release. The process continues until the complete system
achieved.

The various phases of incremental model are as follows:

1. Requirement analysis: In the first phase of the incremental model, the product analysis expertise
identifies the requirements. And the system functional requirements are understood by the
requirement analysis team. To develop the software under the incremental model, this phase
performs a crucial role.

2. Design & Development: In this phase of the Incremental model of SDLC, the design of the system
functionality and the development method are finished with success. When software develops new
practicality, the incremental model uses style and development phase.

3. Testing: In the incremental model, the testing phase checks the performance of each existing
function as well as additional functionality. In the testing phase, the various methods are used to
test the behavior of each task.

9.5M
 197
Java Try Catch

4. Implementation: Implementation phase enables the coding phase of the development system. It

involves the final coding that design in the designing and development phase and tests the
functionality in the testing phase. After completion of this phase, the number of the product working
is enhanced and upgraded up to the final system product

When we use the Incremental Model?

o When the requirements are superior.

o A project has a lengthy development schedule.
o When Software team are not very well skilled or trained.
o When the customer demands a quick release of the product.
o You can develop prioritized requirements first.

Advantage of Incremental Model

o Errors are easy to be recognized.

o Easier to test and debug
o More flexible.
o Simple to manage risk because it handled during its iteration.
o The Client gets important functionality early.

Disadvantage of Incremental Model

o Need for good planning

o Total Cost is high.
o Well defined module interfaces are needed.

System
What is a System?

The word System is derived from Greek word Systema, which means an organized relationship
between any set of components to achieve some common cause or objective.
A system is “an orderly grouping of interdependent components linked together according to a plan
to achieve a specific goal.”
Characteristics and types of system

Organization

Organization implies structure and order. It is the arrangement of components that helps to
achieve predetermined objectives.

Interaction

It is defined by the manner in which the components operate with each other.
For example, in an organization, purchasing department must interact with production department
and payroll with personnel department.

Interdependence

Interdependence means how the components of a system depend on one another. For proper
functioning, the components are coordinated and linked together according to a specified plan. The
output of one subsystem is the required by other subsystem as input.

Integration

Integration is concerned with how a system components are connected together. It means that the
parts of the system work together within the system even if each part performs a unique function.

Central Objective

The objective of system must be central. It may be real or stated. It is not uncommon for an
organization to state an objective and operate to achieve another.
The users must know the main objective of a computer application early in the analysis for a
successful design and conversion.

Elements of a System

The following diagram shows the elements of a system −

Outputs and Inputs

 The main aim of a system is to produce an output which is useful for its user.
 Inputs are the information that enters into the system for processing.
 Output is the outcome of processing.

Processor(s)

 The processor is the element of a system that involves the actual transformation of input
into output.
 It is the operational component of a system. Processors may modify the input either totally
or partially, depending on the output specification.
 As the output specifications change, so does the processing. In some cases, input is also
modified to enable the processor for handling the transformation.

Control

 The control element guides the system.

 It is the decision–making subsystem that controls the pattern of activities governing input,
processing, and output.
 The behavior of a computer System is controlled by the Operating System and software. In
order to keep system in balance, what and how much input is needed is determined by
Output Specifications.

Feedback

 Feedback provides the control in a dynamic system.

 Positive feedback is routine in nature that encourages the performance of the system.
  Negative feedback is informational in nature that provides the controller with information
for action.

Environment

 The environment is the “supersystem” within which an organization operates.

 It is the source of external elements that strike on the system.
 It determines how a system must function. For example, vendors and competitors of
organization’s environment, may provide constraints that affect the actual performance of
the business.

Boundaries and Interface

 A system should be defined by its boundaries. Boundaries are the limits that identify its
components, processes, and interrelationship when it interfaces with another system.
 Each system has boundaries that determine its sphere of influence and control.
 The knowledge of the boundaries of a given system is crucial in determining the nature of
its interface with other systems for successful design.

Types of Systems
The systems can be divided into the following types −

Physical or Abstract Systems

 Physical systems are tangible entities. We can touch and feel them.
 Physical System may be static or dynamic in nature. For example, desks and chairs are the
physical parts of computer center which are static. A programmed computer is a dynamic
system in which programs, data, and applications can change according to the user's needs.
 Abstract systems are non-physical entities or conceptual that may be formulas,
representation or model of a real system.

Open or Closed Systems

 An open system must interact with its environment. It receives inputs from and delivers
outputs to the outside of the system. For example, an information system which must
adapt to the changing environmental conditions.
 A closed system does not interact with its environment. It is isolated from environmental
influences. A completely closed system is rare in reality.

Natural and Manufactured System

 Natural systems are created by the nature. For example, Solar system, seasonal system.
  Manufactured System is the man-made system. For example, Rockets, dams, trains.

Deterministic or Probabilistic System

 Deterministic system operates in a predictable manner and the interaction between system
components is known with certainty. For example, two molecules of hydrogen and one
molecule of oxygen makes water.
 Probabilistic System shows uncertain behavior. The exact output is not known. For example,
Weather forecasting, mail delivery.

Man–Made Information Systems

 It is an interconnected set of information resources to manage data for particular

organization, under Direct Management Control (DMC).
 This system includes hardware, software, communication, data, and application for
producing information according to the need of an organization.
Man-made information systems are divided into three types −
 Formal Information System − It is based on the flow of information in the form of memos,
instructions, etc., from top level to lower levels of management.
 Informal Information System − This is employee based system which solves the day to day
work related problems.
 Computer Based System − This system is directly dependent on the computer for managing
business applications. For example, automatic library system, railway reservation system,
banking system, etc

Project Communication Management

Project communication management is a collection of processes that help make sure the right

messages are sent, received, and understood by the right people. 

Project communication management is one of the 10 key knowledge areas in the PMBOK (Project

Management Book of Knowledge). The processes included in this area have changed over the years

but, in the current version, there are three primary project communication management processes.

These are:

1. Plan communications management

2. Manage communications

3. Monitor communications
How to create a project communication management plan

Project managers need to clearly outline how they will manage communications across their

projects. This is done by creating a project communication management plan.

When creating a plan, project managers should follow these five steps:

1. Decide your objectives: What will be the purpose of your communication? You may use
some communication tools for awareness, such as a status report. Others may require
action, such as requiring a sponsor to authorize spending or a customer to approve project
testing.

2. Determine your audience: Who are the stakeholder in this project? You should make an
extensive list of everyone involved. Consider anyone impacted by the project or who
influences its success. This list should include team members, sponsors, customers, and
other interested parties.

3. Write your message: What will the message be for each type of communication? This is the
actual content that will be shared. Key components to be communicated include
scope, schedule, budget, objectives, risks, and deliverables.

4. Choose your channel: How will the message be delivered? Will it be a formal report emailed
out to all stakeholders? Or will it be an informal verbal debrief during a team meeting?

5. Set a timeline: When will you deliver your message? Do your stakeholders require weekly or
monthly reports? Is there a deadline to meet? Consider varying time zones and employee
schedules here.

Your project communication management plan should be detailed enough to lay out why you’re

sending a message, who you’re sending it to, what specific information will be sent, how you’re

going to send it, and when.

Involving your stakeholders in the creation of this plan is important. You need to understand their

communication preferences and expectations. If you over-communicate, they may stop paying

attention. But, if you under-communicate, it can lead to misunderstandings and issues.

The golden rule here is that, to be a good communicator, you need to be a good listener. Pay

attention to all the factors and take every opinion into account before creating your project

communication management plan.

Manage Project Communication
Once the project communication management plan has been created and approved, it’s the project

manager’s job to ensure it’s carried out successfully. This means the plan needs to be reviewed and

updated on a regular basis to reflect any changes to the project or its stakeholders. 

The project manager also has to manage the execution of the project communication management

plan. This includes:

1. Collection and analysis of data

2. Creation of messages for communication

3. Transmission or distribution of communications

4. Storage of any communication reports, files, or documents

5. Retrieval of any stored communications

6. Disposal of any old communications upon project closure or a set date

Monitor project communication

This process used to be called ‘control communications,’ but was updated in the sixth edition of the

PMBOK. Despite the title change, the process is the same. It involves monitoring and controlling

project communications throughout the entire lifecycle.

This may include the confirmation of the following:

 Communications went out as planned

 They were received by the proper stakeholders

 Messages were understood

 Any relevant feedback was provided to the appropriate project members

The actual type of monitoring, including method and frequency, should be a part of the project

communication management plan.

The Risk Management in Project Management

Project risk management is the process of identifying, analyzing and responding to any risk that

arises over the life cycle of a project to help the project remain on track and meet its goal. Risk

management isn’t reactive only; it should be part of the planning process to figure out risk that

might happen in the project and how to control that risk if it in fact occurs.

A risk is anything that could potentially impact your project’s timeline, performance or budget. Risks

are potentialities, and in a project management context, if they become realities, they then become

classified as “issues” that must be addressed. So risk management, then, is the process of

identifying, categorizing, prioritizing and planning for risks before they become issues.

Risk management can mean different things on different types of projects. On large-scale projects,

risk management strategies might include extensive detailed planning for each risk to ensure

mitigation strategies are in place if issues arise. For smaller projects, risk management might mean a

simple, prioritized list of high, medium and low priority risks.

How to Manage Risk

To begin managing risk, it’s crucial to start with a clear and precise definition of what your project

has been tasked to deliver. In other words, write a very detailed project charter, with your project

vision, objectives, scope and deliverables. This way risks can be identified at every stage of the

project. Then you’ll want to engage your team early in identifying any and all risks.

Don’t be afraid to get more than just your team involved to identify and prioritize risks, too. Many

project managers simply email their project team and ask to send them things they think might go

wrong on the project. But to better plot project risk, you should get the entire project team, your

clients’ representatives, and vendors into a room together and do a risk identification session.
With every risk you define, you’ll want to log it somewhere—using a risk tracking template helps you

prioritize the level of risk. Then, create a risk management plan to capture the negative and positive

impacts to the project and what actions you will take to deal with them. You’ll want to set up regular

meetings to monitor risk while your project is ongoing. Transparency is critical.

6 Steps in the Risk Management Process

Identify the Risk

You can’t resolve a risk if you don’t know what it is. There are many ways to identify risk. As you do

go through this step, you’ll want to collect the data in a risk register.

One way is brainstorming with your team, colleagues or stakeholders. Find the individuals with

relevant experience and set up interviews so you can gather the information you’ll need to both

identify and resolve the risks. Think of the many things that can go wrong. Note them. Do the same

with historical data on past projects. Now your list of potential risk has grown.

Make sure the risks are rooted in the cause of a problem. Basically, drill down to the root cause to

see if the risk is one that will have the kind of impact on your project that needs identifying. When

trying to minimize risk, it’s good to trust your intuition. This can point you to unlikely scenarios that

you just assume couldn’t happen. Remember, don’t be overconfident. Use process to weed out risks

from non-risks.
Analyze the Risk

Analyzing risk is hard. There is never enough information you can gather. Of course, a lot of that data

is complex, but most industries have best practices, which can help you with your analysis. You

might be surprised to discover that your company already has a framework for this process.

When you assess project risk you can ultimately and proactively address many impacts, such as

avoiding potential litigation, addressing regulatory issues, complying with new legislation, reducing

your exposure and minimizing impact.

So, how do you analyze risk in your project? Through qualitative and quantitative risk analysis, you

can determine how the risk is going to impact your schedule and budget.

Project management software helps you analyze risk by monitoring your

project. ProjectManager takes that one step further with real-time dashboards that display live data.

Unlike other software tools, you don’t have to set up our dashboard. It’s ready to give you a high-

level view of your project from the get-go. We calculate the live date and then display it for you in

easy-to-read graphs and charts. Catch issues faster as you monitor time, costs and more.

Prioritize the Risk

Not all risks are created equally. You need to evaluate the risk to know what resources you’re going

to assemble towards resolving it when and if it occurs.

Having a large list of risks can be daunting. But you can manage this by simply categorizing risks as

high, medium or low. Now there’s a horizon line and you can see the risk in context. With this

perspective, you can begin to plan for how and when you’ll address these risks.

Some risks are going to require immediate attention. These are the risks that can derail your project.

Failure isn’t an option. Other risks are important, but perhaps not threatening the success of your

project. You can act accordingly. Then there are those risks that have little to no impact on the

overall project’s schedule and budget. Some of these low-priority risks might be important, but not

enough to waste time on.

Assign an Owner to the Risk

All your hard work identifying and evaluating risk is for naught if you don’t assign someone to

oversee the risk. In fact, this is something that you should do when listing the risks. Who is the

person who is responsible for that risk, identifying it when and if it should occur and then leading the

work towards resolving it?

That determination is up to you. There might be a team member who is more skilled or experienced

in the risk. Then that person should lead the charge to resolve it. Or it might just be an arbitrary

choice. Of course, it’s better to assign the task to the right person, but equally important in making

sure that every risk has a person responsible for it.

Think about it. If you don’t give each risk a person tasked with watching out for it, and then dealing

with resolving it when and if it should arise, you’re opening yourself up to more risk. It’s one thing to

identify risk, but if you don’t manage it then you’re not protecting the project.

Respond to the Risk

Now the rubber hits the road. You’ve found a risk. All that planning you’ve done is going to be put to

use. First you need to know if this is a positive or negative risk. Is it something you could exploit for

the betterment of the project?

For each major risk identified, you create a plan to mitigate it. You develop a strategy, some

preventative or contingency plan. You then act on the risk by how you prioritized it. You have

communications with the risk owner and, together, decide on which of the plans you created to

implement to resolve the risk.

Monitor the Risk

You can’t just set forces against a risk without tracking the progress of that initiative. That’s where

the monitoring comes in. Whoever owns the risk will be responsible for tracking its progress towards

resolution. But you will need to stay updated to have an accurate picture of the project’s overall

progress to identify and monitor new risks.

You’ll want to set up a series of meetings to manage the risks. Make sure you’ve already decided on

the means of communications to do this. It’s best to have various channels dedicated to

communication.

Whatever you choose to do, remember: always be transparent. It’s best if everyone in the project

knows what is going on, so they know what to be on the lookout for and help manage the process.