Software Engineering & Project Management (BCS501)-2024

Module-1

Syllabus

Software and Software Engineering: The nature of Software, The unique nature of WebApps, Software
Engineering, The software Process, The software Engineering practice, The software myths.
Textbook 1: Chapter 1: 1.1 to 1.6
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 modelsUnified Process, Personal and Team process models.
Textbook 1: Chapter 2: 2.1 to 2.5

Chapter 1: Software and Software Engineering:

The Nature of Software
Software serves a dual role as both a product and the vehicle for delivering other products,
transforming and managing information across various devices from mobile phones to
mainframe computers. It enables control of computers, communication of information, and
creation of other programs, ultimately delivering the critical product of our time information.
Over the past half-century, advancements in hardware and computing architectures have led to
more sophisticated and complex systems, bringing both impressive results and significant
challenges. The software industry has grown immensely, with teams of specialists replacing
lone programmers, yet persistent questions remain about the efficiency, cost, error detection,
maintenance, and progress measurement in software development. These ongoing concerns
have driven the adoption of software engineering practices.

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 adequately
manipulate information, and (3) descriptive information in both hard copy and virtual forms
that describes the operation and use of the programs.
Software is engineered, not manufactured, and consists of instructions, data structures, and
descriptive information. Unlike hardware, software is a logical system element and does not
wear out, though it can deteriorate over time due to changes that introduce errors. The failure
rate for software, initially high due to undiscovered defects, flattens once these are corrected,
but spikes again with each change, causing deterioration. Unlike hardware, software does not
have spare parts; every failure indicates a design or implementation error, making maintenance
complex. Despite a trend toward component-based construction, most software is still custom-
built. Standard design components, common in hardware engineering, are only

1|Page
 Software Engineering & Project Management (BCS501)-2024

beginning to be broadly used in software. Reusable software components, which encapsulate

data and processing, are increasingly enabling the creation of new applications from existing
parts, such as modern interactive user interfaces built with reusable components.
Software Application Domains
Today, software engineers face challenges across seven broad categories of computer
software:
System software services other programs and interacts heavily with hardware, involving
complex data structures and multiple external interfaces.
Application software consists of standalone programs addressing specific business needs,
including real-time business function control.
Engineering/scientific software includes applications ranging from numerical algorithms to
interactive real-time system simulations.
Embedded software resides within products, controlling functions from simple keypads to
complex automotive systems.
Product-line software serves multiple customers, from niche markets to mass consumer
applications like word processing and spreadsheets.
Web applications (WebApps) have evolved from simple hypertext files to sophisticated
environments integrated with corporate databases.
Artificial intelligence software uses nonnumerical algorithms for complex problem-solving,
such as robotics and pattern recognition.
Emerging challenges for software engineers include:
Open-world computing: Developing systems and applications for pervasive, distributed
computing across vast networks, enabling communication among mobile devices, personal
computers, and enterprise systems.
Netsourcing: Architecting both simple and sophisticated applications that leverage the World
Wide Web as a computing engine and content provider for global end-user markets.
Open source: Creating self-descriptive source code for systems applications, and developing
techniques for tracking and understanding changes made by multiple contributors.
Legacy Software
Legacy software, often developed decades ago and continuously modified, poses challenges
for organizations due to its longevity and criticality to business functions. While indispensable,
these systems often suffer from poor quality, with inextensible designs, convoluted code, and
inadequate documentation. Despite these drawbacks, if the legacy software meets user needs
and operates reliably, there may be no immediate need for action.

2|Page
 Software Engineering & Project Management (BCS501)-2024

However, as technology and business requirements evolve, legacy systems may require
adaptation, enhancement, extension, or re-architecture to remain viable. Modern software
engineering aims to devise methodologies that facilitate the evolution of software systems,
ensuring interoperability and cooperation between old and new systems.
The Unique Nature of Webapps
In the early years of the World Wide Web, websites were basic collections of linked hypertext
files with limited graphics. With advancements like XML and Java, Web engineers transformed
these into sophisticated WebApps, blending computing capability with informational content
and integrating with databases and business applications. WebApps are unique, bridging
elements of print publishing, software development, marketing, internal communications,
external relations, and the convergence of art and technology.
The following attributes are encountered in the vast majority of WebApps:
 WebApps operate on networks, catering to diverse users, whether globally through
the Internet or within a limited scope like a corporate Intranet.
 They handle large numbers of users simultaneously, with usage patterns varying
widely among users.
 WebApps face unpredictable user loads, fluctuating from hundreds to thousands
within days, posing challenges for resource allocation and performance management.
 Performance is crucial for user satisfaction; delays in access or processing may drive
users away to alternatives.
 Users expect round-the-clock availability from popular WebApps, even during
maintenance windows when traditional software might be offline.
 Many WebApps utilize hypermedia to present content and access external databases,
especially in e-commerce or financial applications.
 Quality content is essential for WebApp success, influencing user satisfaction and
