0% found this document useful (0 votes)
33 views74 pages

Software Engineering and Project Management PPT of Module 1

The document outlines the fundamentals of software and software engineering, including definitions, characteristics, and various software application domains. It discusses the software engineering process, including specifications, development, validation, and evolution, while emphasizing the importance of effective communication, planning, modeling, construction, and deployment. Additionally, it addresses common software myths and process models, highlighting the need for structured practices in software development to ensure reliability and efficiency.

Uploaded by

praveenm365
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
33 views74 pages

Software Engineering and Project Management PPT of Module 1

The document outlines the fundamentals of software and software engineering, including definitions, characteristics, and various software application domains. It discusses the software engineering process, including specifications, development, validation, and evolution, while emphasizing the importance of effective communication, planning, modeling, construction, and deployment. Additionally, it addresses common software myths and process models, highlighting the need for structured practices in software development to ensure reliability and efficiency.

Uploaded by

praveenm365
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 74

Module 1

Software and Software Engineering:


Syllabus
 Software and Software Engineering:
 The nature of Software
 The unique nature of WebApps,
 Software Engineering
 The Software Process
 Software Engineering Practice
 Software Myths
Process Models
 A generic process model
 Process assessment and improvement
Prescriptive Process Models:
 Waterfall Model
 Incremental Process Models
 Evolutionary Process Models
 Concurrent Models
 Specialized Process Models
 Unified Process
 Personal and Team Process Models
Defining Software
• Software is:
(1) instructions (computer programs) that when executed provide desired
features, function, and performance
(2) data structures that enable the programs to effectively manipulate
information
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.
Characteristics of Software
Operational Transitional Maintenance
Budget Interoperability Flexibility
Efficiency Reusability Maintainability
Usability Portability Modularity
Dependability Adaptability Scalability
Correctness
Functionality
safety
Efficiency: Measuring the output of work as compared to the expected
outcome.
Usability: Measure of how well a software product can be used by its users
to achieve their goals.
Dependability: Measure of how trustworthy a system is, and how well it
meets user expectations.
It is a measure of system’s availability, reliability, maintainability.
Correctness: The ability of software products to perform their exact tasks,
as defined by their specifications.
Functionality: The ability of software applications to perform specific
tasks or operations and to provide value to its users.
Safety: It ensures that software used in safety-related systems doesn’t
contribute to any hazards.
Interoperability: The ability of software to exchange and make use of
information.
Reusability: The practice of reusing existing assets, such as code,
components, designs and documentation in the development of new software.
Portability: The ability to run a computer program on different Operating
Systems with minimal rework.
Adaptability: The ability of a software systems or parts of it to adapt to
changing requirements.
• Flexibility: The ability of a software systems to adopt to different
situations, environments, and needs, without requiring significant
changes to its code or structure.
• Maintainability: It measures how easily a software system can be
modified, enhanced or repaired.
• Modularity: It is the practice of dividing a software system into
independent modules, each with its own function.
• Scalability: The ability to handle workload variation while adding or
removing users with minimal costs.
Nature of Software
Software Application Domains:
1.System Software:
 System software is a software designed to provide the platform for the other
software’s.
 It is an interaction between hardware and application software.
Example: Operating systems like macOS, Linux, Android and Microsoft
Windows etc.
2. Application Software:
 Application software is a computer program designed to carry out a specific task
as per user & business need.
Example: Social media apps, Gaming apps, Word processing apps, Shopping
3.Engineering and Scientific Software:
 This software is used to facilitate the engineering functions and tasks takes the
real time.
 It is high accuracy and data analysis..

Example: Weather prediction apps, Stock market apps, Stress analysis.

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

Example: Washing machine, Air cooler, fridge etc.


5.Web Applications:
 It is a client server computer program which the client runs on web browser.
 Web apps can be little more than a set of linked hypertext files that present
information using text and limited graphics.
Example: Online forms, Shopping carts, Gmail, Photo editing, File conversion
etc.
6. Artificial Intelligence Software:
 It makes use of a nonnumerical algorithm to solve the complex problems.
 Application within this area includes robotics, expert system, pattern
