Software Engineering & Project Management

(21CS61)

Module – 1

 Nature of Software
 Domain of Software Application
 Unique features of webapps
 Software Engineer layers
 Software Process Framework
 Software Engineer Practice
 Process Flow
 Process Models
 Waterfall model
 V model
 Spiral Model

Module – 2

 Requirement Engineer(Establishing Groundwork)

 Elicating requirements
1)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.

2)Domain of Software Application:

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

3)Unique features of Web Apps:

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.
 Aesthetics play a significant role in the appeal of WebApps, particularly in applications
aimed at marketing or selling products, influencing user perception and engagement.
4)Software Engineer layers:

Software engineering is a layered technology, and each layer plays a crucial role in the
development and management of software projects. Here’s an explanation of each layer with a
focus on quality, process, methods, and tools:

Quality Focus

 Foundation: The foundation of software engineering is an organizational commitment to

quality. This means fostering a culture of continuous improvement and prioritizing high
standards in every aspect of software development.
 Objective: Ensuring that the end product meets or exceeds customer expectations,
adheres to regulatory requirements, and is free from defects.
 Impact: Quality focus influences every layer of software engineering, ensuring that
processes are well-defined, methods are rigorously applied, and tools are effectively
utilized to maintain high standards.

Process

 Framework: The process layer provides a structured framework for the rational and
timely development, management, and quality assurance of software projects.
 Components: It includes project planning, project monitoring and control, requirements
management, risk management, and configuration management.
 Purpose: Ensuring that the software development process is predictable, repeatable, and
measurable, leading to consistent quality outcomes.

Methods

 Technical Guidance: Software engineering methods offer technical guidance for various
tasks including communication, requirements analysis, design, coding, testing, and
support.
 Principles: These methods are based on fundamental principles and best practices that
govern each area of technology. This includes modeling activities and descriptive
techniques.
  Application: Methods ensure that each task is performed systematically and efficiently,
adhering to established standards and procedures.

Tools

 Automation Support: Software engineering tools provide automated or semi-automated

support for processes and methods, enhancing the efficiency and effectiveness of
software development.
 Functions: These tools can include integrated development environments (IDEs), version
control systems, build automation tools, testing tools, and project management software.
 Integration: When tools are integrated, they form a computer-aided software engineering
(CASE) environment, which streamlines the software development process by providing
cohesive support for all phases of the software lifecycle.
 Benefits: Tools help in reducing manual effort, minimizing errors, and ensuring
consistency across different stages of software development.

By understanding and effectively utilizing these layers—quality focus, process, methods, and
tools—software engineering ensures that high-quality software is developed in a structured,
efficient, and repeatable manner.

5)Software Process Framework:

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

6)Software Engineer 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)

 i. Understanding the problem involves identifying stakeholders, clarifying unknowns,
breaking down the problem into smaller parts, and considering graphical representations.
ii. Planning the solution entails recognizing patterns from similar problems, reusing
existing solutions, defining subproblems, and creating design mods.
iii. Carrying out the plan involves following the design as a roadmap, ensuring conformity to
the plan, and verifying the correctness of each component.
iv. Examining the result includes testing each component, validating against requirements,
and uncovering errors through thorough testing.

7)Process Flow:

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.

Linear Process Flow

 Linear process flow, also known as the sequential or waterfall model, organizes
framework activities in a strict, step-by-step sequence.
 Each phase (such as requirements gathering, design, implementation, testing, and
maintenance) must be completed before moving on to the next.
 This model assumes that all requirements can be gathered upfront and that changes are
minimal once the project begins.

Iterative Process Flow

 Iterative process flow involves repeating a series of framework activities, allowing for
refinement and enhancement of the software with each iteration.
 Each cycle produces a working version of the software, which is evaluated and improved
upon in subsequent iterations.
 This approach allows for adjustments based on feedback, making it suitable for projects
where requirements are expected to evolve.

Evolutionary Process Flow

 Evolutionary process flow is characterized by the gradual development of increasingly

complete versions of the software through multiple iterations.
 This model includes approaches like prototyping and the spiral model, where the
software evolves over time with continuous stakeholder feedback and risk assessment.
  It accommodates changes and refinements as the project progresses, making it ideal for
complex and uncertain projects.

8)Process Models

a)Waterfall Model

 The waterfall model is a systematic and sequential approach to software development,

known as the classic life cycle.
 It begins with gathering customer requirements and progresses through planning,
modeling, construction, deployment, and maintenance.
 The process emphasizes the completion of each phase before moving on to the next, with
minimal overlap between phases.
Requirements Gathering

 Document all the needs of stakeholders and define what the software should accomplish.

System Design

 Plan and document the architecture and design of the system, defining how it will be
structured and function to meet requirements.