engagement.
 WebApps evolve continuously, updating content on a minute-by-minute basis and
adapting rapidly to changing demands.
 Immediacy characterizes WebApp development, with rapid time-to-market often
achieved within days or weeks.
 Security is paramount for WebApps due to network accessibility, necessitating robust
measures to protect sensitive data and ensure secure transmission.

3|Page
 Software Engineering & Project Management (BCS501)-2024

 Aesthetics play a significant role in the appeal of WebApps, particularly in applications

aimed at marketing or selling products, influencing user perception and engagement.
Software Engineering
Software engineering requires recognizing the importance of understanding the problem before
developing a solution, emphasizing the pivotal role of design in creating reliable and efficient
software. With software now deeply embedded in various aspects of life, diverse voices
influence the features and functions of new applications, necessitating a thorough
understanding of the problem domain. As technology requirements grow more complex, design
becomes crucial in managing the interactions of system elements, while the reliance on
software for critical functions demands high quality and maintainability. As applications
increase in value, so do demands for adaptation and enhancement, highlighting the need for
maintainable software. Thus, software in all its forms should be engineered, guided by sound
engineering principles to obtain economically reliable and efficient software.
The IEEE defines software engineering as the application of a systematic, disciplined approach
to software development and maintenance. However, adaptability and agility are also important
together with discipline.
Software engineering is a layered technology, built on a foundation of organizational
commitment to quality, fostering a culture of continuous improvement.
The process layer of software engineering provides the framework for rational and timely
development, management, and quality assurance of software projects.
Software engineering methods offer technical guidance for various tasks including
communication, requirements analysis, design, coding, testing, and support.

These methods rely on a set of basic principles governing each area of technology, including
modelling activities and descriptive techniques.
Software engineering tools automate or semi-automate support for processes and methods,
enabling efficient development and management of software projects.

4|Page
 Software Engineering & Project Management (BCS501)-2024

Integration of tools creates a system known as computer-aided software engineering (CASE),

streamlining the software development process.
The software Process
A process in software engineering consists of activities, actions, and tasks aimed at creating
work products. Activities serve broad objectives like communication, while actions encompass
tasks producing major work products. Tasks focus on specific, well-defined objectives, such as
conducting unit tests. The process is adaptable, allowing software teams to choose appropriate
actions and tasks to deliver software timely and with sufficient quality.
The five generic process framework activities for software engineering:
Communication: Collaborate with stakeholders to gather project requirements.
Planning: Create a project plan outlining tasks, risks, resources, and schedules.
Modeling: Develop models to understand software requirements and design solutions.
Construction: Generate code and conduct testing to uncover errors.
Deployment: Deliver the software to customers for evaluation and feedback.
In software projects, framework activities like communication, planning, modeling,
construction, and deployment are often applied iteratively, with multiple project iterations.
Each iteration produces a software increment containing a subset of features, gradually
enhancing the completeness of the software with each cycle.
Software engineering process framework activities are complemented by a number of umbrella
activities. In general, umbrella activities are applied throughout a software project and help a
software team manage and control progress, quality, change, and risk. Typical umbrella
activities include:
Software project tracking and control allows the software team to assess progress against the
project plan and take any necessary action to maintain the schedule.
Risk management assesses risks that may affect the outcome of the project or the quality of the
product.
Software quality assurance defines and conducts the activities required to ensure software
quality.
Technical reviews assess software engineering work products in an effort to uncover and
remove errors before they are propagated to the next activity.
Measurement defines and collects process, project, and product measures that assist the team
in delivering software that meets stakeholders’ needs; can be used in conjunction with all other
framework and umbrella activities.

5|Page
 Software Engineering & Project Management (BCS501)-2024

Software configuration management manages the effects of change throughout the software
process.
Reusability management defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
Work product preparation and production encompasses the activities required to create work
products such as models, documents, logs, forms, and lists.
Processes adopted for different projects can vary significantly in several aspects, including the
overall flow of activities, the degree of definition within framework activities, the level of detail
in work product identification, and the application of quality assurance and project tracking
activities. Additionally, differences may exist in the involvement of stakeholders, autonomy
given to the software team, and prescribed team organization and roles.
The software Engineering practice
The essence of software engineering practice:
 Understand the problem (communication and analysis).
 Plan a solution (modeling and software design)
 Carry out the plan (code generation).
 Examine the result for accuracy (testing and quality assurance)
Understanding the problem involves identifying stakeholders, clarifying unknowns, breaking
down the problem into smaller parts, and considering graphical representations. Planning the
solution entails recognizing patterns from similar problems, reusing existing solutions, defining
subproblems, and creating design models. Carrying out the plan involves following the design
as a roadmap, ensuring conformity to the plan, and verifying the correctness of each
component. Examining the result includes testing each component, validating against
requirements, and uncovering errors through thorough testing.
General Principles
Principles, defined as important underlying laws or assumptions in a system of thought, are
discussed throughout this book at various levels of abstraction. Whether focusing on software
engineering as a whole, specific framework activities, or technical tasks, principles help
establish a mindset for robust software engineering practice.
David Hooker [Hoo96] has proposed seven principles that focus on software engineering
practice as a whole. They are reproduced in the following paragraphs:

