Software Engineering and Project Management PPT of Module 1
Software Engineering and Project Management PPT of Module 1
4. Embedded Software:
These are resides within the system or product and is used to implement, control
features and functions for the end-user and for the system itself..
• Security: Because WebApps are available via network access sensitive content must be
protected and secure modes of data transmission must be provided.
• Aesthetics: An undeniable part of the appeal of a WebApp is its look and feel
Software Engineering
Software: It is a collection of integrated programs.
It carefully organized the instructions and code written by the developers on
any of various particular computer languages.
It is a set of instructions, data or programs that tells a computer how to operate
and perform the tasks.
Engineering: It is the application of scientific and practical knowledge to
invent, design, build, maintain and improve the frameworks, processes etc.
Software Engineering: It is an engineering branch related to the
evolution of software products using well defined scientific principles, techniques
and procedures.
The result of software engineering is an effective and reliable software products.
Need of Software Engineering
1.Handling of Big Projects: The organizations uses Software Engineering to
handle large projects without any issues.
2.To manage the cost: Software Engineering programmers plan everything and
reduces all those things which are not required.
3.To decrease time: Developing a software using software engineering
techniques, will save the lot of time.
4.Reliable Software: It is the responsibility of organization to deliver the
products on schedule and to address any defects which may exist.
5.Effectiveness: Effectiveness results from the things being created in
accordance with the software standards.
The Software Process:
A process is a collection of activities, actions, and tasks that are performed
when some work product is to be created.
An activity strives to achieve a broad objective (e.g. communication with
stakeholders) and is applied regardless of the application domain, size of the
project, complexity of the effort, or degree of rigor with which software
engineering is to be applied.
An action (e.g., architectural design) encompasses a set of tasks that produce a
major work product (e.g., an architectural design model).
A task focuses on a small, but well-defined objective (e.g., conducting a unit
test) that produces a tangible outcome.
Software engineers carry out these activities:
Software Evolution: The software must evolve to meet changing client needs.
Software Engineering Practice:
The Essence of Practice:
• The essence of problem solving is essentially the essence of software
engineering practice. Here we try to answer some of the questions under
different phases of problem solving.
• Understand the problem (communication and analysis).
○ Who has a stake in the solution to the problem?
○ What are the unknowns?
○ Can the problem be represented graphically?
• Plan a solution (modeling and software design).
o Have you seen similar problems before?
o Has a similar problem been solved?
o Can subproblems be defined?
• Carry out the plan (code generation).
○ Does the solution produce results that conform to the data, functions, and
features that are required?
Core Principles of Software Engineering Practices:
Principle – Guidelines and best practices that help ensure software is well-structured,
efficient and maintainable.
David Hooker has proposed 7 core Principles that focus on Software Engineering
Practice.
Following are the Principles:
1. The Reason it all Exists: A software system exists for one reason, to provide value
to its users.
All decisions should be made before specifying a system requirements, before noting
a piece of system functionality, before determining the platforms or development
process
2. Keep It Simple Stupid: All design should be as simple as possible, but no simpler.
This facilitates having a more easily understood, and easily maintained system.
3. Maintain the Vision: A clear vision is essential to the success of software project.
4. What you produce, others will consume: In some way or other, someone else
will use, maintain, document or otherwise depend on being able to understand
your system.
so always specify, design, and implement knowing someone else will have to
understand what you are doing.
5. Be Open to the Future: In today’s computing environments, where
specifications change on a moment’s notice and hardware platforms are obsolete
when just a few months old, software lifetimes are typically measured in months
instead of years. Never design yourself into a corner.
6. Plan ahead for Software Reuse: It reduces the cost and increases the value of
both the reusable components and systems into which they are incorporated.
7. Think: Placing clear, complete thought before action almost always
produces better results . When you think about something, you are more likely to
do it right.
Software Myths
• Software myths are erroneous beliefs about software and the process that is used
to build it. We categorize myths from three different perspectives.
1. Management Myths
• Myth: We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they need to
know?
Reality
• Are software practitioners aware of existence standards?
• Does it reflect modern software engineering practice?
• Is it complete? Is it streamlined to improve time to delivery while still
maintaining a focus on quality?
In many cases, the answer to all of these questions is "no."
• Myth: If we get behind schedule, we can add more programmers and catch up
(sometimes called the “Mongolian horde” concept).
• Reality: Software development is not a mechanistic process like manufacturing.
As new people are added, people who are working must spend time educating
the newcomers, thereby reducing the amount of time spent on productive
development effort. People can be added but only in a planned and well
coordinated manner.
• Myth: If I decide to outsource the software project to a third party, I can just
relax and let that firm build it.
• Reality: If an organization does not understand how to manage and control
software projects internally, it will invariably struggle when it out-sources
software project.
2. Customer Myths
• Myth: A general statement of objectives is sufficient to begin writing programs
—we can fill in the details later.
• Reality: Although a comprehensive and stable statement of requirements is not
always possible, an ambiguous “statement of objectives” is a recipe for
disaster.
• A process was defined as a collection of work activities, actions, and tasks that
are performed when some work product is to be created.
• Each of these activities, actions, and tasks reside within a framework or model
that defines their relationship with the process and with one another.
• The generic process model is description of the software development process.
• It is used in the most software models since it provides a base for them.
• A generic process framework for software engineering defines five framework
activities — communication, planning, modeling, construction, and
deployment.
• Each framework activity is populated by a set of software engineering actions
• Each software engineering action is defined by a task set that identifies the work
tasks that are to be completed, the work products that will be produced, the
quality assurance points that will be required, and the milestones that will be
used to indicate progress.
• One important aspect of the software process called process flow—describes
how the framework activities and the actions and tasks that occur within each
framework activity are organized with respect to sequence and time.
1.Tasks: They focus on a small, specific objective.
2.Action: It is a set of tasks that produce a major work product.
3.Activities: Activities are groups of related tasks and actions for a major
objective.
Process Framework Activities
A process is a collection of activities, actions, and tasks that are performed when
some work product is to be created.
A generic process framework for software engineering encompasses five
activities:
1. Communication:
The software development starts with the communication between customer
and developer.
Developer gather requirements of the project with the users.
Communication with customers and stakeholders to determine the system’s
objectives, software requirements and features.
2. Planning:
It consists of complete estimation, scheduling for project development and
tracking.
Discuss work plan, technical risk, list of resource requirements, work produced
and work schedule.
3. Modeling:
Develop a practical model to get a better understanding of the project.
It consists of complete requirement analysis and design of the project like
algorithm, flowchart.
The algorithm is a step by step solution of the problem
The flow chart shows the complete flow diagram of the problem.
4. Construction:
It consists of code generation and testing part.
Coding part implements the design details using an appropriate programming
language.
Testing is to check whether the flow of coding is correct or not.
Testing also check that the program provides the desired output or not.
5. Deployment:
The software (as a complete entity or as a partially completed increment) is
delivered to the customer who evaluates the delivered product and provides
feedback based on the evaluation.
If the customer wanted some correction or demands for the additional
capabilities, then the change is required for improvement in the quality of the
software.
Umbrella Activities
Activities that occurs throughout a software process for better management and
tracking of the project.
Software project tracking and control: Compare the progress of the project
with the plan and take steps to maintain a planned schedule.
Risk management: Analyze any potential risks that may have an impact on the
software product’s quality and outcome.
Technical reviews: Assessment of errors and correction done at each stage of
activity.
Software quality assurance (SQA): defines and conducts the activities
required to ensure software quality.
Measurement: defines and collects process, project, and product measures that
assist the team in delivering software that meets stakeholders’ needs
Software configuration management(SCM):
Managing the configuration process when any changes occurs in the software
Reusability management
Reusable work items should be backed up, and reusable software components
should achieved.
Work product preparation and production
The activities to create models, documents, logs, forms and lists are carried out.
Framework Activities
Consider Communication Activity for small projects:
Making a phone call with stakeholders.
Discuss requirements and note them.
Organize the requirements.
Mail to stakeholders for review and approval
Consider Communication Activity for large projects:
Arrange live meeting
Complete feasibility study
Requirements analysis
Specification of documents.
Identifying Task Sets:
Task set is the actual work to be done to achieve an objective of each engineering
module.
Consider Communication Activity Task Set:
Prepare a list of stakeholders of the project
Organize the meeting for stakeholders.
Discuss the requirements.
Finalize the requirements list
Make a list of issues raised.
Software Process Assessment
• The Software Process Assessment includes many fields and parts like
identification and characterization of current practices, the ability of current
practices to control or avoid significant causes of poor (software) quality, cost,
schedule and identifying areas of strengths and weaknesses of the software.
Types of Software Assessment :
• Self Assessment: This is conducted internally by the people of their own
organization.
• Second Party assessment: This is conducted by an external team or people of
the own organization are supervised by an external team.
• Third Party assessment: a process for evaluating and quantifying the risks
associated with third-party vendors, suppliers, or partners
PROCESS ASSESSMENT AND IMPROVEMENT
Standard CMMI Assessment Method for Process Improvement (SCAMPI)
- provides a five-step process assessment model that incorporates five phases:
initiating, diagnosing, establishing, acting, and learning. The SCAMPI method
uses the SEI CMMI as the basis for assessment.
CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
- provides a diagnostic technique for assessing the relative maturity of a software
organization; uses the SEI CMM as the basis for the assessment.
SPICE (ISO/IEC15504)
- a standard that defines a set of requirements for software process assessment. The
intent of the standard is to assist organizations in developing an objective
evaluation of the efficacy of any defined software process.
ISO 9001:2000 for Software: a generic standard that applies to any
organization that wants to improve the overall quality of the products, systems,
or services that it provides
Process Technology
Software Development Life Cycle (SDLC):
Software development life cycle (SDLC) is a structured process that is used to
design, develop, and test good-quality software. SDLC, or software
development life cycle, is a methodology that defines the entire procedure of
software development step-by-step.
Need of SDLC Process:
Improves relation with client and development team
It offers basic project planning, scheduling and cost estimation.
Increase and enhance development speed.
Maintain project tracking and control
Decrease any type of project risk.
Decide entry and exit criteria of each phase.
Prescriptive Process Models
• The following framework activities are carried out irrespective of the process
model chosen by the organization.
1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment
Types of Prescriptive Process Models
Waterfall Model
Waterfall Model
• This model is not good for complex and object oriented projects.
• It is a poor model for long projects.
• The problems with this model are uncovered, until the software testing.
• The amount of risk is high.
Incremental Process Model
Incremental Process Model
The incremental model combines elements of linear and parallel process flows.
When an incremental model is used, the first increment is often a core product.
That is, basic requirements are addressed but many supplementary features
(some known, others unknown) remain undelivered.
The core product is used by the customer (or undergoes detailed evaluation).
As a result of use and/or evaluation, a plan is developed for the next increment.
The plan addresses the modification of the core product to better meet the
needs of the customer and the delivery of additional features and functionality.
This process is repeated following the delivery of each increment, until the
complete product is produced.
focuses on the delivery of an operational product with each increment.
Phases of Incremental Model
• Requirement analysis: In Requirement Analysis At any time, the plan is made
just for the next increment and not for any kind of long-term plan. Therefore, it
is easier to modify the version as per the needs of the customer.
• Design & Development: At any time, the plan is made just for the next
increment and not for any kind of long-term plan. Therefore, it is easier to
modify the version as per the needs of the customer.
• The Development Team first undertakes to develop core features (these do not
need services from other features) of the system. Once the core features are
fully developed, then these are refined to increase levels of capabilities by
adding new functions in Successive versions.
• Each incremental version is usually developed using an iterative waterfall
model of development.
• Deployment and Testing: After Requirements gathering and specification,
requirements are then split into several different versions starting with version
1, in each successive increment, the next version is constructed and then
deployed at the customer site. in development and Testing the product is
checked and tested for the actual process of the model.
Merits:
Leads to software reuse, which provides number of benefits
• 70% reduction in development cycle time
• 84 % reduction in project cost
• Productivity index goes up to 26.2 ( Norm : 16.9)
Demerits:
Component Library must be robust.
Performance may degrade
The Formal Methods Model:
The formal methods model encompasses a set of activities that lead to
formal mathematical specification of computer software.
It consists of specifications, development & verification by applying
rigorous mathematical notation. Example, Clean Room S/W Engineering
(CRSE)
• Merits:
Removes many of the problems that are difficult to remove using other
S/W Engg. Paradigms.
Ambiguity, Incompleteness & Inconsistency can be discovered & corrected
easily by using formal methods of mathematical analysis.
• Demerits:
Development is time consuming & expensive
Extensive training is required
Aspect Oriented Software Development (AOSD):
• A set of localized features, functions & information contents are used while building
complex software.
• These localized s/w characteristics are modeled as components (e.g. OO classes) & then
constructed within the context of a system architecture.
• Certain “concerns” (Customer required properties or areas of technical interest) span the
entire architecture i.e. Cross cutting Concerns like system security, fault tolerance etc.
Merits:
It is similar to component based development for aspects
Demerits:
Component Library must be robust.
Performance may degrade
SPECIALIZED PROCESS MODELS
Component-Based Development
• Commercial off-the-shelf (COTS) software components, developed by vendors
who offer them as products, provide targeted functionality with well-defined
interfaces that enable the component to be integrated into the software that is to
be built.
• The component-based development model incorporates many of the
characteristics of the spiral model.
• It is evolutionary in nature, demanding an iterative approach to the creation of
software. However, the component-based development model constructs
applications from prepackaged software components.
• Modeling and construction activities begin with the identification of candidate
components.
Model incorporates the following steps:
1.Available component-based products are researched and evaluated for the
application domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
• leads to software reuse, and reusability provides software engineers with a
number of measurable benefits.
The Formal Methods Model
• encompasses a set of activities that leads to formal mathematical specification
of computer software. Formal methods enable you to specify, develop, and
verify a computer-based system by applying a rigorous, mathematical notation.
A variation on this approach, called cleanroom software engineering
• The development of formal models is currently quite time consuming and
expensive.
• Because few software developers have the necessary background to apply
formal methods, extensive training is required.
• It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
Aspect-Oriented Software Development
• provides a process and methodological approach for defining, specifying,
designing, and constructing aspects—“mechanisms beyond subroutines and
inheritance for localizing the expression of a crosscutting concern”.
• Common, systemic aspects include user interfaces, collaborative work,
distribution, persistency, memory management, transaction processing, security,
integrity and so on. Components may provide or require one or more “aspect
details” relating to a particular aspect