recognition, artificial neural network.
Example: Google Cloud, Azure studio, Salesforce.
The Unique Nature of WebApps:
• In the early days of the World Wide Web, websites were just a set of linked
hypertext files which presented information using text and limited graphics.
• The augmentation of HTML by development tools like Java, XML enabled web
engineers to provide computing capability along with informational content.
• WebApps provides not only standalone function to the end user but also have
been integrated with corporate databases and business applications.
• Web-based systems and applications “involve a mixture between print
publishing and software development, between marketing and computing,
between internal communications and external relations, and between art and
technology.”
The following are the common attributes for WebApps:
• Network intensiveness: A WebApp resides on a network (Internet or Intranet)
and must serve the needs of a diverse community of clients.
• Concurrency: A large number of users may access the WebApp at one time.
• Unpredictable load. The number of users of the WebApp may vary by orders
of magnitude from day to day.
• Performance: If a WebApp user must wait too long, he or she may decide to go
elsewhere.
• Availability: Although the expectation of 100 percent availability is
unreasonable, users of popular WebApps often demand access on a 24/7/365
basis.
• Data driven: The primary function of many WebApps is to use hypermedia to
present text, graphics, audio, and video content to the end user
• Content sensitive: The quality and aesthetic nature of content remains an important
determinant of the quality of a WebApp.

• Continuous evolution: Unlike conventional application software that evolves over a


series of planned, chronologically spaced releases, Web applications evolve continuously.

• Immediacy: It is need to get software to market quickly and it is characteristics of many


application domains, WebApps often exhibit a time-to-market that can be a matter of a
few days or weeks.

• 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 Specifications: The functionality of the software and constraints on


its operation must be defined.

Software Development: The software to meet the requirement must be


produced.

Software Validation: The software must be validated to ensure that it does


what the customer wants.

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 conform to the plan?

○ Is each component part of the solution provably correct?

• Examine the result for accuracy (testing and quality assurance).

○ Is each component part of the solution provably correct?

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

• Myth: Software requirements continually change, but change can be easily


accommodated because software is flexible.
• Reality: It is true that software requirements change, but the impact of change
varies with the time at which it is introduced. When requirements changes are
requested early (before design or code has been started), the cost impact is
relatively small. However, as time passes, the cost impact grows rapidly
3. Practitioner’s Myths:
• Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that “the sooner you begin ‘writing code,’ the
longer it’ll take you to get done.” Industry data indicate that between 60 and 80
percent of all effort expended on software will be expended after it is delivered
to the customer for the first time
• Myth: Until I get the program “running” I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can
be applied from the inception of a project—the technical review.
• Myth: The only deliverable work product for a successful project is the
working program.
Reality: A working program is only one part of a software configuration that
includes many elements.
Process Models:
Generic Process Model:
Process Models:
Generic Process Model:

• 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

• The waterfall model is also called as 'Linear sequential model' or 'Classic


life cycle model'.
• In this model, each phase is fully completed before the beginning of the next
phase.
• This model is used for the small projects.
• In this model, feedback is taken after each phase to ensure that the project is
on the right path.
• Testing part starts only after the development is complete.
Phases of Waterfall Model
1.Requirements: The first phase involves gathering requirements from
stakeholders and analyzing them to understand the scope and objectives of the
project.
2.Design: Once the requirements are understood, the design phase begins. This
involves creating a detailed design document that outlines the software
architecture, user interface, and system components.
3.Development: The Development phase include implementation involves
coding the software based on the design specifications. This phase also includes
unit testing to ensure that each component of the software is working as expected.
4. Testing: In the testing phase, the software is tested as a whole to ensure that it
meets the requirements and is free from defects.
5. Deployment: Once the software has been tested and approved, it is deployed
to the production environment.
6. Maintenance: The final phase of the Waterfall Model is maintenance, which
involves fixing any issues that arise after the software has been deployed and
ensuring that it continues to meet the requirements over time.
Advantages
• The waterfall model is simple and easy to understand, implement, and use.
• All the requirements are known at the beginning of the project, hence it is easy
to manage.
• It avoids overlapping of phases because each phase is completed at once.
• This model works for small projects because the requirements are understood
very well.
• This model is preferred for those projects where the quality is more important as
compared to the cost of the project.
Disadvantages

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

• Implementation: In implementation After the last version (version n), it is now


deployed at the client site.
Advantages
 This model is flexible and initial product delivery is faster.
 It is easier to test and debug during the smaller iteration.
 The working software generates quickly and early during the software life
cycle.
 The customers can respond to its functionalities after every increment.
Disadvantages
 The cost of the final product may cross the cost estimated initially.
 This model requires a very clear and complete planning.
 The planning of design is required before the whole system is broken into small
increments.
 The demands of customer for the additional functionalities after every increment
causes problem during the system architecture.
Evolutionary Process Models
Prototype Model
 The prototyping paradigm begins with communication.
 You meet with other stakeholders to define the overall objectives for the software,
identify whatever requirements are known, and outline areas where further
definition is mandatory.
 A prototyping iteration is planned quickly, and modeling (in the form of a “quick
design”) occurs.
 A quick design focuses on a representation of those aspects of the software that
will be visible to end users (e.g., human interface layout or output display formats).
 The quick design leads to the construction of a prototype.
 The prototype is deployed and evaluated by stakeholders, who provide feedback