6|Page
 Software Engineering & Project Management (BCS501)-2024

i) The Reason It All Exists: Software systems should exist to provide value to users. All
decisions in software engineering should prioritize adding real value to the system, ensuring
that every aspect contributes to its overall purpose.
ii) KISS (Keep It Simple, Stupid!): Software design should aim for simplicity without
sacrificing essential features. Elegant designs are often simpler and more maintainable,
requiring thoughtful iteration rather than rushed development.
iii) Maintain the Vision: A clear vision is crucial for project success, preventing a system from
becoming disjointed or inconsistent. Upholding architectural vision throughout the project,
enforced by an empowered architect, ensures conceptual integrity and a successful outcome.
iv) What You Produce, Others Will Consume: Software development should anticipate that
others will need to understand and use the system. Design and implement with consideration
for usability, maintenance, and extension, ensuring that the product adds value for all
stakeholders.
v) Be Open to the Future: Software systems should be designed to adapt to changing
requirements and environments. By planning for future changes and avoiding design
constraints, systems can maintain value over the long term, even amid evolving technology
landscapes.
vi) Plan Ahead for Reuse: Reuse of code and designs saves time and effort in software
development. However, achieving effective reuse requires careful planning and foresight,
leveraging techniques to identify and incorporate reusable components throughout the
development process.
vii) Think!: Clear and complete thought before action leads to better results in software
engineering. Intense thought and consideration, guided by the first six principles, enhance the
quality and value of software systems, reducing difficulties in building complex computer-
based systems.
The software myths
Software myths, originating from the early days of computing, persist due to their seemingly
reasonable nature and intuitive appeal. Despite being recognized as misleading by most
software engineering professionals today, these myths can still influence attitudes and practices
within the industry. Overcoming these entrenched beliefs requires ongoing efforts to challenge
and replace them with evidence-based practices and principles.
Management myths often stem from the pressure to maintain budgets, meet schedules, and
improve quality. For example, the belief that a book of standards contains all necessary
guidance for software development overlooks issues of awareness, relevance, and

7|Page
 Software Engineering & Project Management (BCS501)-2024

adaptability. Similarly, the idea that adding more programmers can accelerate a late project
ignores the complexities of software development and the potential for diminishing returns.
Lastly, outsourcing a software project doesn't alleviate the need for effective management and
oversight internally; without proper understanding and control, outsourcing can lead to
challenges and setbacks.
Customer myths often arise due to misinformation and can lead to false expectations and
dissatisfaction. For instance, the belief that a general statement of objectives suffices for
software development overlooks the need for clear and unambiguous requirements, which are
essential for successful projects. Similarly, while it's true that software requirements can
change, accommodating changes becomes increasingly difficult and costly as the project
progresses, highlighting the importance of early clarification and stability in requirements.
Software practitioners may hold onto myths ingrained in programming culture, despite
advancements in software engineering practices. For instance, the belief that the job is done
once the program works overlooks the substantial effort required for maintenance and updates
post-delivery, which can constitute the majority of project effort. Additionally, the
misconception that program quality can only be assessed once it's running ignores the
effectiveness of technical reviews as early quality assurance measures. Moreover, the notion
that software engineering leads to excessive documentation and slowdowns overlooks its focus
on creating quality products, which ultimately reduces rework and accelerates delivery times.
How It All Starts
At the onset of a software project, a business need arises, whether it's to fix a defect, adapt to
changing business conditions, enhance existing features, or create something new. Initially,
this need is often communicated informally, as seen in the typical conversation presented in
the sidebar.
SafeHome: How a Project Starts
At CPI Corporation's meeting, the team discusses developing a new product: a small, versatile
wireless device. They envision it as a key component for innovative home management
products called SafeHome. Mal and Lisa propose SafeHome as a solution to boost sales,
leveraging the widespread use of PCs and the unique features of their wireless box. With
engineering confirming technical feasibility, Joe sees the potential for significant revenue,
showing interest in advancing the project to the next stage.

8|Page
 Software Engineering & Project Management (BCS501)-2024

Chapter 2: Process Models

Since a technical perspective, a software process is a structured framework outlining the
activities, actions, and tasks necessary for developing high-quality software. While a software
process defines the approach to software engineering, it's not entirely synonymous with
software engineering itself. Software engineering also involves utilizing technical methods and
tools within the process, all of which are guided and adapted by skilled individuals to meet the
needs of their projects and market demands.
A generic process model
The software process encompasses an important aspect known as process flow, which defines
the organization of framework activities, actions, and tasks over time. Process flow can take
various forms: linear, iterative, evolutionary, or parallel, each saying how the framework
activities are sequenced or executed. These different flow types influence the order and
repetition of activities, allowing for flexibility in software development approaches.