Implementation

 Developers write code according to the system design and programming standards.

Testing

 Rigorous testing is performed to identify and fix defects or bugs, ensuring the software
meets requirements and functions correctly.

Deployment

 The software is released to end-users, involving installation on users' systems and making
it available for use.

Maintenance

 Post-deployment, updates, enhancements, and bug fixes are made to ensure continued
functionality and relevance.

Limitations

 Real projects rarely follow the sequential flow proposed by the model, causing confusion
when changes occur.
 It is difficult for customers to state all requirements explicitly at the beginning, leading to
challenges in accommodating initial uncertainties.
 Customers must be patient, as a working version of the software is not available until late
in the project timeline.
 Major errors, if undetected until the working program is reviewed, can be disastrous.
b)V-Model:

 The V-model is a variation of the waterfall model, illustrating the relationship between
development activities and quality assurance actions.
 It emphasizes the importance of validation and verification in the software development
process.

Requirements Gathering

 Gather and document all software requirements.

 Corresponding QA action: Requirements review to ensure completeness and correctness.

System Design

 Plan and document the system's architecture and design.

 Corresponding QA action: Design review to verify alignment with requirements.

High-Level Design

 Define the overall system architecture and break down the system into modules.
 Corresponding QA action: High-level design review to ensure the architecture meets the
requirements.

Low-Level Design

 Detailed design of individual modules and components.

  Corresponding QA action: Low-level design review to check the detailed design against
the high-level design and requirements.

Implementation (Coding)

 Actual coding or programming of the software based on design specifications.

 Corresponding QA action: Code reviews, unit testing, and static code analysis to ensure
code quality and adherence to design.

Unit Testing

 Test individual components or modules to verify their functionality.

 Corresponding QA action: Execute unit tests to validate the functionality of individual
modules.

Integration Testing

 Combine modules and test them as a group to verify their interaction.

 Corresponding QA action: Execute integration tests to ensure that modules work together
as intended.

System Testing

 Test the complete system to verify it meets the specified requirements.

 Corresponding QA action: Execute system tests to validate the entire system's
functionality against requirements.

Acceptance Testing

 Validate the software in the user's environment to ensure it meets their needs and
requirements.
 Corresponding QA action: Execute acceptance tests to confirm the system is ready for
deployment.

Deployment

 Release the software to end-users and install it on their systems.

 Corresponding QA action: Verify deployment process and perform final checks to ensure
successful installation and functionality.

Maintenance

 Provide ongoing support, updates, enhancements, and bug fixes.

 Corresponding QA action: Regression testing and validation of updates to ensure
continued functionality and quality.
The V-model emphasizes the parallel relationship between development activities and
corresponding QA actions, ensuring continuous validation and verification throughout the
software development lifecycle.

(OR)

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

c)Spiral Model

The Spiral Model, proposed by Barry Boehm, combines the iterative nature of prototyping
with the structured aspects of the waterfall model.
It enables the rapid development of increasingly complete versions of software.
The model operates as a risk-driven process generator, incrementally growing system
definition and implementation.
It decreases risk through a series of evolutionary releases, with each iteration involving a set
of framework activities.
Risk is considered at each revolution around the spiral path, ensuring proactive identification
and mitigation.
Anchor point milestones mark each pass around the spiral, ensuring stakeholder commitment
to feasible solutions.
Early iterations may produce product specifications, while subsequent iterations result in
prototypes and more sophisticated software versions.
The process is adaptable and can continue throughout the life of the software, evolving from
concept development to product enhancement projects.
The Spiral Model is realistic for large-scale systems but requires expertise in risk assessment.
Convincing customers of its controllability can be challenging in contract situations.
When properly applied, it facilitates risk reduction and provides a systematic approach to
software development that reflects real-world complexities.
Requirement Engineering:

Inception

 Inception marks the beginning of a software project, often triggered by identifying a

business need or market opportunity.
 Stakeholders define a business case, assess market potential, conduct feasibility analysis,
and outline the project scope.
 Initial discussions with the software engineering team establish a basic understanding of
the problem, stakeholders, desired solution, and initial communication effectiveness.

Elicitation

 Elicitation involves gathering requirements from stakeholders, including customers and

users, to understand system objectives, business needs, and usage scenarios.
 Despite its apparent simplicity, elicitation can be challenging and requires careful
communication and collaboration.
 Challenges include scope issues, understanding problems, and volatility issues, as
described by Christel and Kang.

Elaboration

 Elaboration involves expanding and refining the information gathered during inception
and elicitation.
 This phase focuses on developing a detailed requirements model that identifies various
aspects of software function, behavior, and information.
 User scenarios are created and refined, leading to the identification of analysis classes