that is used to further refine requirements .
 Prototype serves as a mechanism for identifying software requirements. If a
working prototype is to be built, you can make use of existing program fragments
or apply tools .
 The prototype can serve as “the first system “
Phases of Prototype Model
• Step 1: Requirement Gathering and Analysis: This is the initial step in
designing a prototype model. In this phase, users are asked about what they
expect or what they want from the system.
• Step 2: Quick Design: This is the second step in the Prototyping Model. This
model covers the basic design of the requirement through which a quick
overview can be easily described.
• Step 3: Build a Prototype: This step helps in building an actual prototype from
the knowledge gained from prototype design.
• Step 4: Initial User Evaluation: This step describes the preliminary testing
where the investigation of the performance model occurs, as the customer will
tell the strengths and weaknesses of the design, which was sent to the developer.
• Step 5: Refining Prototype: If any feedback is given by the user, then
improving the client’s response to feedback and suggestions, the final system is
approved.
• Step 6: Implement Product and Maintain: This is the final step in the phase
of the Prototyping Model where the final system is tested and distributed to
production, here the program is run regularly to prevent failures.
Advantages:
 Issues can be identified in the early phase.
 customer satisfaction exists.
 We can easily detect the missing functionality.
 We can re-use the prototype in the design phase and for similar applications.
 In this model, customer rejection is less as compared to the other models.
Disadvantages:
 It is a time-consuming process because if customer changes in the prototype.
And it will also waste our time by changing again and again in the dummy
(prototype), which will delay the working of the real project.
 We may also lose customer attention if they are not happy with the final product
or original prototype.
 Insufficient or partial problem Analysis
The Spiral Model
Originally proposed by Barry Boehm, the spiral model is an evolutionary
software process model that couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model.
It provides the potential for rapid development of increasingly more complete
versions of the software.
risk-driven process model generator that is used to guide multi-stakeholder
concurrent engineering of software intensive systems.
It has two main distinguishing features. One is a cyclic approach for
incrementally growing a system’s degree of definition and implementation while
decreasing its degree of risk .
Software is developed in a series of evolutionary releases. During early
iterations, the release might be a model or prototype. During later iterations,
increasingly more complete versions of the engineered system are produced.
divided into a set of framework activities defined by the software engineering
team. The spiral model is a realistic approach to the development of large-scale
systems and software
Phases of spiral model
1.Planning: The first phase of the Spiral Model is the planning phase, where the
scope of the project is determined and a plan is created for the next iteration of
the spiral.
2.Risk Analysis: In the risk analysis phase, the risks associated with the project
are identified and evaluated.
3.Engineering: In the engineering phase, the software is developed based on the
requirements gathered in the previous iteration.
4.Evaluation: In the evaluation phase, the software is evaluated to determine if it
meets the customer’s requirements and if it is of high quality.
5.Planning: The next iteration of the spiral begins with a new planning phase,
based on the results of the evaluation.
Applications
• When deliverance is required to be frequent.
• When the project is large
• When requirements are unclear and complex
• When changes may require at any time
• Large and high budget project
Advantages
High amount of risk analysis
Useful for large and mission-critical projects.
Good for large projects.
Improved quality and communication.
Iterative and Incremental Approach.
Disadvantages
• Can be a costly model to use.
• Risk analysis needed highly particular expertise
• Doesn't work well for smaller projects.
• Time consuming.
Concurrent Models
• called concurrent engineering, allows a software team to represent iterative and
concurrent elements of any of the process models.
• All software engineering activities exist concurrently but reside in different
states.
• Concurrent modeling defines a series of events that will trigger transitions from
state to state for each of the software engineering activities, actions, or tasks .
• Concurrent modeling is applicable to all types of software development and
provides an accurate picture of the current state of a project.
Concurrent Model Working
• SDLC activities: communication, design, coding ,testing and deployment.

• Inactive: No any activity/state performed.


• Under Development: Any activity performed.
• Awaiting changes: If customer want any changes.
• Under review: Testing activity start.
• Under revision: Do all required changes.
• Baselined: As per the SRS document.
• Done: Project completed and deployed.
Advantages
• This model is applicable to all types of software development process.
• It is easy for understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current state of a project.
Disadvantages
• It needs better communication between the team members, this may not be
achieved all the time.
• It requires to remember the status of different activities.
Specialized Process Models
• Specialized process models use many of the characteristics of one or more of
the conventional models presented so far, however they tend to be applied
when a narrowly defined software engineering approach is chosen. They
include,

 Components based development

The Formal Methods Model

Aspect oriented software development


Components Based Development :
• In this approach, Commercial Off-The-Shelf (COTS) S/W components, developed by
vendors who offer them as products are used in the development of software. Characteristics
resemble to spiral 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

You might also like