Defining a Framework Activity: For small software projects with simple requirements, the
communication activity might involve basic tasks like making a phone call, discussing
requirements, and organizing notes into a brief document. However, for complex projects with
multiple stakeholders and conflicting requirements, the communication activity could entail
more elaborate actions such as inception, elicitation, elaboration, negotiation, specification,
and validation, each with numerous associated tasks and work products. The task set chosen
by the software team varies based on the specific characteristics of the problem and project at
hand.

9|Page
 Software Engineering & Project Management (BCS501)-2024

Identifying a Task Set: Each software engineering action, like elicitation, can be represented
by various task sets, each comprising work tasks, related work products, quality assurance
points, and project milestones. The choice of a task set should align with the project's needs
and the team's characteristics, allowing for adaptation to the specific project requirements and
team dynamics.
Task Set: It defines the actual work to be done to accomplish the objectives of a software
engineering action. For example, elicitation (more commonly called “requirements gathering”)
is an important software engineering action that occurs during the communication activity. The
goal of requirements gathering is to understand what various stakeholders want from the
software that is to be built.
For a small, relatively simple project, the task set for requirements gathering might look like
this:
i. Make a list of stakeholders for the project.
ii. Invite all stakeholders to an informal meeting.
iii. Ask each stakeholder to make a list of features and functions required.
iv. Discuss requirements and build a final list.
v. Prioritize requirements.
vi. Note areas of uncertainty
For a larger, more complex software project, a different task set would be required. It might
encompass the following work tasks:
i. Make a list of stakeholders for the project.
ii. Interview each stakeholder separately to determine overall wants and needs.
iii. Build a preliminary list of functions and features based on stakeholder input.
iv. Schedule a series of facilitated application specification meetings.
v. Conduct meetings.
vi. Produce informal user scenarios as part of each meeting.
vii. Refine user scenarios based on stakeholder feedback.
viii. Build a revised list of stakeholder requirements.
ix. Use quality function deployment techniques to prioritize requirements.
x. Package requirements so that they can be delivered incrementally.
xi. Note constraints and restrictions that will be placed on the system.
xii. Discuss methods for validating the system.

10 | P a g e
 Software Engineering & Project Management (BCS501)-2024

Both of these task sets achieve “requirements gathering,” but they are quite different in their
depth and formality. The software team chooses the task set that will allow it to achieve the
goal of each action and still maintain quality and agility.
Process Pattern: It is a template that describes a problem encountered in software engineering,
identifies the environment in which it occurs, and suggests proven solutions. These patterns
can address problems at various levels of abstraction, from complete process models to specific
actions within framework activities. They provide a consistent method for describing problem
solutions within the context of the software process, allowing teams to address and resolve
issues efficiently.
Ambler [Amb98] introduced a template for describing process patterns, which includes:
Pattern Name: A descriptive name for the pattern within the software process context (e.g.,
TechnicalReviews).
Forces: Describes the environment where the problem arises and the issues influencing its
solution.
Type: Specifies the pattern type, categorized into Stage patterns (associated with a framework
activity), Task patterns (associated with a specific software engineering action), and Phase
patterns (defining the sequence of framework activities).
An Example Process Pattern
The RequirementsUnclear process pattern addresses situations where stakeholders lack clear
software requirements but recognize the need for a solution. The intent is to develop a prototype
iteratively to help stakeholders refine their requirements.
Initial conditions include stakeholder identification, established communication channels, and
a basic understanding of the project scope.
The problem is hazy requirements, while the solution involves prototyping. The resulting
context is an approved prototype that outlines basic requirements.
Related patterns include CustomerCommunication, IterativeDesign, IterativeDevelopment,
CustomerAssessment, and RequirementExtraction. Prototyping is recommended when
requirements are uncertain.
Process Assessment and Improvement
A number of different approaches to software process assessment and improvement have been
proposed over the past few decades:
Standard CMMI Assessment Method for Process Improvement (SCAMPI)—provides a five-
step process assessment model that incorporates five phases: initiating, diagnosing,

11 | P a g e
 Software Engineering & Project Management (BCS501)-2024

establishing, acting, and learning. The SCAMPI method uses the SEI CMMI as the basis for
assessment [SEI00].
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 [Dun01].
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 [ISO08].
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. Therefore,
the standard is directly applicable to software organizations and companies [Ant06]
Prescriptive Process Models
Prescriptive process models were introduced to bring structure to software development,
offering a roadmap for software teams. However, software engineering remains on the edge of
chaos, where a delicate balance between order and surprise exists. The edge of chaos represents
a state of instability, constantly fluctuating between structured and chaotic states.
Research suggests that operating away from equilibrium fosters creativity and self-
organization. Absolute order may stifle variability, while too much chaos can hinder
coordination. The philosophical implications for software engineering are profound,
questioning the appropriateness of rigidly structured process models in a field characterized by
change.
While prescriptive process models prioritize order and consistency, they may struggle to
accommodate the dynamic nature of software development. Rejecting traditional models in
favour of less structured approaches raises concerns about coordination and coherence.
Software engineers have alternatives to explore, each with its own approach to process
elements and flow.
Prescriptive process models prescribe a set of elements, including framework activities, tasks,
and quality assurance mechanisms. They also define process flows to organize these elements,
albeit with varying emphasis on different activities. Despite their differences, all process
models aim to guide software development while acknowledging the inherent complexities and
uncertainties of the field.
Waterfall Model
The waterfall model, also known as the classic life cycle, is a systematic and sequential
approach to software development. It starts with gathering customer requirements and