representing business domain entities, defining attributes and services for each class, and
establishing relationships between classes through supplementary diagrams.

Negotiation

 Negotiation is essential to reconcile conflicts arising from customers or users requesting

more than can be achieved with limited resources, or proposing conflicting requirements.
 Through an iterative process, stakeholders prioritize requirements, discuss conflicts, and
work towards satisfying each party's needs by eliminating, combining, or modifying
requirements.

Specification

 Specification encompasses various forms, including written documents, graphical

models, formal mathematical models, usage scenarios, or prototypes.
 While some advocate for standard templates for consistency, flexibility is necessary
based on the system's size and complexity.
  Large systems may require detailed written documents with natural language descriptions
and graphical models, while smaller systems may only need usage scenarios within well-
understood technical environments.

Validation

 Validation ensures that the work products from requirements engineering are of high
quality.
 During validation, the requirements specification is examined to verify that all
requirements are clearly stated and to identify and correct any inconsistencies, omissions,
or errors.
 The primary mechanism for requirements validation is the technical review, where a
review team scrutinizes the specification to identify errors, clarify ambiguities, find
missing information, resolve inconsistencies, address conflicting requirements, and assess
feasibility.

Requirements Management

 Requirements management involves activities that help the project team identify, control,
and track requirements and changes to requirements throughout the project's life.
 These activities ensure that changes are properly documented, assessed, and
implemented, similar to software configuration management (SCM) techniques.
 Effective requirements management ensures that the project progresses smoothly and that
requirements changes are systematically handled.

Establishing Groundwork:

Identifying Stakeholders

 Sommerville and Sawyer define a stakeholder as anyone benefiting directly or indirectly

from the system being developed.
 Initially, create a list of people contributing to requirements elicitation, such as business
managers, product managers, customers, and engineers.
 This list will expand as stakeholders are contacted and asked for further
recommendations.

Recognizing Multiple Viewpoints

 Different stakeholders have varying viewpoints on system requirements:

o Marketing wants exciting features.
o Business managers focus on budget and timelines.
o End users seek familiar and user-friendly features.
o Software engineers focus on underlying infrastructure.
o Support engineers prioritize maintainability.
 Each group contributes to the requirements engineering process, potentially resulting in
conflicting or inconsistent requirements.
  These requirements should be categorized to help decision makers select a consistent set
of system requirements.

Working toward Collaboration

 In software projects with multiple stakeholders, differing opinions on requirements are

common.
 The requirements engineer's role is to identify agreed-upon requirements and resolve
conflicts or inconsistencies among stakeholders' needs.
 Successful collaboration requires stakeholders to work together and with software
engineers to achieve consensus.

Asking the First Questions

 Questions at the inception of a project should be "context-free" to gain a preliminary

understanding of the problem.
 Initial questions to identify stakeholders, benefits, and alternatives include:
o Who is behind the request for this work?
o Who will use the solution?
o What will be the economic benefit of a successful solution?
o Is there another source for the solution that you need?
 Follow-up questions to understand the problem and customer perceptions include:
o How would you characterize “good” output from a successful solution?
o What problem(s) will this solution address?
o Can you describe the business environment where the solution will be used?
o Will special performance issues affect the solution?
 Focus on the communication process with "meta-questions":
o Are you the right person to answer these questions?
o Are my questions relevant to the problem?
o Am I asking too many questions?
o Can anyone else provide additional information?
o Should I be asking you anything else?
 These questions initiate communication, but the Q&A format should be used only
initially and replaced by a more interactive elicitation format involving problem-solving,
negotiation, and specification.

Eliciting Requirements

 Requirements elicitation combines problem solving, elaboration, negotiation, and

specification.
 Stakeholders collaborate to identify the problem, propose solutions, negotiate approaches,
and specify preliminary requirements.

Guidelines for Collaborative Requirements Gathering

 Meetings include software engineers and stakeholders.

  Preparation and participation rules are established.
 A flexible agenda encourages idea exchange.
 A facilitator oversees the meeting.
 A definition mechanism (like worksheets or electronic forums) is used.

Meeting Preparation and Execution

 During project inception, initial meetings define the scope and solution.
 This leads to a "product request" distributed to attendees before a requirements gathering
meeting.
 A facilitator, selected beforehand, helps coordinate the session.

SafeHome Example

 A marketing narrative about SafeHome's home security function details system features
like wireless sensors and automatic emergency calls.
 Stakeholders review the product request, make lists of relevant objects, services,
constraints, and performance criteria, and prepare for the meeting.

Meeting Activities

 During the meeting, stakeholders present their lists, which are combined and refined
through discussion led by the facilitator.
 Mini-specifications elaborate on items in the lists, with further adjustments made based
on group input.
 Issues requiring further resolution are noted and addressed later.