12 | P a g e
 Software Engineering & Project Management (BCS501)-2024

progresses through planning, modeling, construction, and deployment, ultimately leading to

ongoing support of the software. The V-model is a variation of the waterfall model, illustrating
the relationship between quality assurance actions and other development activities.

The waterfall model

The V-mode
Each phase is as follows:
Requirements Gathering: The process begins with gathering and documenting all the
requirements for the software product. This involves understanding the needs of the
stakeholders and defining what the software should accomplish.
System Design: Once the requirements are gathered, the system's architecture and design are
planned and documented. This phase involves defining how the system will be structured and
function to meet the specified requirements.
Implementation: In this phase, the actual coding or programming of the software takes place
based on the design specifications. Developers write code according to the system design and
programming standards.

13 | P a g e
 Software Engineering & Project Management (BCS501)-2024

Testing: After the code is implemented, rigorous testing is performed to identify and fix any
defects or bugs. This phase ensures that the software meets the specified requirements and
functions correctly.
Deployment: Once the software has been thoroughly tested and validated, it is deployed or
released to the end-users. This phase involves installing the software on the users' systems and
making it available for use.
Maintenance: After deployment, the software enters the maintenance phase, where updates,
enhancements, and bug fixes are made as necessary to ensure its continued functionality and
relevance.
The waterfall model emphasizes the completion of each phase before moving on to the next,
with little to no overlap between phases. This sequential approach assumes that requirements
are well-understood and can be fully defined upfront, which may not always be the case in
complex or dynamic projects. Despite its limitations, the waterfall model provides a structured
and systematic framework for software development, making it suitable for projects with clear
and stable requirements.
Among the problems that are sometimes encountered when the waterfall model is applied are:
i. Real projects rarely follow the sequential flow that the model proposes. Although the
linear model can accommodate iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds.
ii. It is often difficult for the customer to state all requirements explicitly. The waterfall
model requires this and has difficulty accommodating the natural uncertainty that exists
at the beginning of many projects.
iii. The customer must have patience. A working version of the program(s) will not be
available until late in the project time span. A major blunder, if undetected until the
working program is reviewed, can be disastrous
Advantages:
 Simplicity and Clarity: Easy to understand and manage with well-defined stages.
 Thorough Documentation: Detailed documentation aids future maintenance.
 Predictable: Clear milestones and timelines enhance predictability.
 Discipline: Rigorous approach reduces risks of overlapping activities.
 Suitable for Stable Projects: Effective for projects with well-understood, stable
requirements.

14 | P a g e
 Software Engineering & Project Management (BCS501)-2024

Disadvantages:
 Inflexible to Changes: Hard to accommodate changes once a phase is completed.
 High Risk: Issues found late in testing can be costly to fix.
 Limited Customer Feedback: Minimal customer involvement until the end product is
delivered.
 Time-Consuming: Sequential approach can delay the delivery of the final product.
 Not Ideal for Dynamic Projects: Struggles with evolving requirements.
Incremental Process Models
The incremental process model is employed when initial software requirements are well-
defined, but the project's scope necessitates a phased approach. Rather than following a purely
linear process, the incremental model delivers software functionality in successive increments
over time. Each increment builds upon the previous one, allowing for quick delivery of
essential features followed by refinement and expansion in subsequent releases.
In the incremental model, linear sequences are applied sequentially over time, with each
sequence producing deliverable increments of the software. For instance, a word-processing
software developed incrementally might first deliver basic file management and editing
functions, followed by more advanced features like spell-checking and page layout capabilities
in subsequent increments. The process for each increment can incorporate prototyping to refine
functionality.
Initially, the first increment often delivers a core product addressing basic requirements, with
additional features planned for future increments based on user feedback and evaluation. This
iterative process continues until the complete product is developed, with each increment
enhancing functionality and addressing user needs.

The incremental model

15 | P a g e
 Software Engineering & Project Management (BCS501)-2024

The incremental approach focuses on delivering operational products with each increment,
allowing users to benefit from early versions while providing a platform for evaluation and
feedback. This model is particularly beneficial when staffing constraints or technical risks need
to be managed, as early increments can be implemented with fewer resources and planned to
mitigate uncertainties such as hardware availability.
Advantages:
 Early Product Delivery: Functional product increments are delivered early, providing
value sooner.
 Flexibility: Easier to incorporate changes based on feedback after each increment.
 Risk Management: Risks are identified and mitigated early through incremental
development.
 Customer Feedback: Continuous customer involvement and feedback improve final
product quality.
 Improved Testing: Each increment is tested thoroughly, leading to more reliable
software.
Disadvantages:
 Complex Integration: Combining increments can become complex and challenging.
 Incomplete Early Versions: Initial increments may lack full functionality, potentially
causing dissatisfaction.
 Resource Intensive: Requires continuous involvement of team members, which can be
demanding.
 Management Overhead: Managing multiple increments and frequent releases can
increase administrative efforts.
 Scope Creep: Frequent changes and additions can lead to scope creep, affecting
timelines and budgets
Evolutionary Process Models
Evolutionary process models are designed to accommodate the evolving nature of software
development, particularly when requirements are subject to change or when only a limited
version of the product is needed initially. These models are iterative, allowing for the
development of increasingly complete versions of the software over time.
One common evolutionary model is prototyping, which is employed when detailed
requirements are unclear or when there is uncertainty about certain aspects of the software.
Prototyping involves quickly planning and constructing a basic version of the software,

16 | P a g e
 Software Engineering & Project Management (BCS501)-2024

known as a prototype, which is then evaluated by stakeholders to refine requirements. The

prototype serves as a mechanism for understanding user needs and refining the software's
design.
While prototyping allows for rapid feedback and understanding of requirements, it can also
present challenges. Stakeholders may mistake the prototype for a fully functional product,
leading to unrealistic expectations, and developers may make implementation compromises to
build the prototype quickly, which can lead to long-term issues with software quality and
maintainability.

Despite these challenges, prototyping can be effective if stakeholders agree on its purpose— to
define requirements—and if it is followed by a structured engineering process to build the
actual software with a focus on quality and maintainability.
Advantages:
 Adaptability: Easily accommodates changing requirements throughout the
development process.
 Early Prototyping: Provides early prototypes, helping to gather user feedback and
improve product requirements.
 Continuous Improvement: Iterative cycles allow for continuous refinement and
enhancement of the product.
 Risk Reduction: Early and frequent iterations help identify and mitigate risks early in
the project.
 Customer Involvement: Ongoing customer involvement ensures the final product
aligns closely with user needs.
Disadvantages:
 Management Complexity: Managing iterative cycles and frequent updates can be
complex and time-consuming.

17 | P a g e
 Software Engineering & Project Management (BCS501)-2024

 Scope Creep: Continuous changes and new requirements can lead to scope creep,
affecting project timelines and budgets.
 Resource Intensive: Requires sustained effort and involvement from both the
development team and stakeholders.
 Documentation Challenges: Maintaining up-to-date documentation can be difficult
with frequent changes.
 Potential for Delays: Iterative refinement can extend timelines if not properly
managed.

The Spiral Model, proposed by Barry Boehm, blends the iterative nature of prototyping with
the structured aspects of the waterfall model, enabling the rapid development of increasingly
complete versions of software. It operates as a risk-driven process generator, incrementally
growing system definition and implementation while decreasing risk through a series of
evolutionary releases. Each iteration involves a set of framework activities, with risk
considered at each revolution around the spiral path. Anchor point milestones mark each pass,
ensuring stakeholder commitment to feasible solutions.

18 | P a g e
 Software Engineering & Project Management (BCS501)-2024

A typical spiral model

In the Spiral Model, software development progresses through a series of evolutionary passes,
with early iterations potentially resulting in product specifications and subsequent iterations
producing prototypes and more sophisticated software versions. The process is adaptable and
can continue throughout the life of the software, transitioning from concept development to
product enhancement projects. While realistic for large-scale systems, the model requires
expertise in risk assessment and may face challenges in convincing customers of its
controllability in contract situations. However, when properly applied, it facilitates risk
reduction and provides a systematic approach to software development that reflects real- world
complexities.

Concurrent Models
The concurrent development model, also known as concurrent engineering, allows software
teams to incorporate iterative and concurrent elements from various process models. It

19 | P a g e
 Software Engineering & Project Management (BCS501)-2024

enables activities such as modeling, prototyping, analysis, and design to occur concurrently. In
this approach, software engineering activities exist simultaneously but may be in different
states, transitioning based on events triggered during the development process.
For instance, during the modeling activity, which can include activities like prototyping and
design, different states represent the progress of each task. Events such as uncovering
inconsistencies trigger transitions between states, ensuring that activities progress efficiently.
Concurrent modeling provides a dynamic view of the project's current state, allowing for
flexibility and adaptation to changing requirements.
Overall, concurrent modeling offers a process network where activities, actions, and tasks exist
concurrently, with transitions triggered by specific events. This approach is applicable to
various software development scenarios and provides a more accurate representation of project
progress compared to linear sequences of events.

One element of the concurrent process model

Advantages:
 Parallel Development: Enables simultaneous progress on different components,
speeding up overall development.
 Flexibility: Easily adapts to changes in requirements or design during the
development process.
 Continuous Feedback: Provides ongoing feedback between development phases,
improving the final product.

20 | P a g e
 Software Engineering & Project Management (BCS501)-2024

 Risk Management: Early detection and resolution of issues through overlapping

activities reduce project risks.
 Efficient Resource Utilization: Teams can work independently on different tasks,
optimizing resource use.
Disadvantages:
 Complex Coordination: Managing and coordinating parallel activities can be
challenging and require robust communication.
 Integration Challenges: Combining independently developed components may lead to
integration issues.
 High Dependency: Dependencies between concurrent tasks can create bottlenecks if
not managed properly.
 Resource Intensive: Requires significant resources and skilled team members to
handle parallel development effectively.
 Potential for Conflicts: Concurrent tasks might lead to conflicts and inconsistencies if
not properly synchronized.
A Final Word on Evolutionary Processes: Evolutionary process models were designed to
tackle the challenges of continual change, tight timelines, and the need for customer satisfaction
in modern software development. However, they also have their weaknesses, as summarized
by Nogueira and colleagues. Firstly, project planning can be problematic due to the uncertain
number of cycles required for prototyping and other evolutionary processes, which may not
align well with linear project management techniques. Secondly, there's the risk of the process
falling into chaos if evolutions occur too rapidly without periods of relaxation, or if they
proceed too slowly, affecting productivity. Thirdly, there's a shift towards prioritizing
flexibility and speed over high quality, driven by competition and the need to meet market
demands.
This paradigm shift challenges traditional notions of software quality, as it emphasizes
flexibility, extensibility, and speed of development. While evolutionary models aim to deliver
high-quality software iteratively, they can also be adapted to prioritize other factors. The key
challenge for software teams and managers is to strike a balance between these parameters
while ensuring customer satisfaction, which ultimately determines the success of the software
product.

21 | P a g e
 Software Engineering & Project Management (BCS501)-2024

Specialized Process Models

Specialized process models often exhibit traits similar to those found in traditional models
discussed earlier. However, they are typically employed in situations where a specific or
narrowly focused software engineering approach is preferred.
Advantages:
 Tailored Solutions: Designed to meet specific project requirements or industry
standards, improving relevance and effectiveness.
 Optimized Performance: Focus on particular aspects of development (e.g., safety-
critical systems) can enhance performance and reliability.
 Regulatory Compliance: Often aligned with industry regulations, aiding in
compliance and reducing legal risks.
 Enhanced Quality: Specialized processes often include rigorous testing and validation,
leading to higher quality outcomes.
 Focused Expertise: Leveraging specialized knowledge and techniques can result in
innovative solutions and competitive advantages.
Disadvantages:
 Complexity: May introduce additional complexity, requiring specialized skills and
training.
 Higher Costs: Tailoring processes to specific needs can increase development costs
and resource requirements.
 Limited Flexibility: Specialized processes can be less adaptable to changes outside the
predefined scope.
 Integration Issues: Integrating with more general systems or processes might present
challenges.
 Narrow Scope: Focusing too much on specialized areas might overlook broader
project needs or opportunities for improvement.
The Component-Based Development model controls commercial off-the-shelf (COTS)
software components, integrating them into the software being built. It adopts an evolutionary
approach similar to the spiral model, emphasizing iterative development.
Regardless of the technology that is used to create the components, the component-based
development model incorporates the following steps (implemented using an evolutionary
approach):

22 | P a g e
 Software Engineering & Project Management (BCS501)-2024

i. Available component-based products are researched and evaluated for the application
domain in question.
ii. Component integration issues are considered.
iii. A software architecture is designed to accommodate the components.
iv. Components are integrated into the architecture.
v. Comprehensive testing is conducted to ensure proper functionality.
The process involves researching and evaluating available components, considering integration
issues, designing software architecture to accommodate the components, integrating them, and
conducting comprehensive testing. The primary advantage of this model lies in software reuse.
By incorporating existing components, development teams can significantly reduce the time
and cost associated with building software from scratch. Moreover, the reuse of components
promotes consistency, reliability, and scalability across different projects. Overall, the
Component-Based Development model facilitates efficient and cost-effective software
development through the strategic integration of reusable software components.
The Formal Methods Model
The Formal Methods Model involves a series of activities aimed at creating formal
mathematical specifications for computer software. By employing rigorous mathematical
notations, formal methods allow for the specification, development, and verification of
computer-based systems, offering a systematic approach to identify and correct issues such as
ambiguity, incompleteness, and inconsistency.
One variation of this approach, known as cleanroom software engineering, is practiced by
certain software development organizations. Formal methods are particularly beneficial during
the design phase, providing a foundation for program verification that helps uncover and rectify
errors that might otherwise remain undetected.
Despite its potential for producing defect-free software, the formal methods model is not
widely adopted due to several concerns. Firstly, developing formal models can be time-
consuming and expensive. Additionally, because of the specialized knowledge required,
extensive training is often necessary for software developers. Furthermore, communicating
the intricacies of formal models to technically unsophisticated customers can be challenging.
Nevertheless, the formal methods approach has found favor among developers of safety-
critical software, such as aircraft avionics and medical devices, as well as among those who
face significant economic consequences in the event of software errors. Despite its

23 | P a g e
 Software Engineering & Project Management (BCS501)-2024

challenges, the formal methods model remains a valuable option for ensuring software
reliability and safety in critical application
Aspect-Oriented Software Development
Aspect-oriented software development (AOSD), also known as aspect-oriented programming
(AOP), is a modern paradigm in software engineering that addresses the challenge of
crosscutting concerns. Crosscutting concerns are those that span the entire architecture of a
software system and affect multiple functions, features, and information.
Aspect-oriented development provides a process and methodological approach for defining,
specifying, designing, and constructing aspects, which are mechanisms beyond subroutines
and inheritance for localizing the expression of crosscutting concerns. These concerns may
include high-level properties such as security and fault tolerance, functional concerns like
business rules, or systemic concerns such as task synchronization and memory management.
In aspect-oriented component engineering (AOCE), aspects are characterized as horizontal
slices through vertically decomposed software components. These aspects represent cross-
cutting functional and non-functional properties of components, such as user interfaces,
distribution, persistency, security, and transaction processing.
Each aspect may have various aspect details, specifying properties related to its functional and
non-functional characteristics. For example, user interface aspects may include details like
viewing mechanisms and extensible affordances, while distribution aspects may involve event
generation and transport mechanisms.
While a distinct aspect-oriented process has yet to fully mature, it's likely to adopt
characteristics from both evolutionary and concurrent process models. The evolutionary model
is suitable for identifying and constructing aspects over time, while the parallel nature of
concurrent development is essential because aspects are engineered independently but have a
direct impact on localized software components.
Aspects and components require asynchronous communication between software process
activities to ensure effective integration and coordination. By integrating aspect-oriented
principles into software development, teams can better manage crosscutting concerns and
improve the modularity, maintainability, and scalability of complex software systems.
Process Management
Objective: To assist in the definition, execution, and management of prescriptive process
models.
Mechanics: Process management tools allow a software organization or team to define a
complete software process model (framework activities, actions, tasks, QA checkpoints,

24 | P a g e
 Software Engineering & Project Management (BCS501)-2024

milestones, and work products). In addition, the tools provide a road map as software engineers
do technical work and a template for managers who must track and control the software
process.
Representative Tools: GDPA, a research process definition tool suite, developed at Bremen
University in Germany (www.informatik.uni-bremen.de/uniform/gdpa/home.htm), provides a
wide array of process modeling and management functions.
SpeeDev, developed by SpeeDev Corporation (www.speedev.com) encompasses a suite of
tools for process definition, requirements management, issue resolution, project planning, and
tracking.
ProVision BPMx, developed by Proforma (www.proformacorp.com), is representative of
many tools that assist in process definition and workflow automation.
A worthwhile listing of many different tools associated with the software process can be found
at www .processwave.net/Links/tool_links.htm
Question Bank
1. Explain the distinctive characteristics of software and how they influence the
development process illustrate with an example.
2. Describe the unique features and challenges of web applications compared to
traditional software. How do these challenges impact software engineering practices?
3. Define software engineering and its significance in ensuring the quality and reliability
of software products. Discuss the key principles of software engineering.
4. Outline the stages of the software development process. Explain the importance of
each stage and how they contribute to project success.
5. Compare different software development methodologies (e.g., Agile, Waterfall) and
tools used in software engineering. Discuss their advantages and disadvantages.
6. Identify and explain a common myth about software development. Explain why this
myth persists and its implications for project management.
7. Discuss the initial steps involved in starting a software development project. Why is
project initiation important, and what factors should be considered?
8. Explain various software development process models, such as Waterfall, Agile, and
Spiral. Describe their characteristics and when they are most suitable.
9. Discuss the importance of assessing and improving software development processes.
How can organizations benefit from process assessment and improvement?
10. Describe the Waterfall model of software development. Discuss its advantages and
disadvantages, and when it should be used.

25 | P a g e
 Software Engineering & Project Management (BCS501)-2024

11. Explain the concept of incremental development in software engineering. How does it
differ from other development approaches, and what are its benefits?
12. Define evolutionary process models in software engineering. Provide examples of
such models and their applications.
13. What are concurrent models in software development? How do they facilitate
collaboration among team members?
14. Describe specialized process models used in software development. Provide examples
of when and why these models are used.
15. Explain the concept of component-based development in software engineering.
Discuss its advantages and challenges.

Text Book
1. Roger S. Pressman: Software Engineering-A Practitioners approach, 7th
Edition, Tata McGraw Hill.

26 | P a g e