1. What is Software Engineering?

Briefly explain the 5 steps involved in Problem

Solving in Engineering.
Software Engineering is the application of engineering principles to the design, development, maintenance,
testing, and evaluation of software and systems. Software Engineering is a modeling, problem solving,
knowledge acquisition and rationale(purpose) driven activity.
The problem-solving method in engineering involves a structured approach to finding effective solutions.
Here's a brief explanation of the five steps:
1. Formulate the Problem: Clearly define the problem you are trying to solve. This involves
understanding the context, constraints, and objectives. The goal is to precisely identify what needs to be
addressed before moving forward.
2. Analyze the Problem: Break down the problem into smaller components to understand its nature and
the relationships between different factors. This step involves gathering data, identifying limitations,
and considering various perspectives to form a deeper understanding of the issue.
3. Search for Solutions: Explore different possible solutions or approaches. This step involves
brainstorming and researching alternatives, drawing from previous experiences, or investigating new
technologies or methods that could work.
4. Decide on the Appropriate Solution: Evaluate the possible solutions based on criteria such as
feasibility, cost, time, and effectiveness. Select the solution that best addresses the problem while
meeting the necessary requirements and constraints.
5. Specify the Solution: Once the best solution is chosen, clearly document the details for implementation.
This includes defining the technical specifications, necessary resources, and a plan for execution,
ensuring the solution is fully understood and actionable.

2. Explain in detail the various Software Engineering Development Activities.

Development activities in Software Engineering deal with the complexity by constructing and validating
models of the application domain or the system. Development activities include,

 Requirements Elicitation
 Analysis
 System Design
 Object Design
 Implementation
 Testing

Requirements Elicitation:
 During requirements elicitation, the client and developers define the purpose of the system.
 The result of this activity is a description of the system in terms of actors and use cases.
 Actors represent the external entities that interact with the system. Actors include roles such as end
users, other computers the system needs to deal with (e.g., a central bank computer, a network), and the
environment (e.g., a chemical process).
 Use cases are general sequences of events that describe all the possible actions between an actor and the
system for a given piece of functionality.
Real-world Example:
or an e-commerce platform, the requirements elicitation phase would involve meetings with the business
owner, sales team, and customers to understand the features needed, such as:

 Product browsing and searching

 Secure payment gateway
 User reviews and ratings
 Order tracking system

Analysis:
 During analysis, developers aim to produce a model of the system that is correct, complete, consistent,
and unambiguous.
 Developers transform the use cases produced during requirements elicitation into an object model that
completely describes the system.
 During this activity, developers discover ambiguities and inconsistencies in the use case model that they
resolve with the client.
 The result of analysis is a system model annotated with attributes, operations, and associations. The
system model can be described in terms of its structure and its dynamic interoperation.

Real-World-Example:
For the e-commerce platform, the analysis phase might reveal that the platform needs to handle large traffic
spikes during sales events (e.g., Black Friday). It may also identify the need for multi-currency support if
the business operates globally.

System Design:

 During system design, developers define the design goals of the project and decompose the system into
smaller subsystems that can be realized by individual teams.
 Developers also select strategies for building the system, such as the hardware/software platform on
which the system will run, the persistent data management strategy, the global control flow, the access
control policy, and the handling of boundary conditions.
 The result of system design is a clear description of each of these strategies, a subsystem decomposition,
and a deployment diagram representing the hardware/software mapping of the system.
 Whereas both analysis and system design produce models of the system under construction, only
analysis deals with entities that the client can understand. System design deals with a much more refined
model that includes many entities that are beyond the comprehension (and interest) of the client.

Real-World Example:
For the e-commerce platform, system design would define:

 The high-level architecture (e.g., client-server model)

 Technologies to use (e.g., React for the front end, Node.js for the back end, MySQL for the database)
 Components (e.g., user authentication module, product catalog, checkout process)
 How data will flow between the frontend and backend

Object Design:

 During object design, developers define solution domain objects to bridge the gap between the analysis
model and the hardware/software platform defined during system design.
 This includes precisely describing object and subsystem interfaces, selecting off-the-shelf components,
restructuring the object model to attain design goals such as extensibility or understandability, and
optimizing the object model for performance.
 The result of the object design activity is a detailed object model annotated with constraints and precise
descriptions for each element.

Real-World Example:
For the e-commerce platform, object design would define the classes such as:

 User (with attributes like name, email, password) and methods like register(), login()
 Product (with attributes like name, price, description) and methods like addProduct(), updateStock()
 Order (with attributes like order ID, date, products) and methods like placeOrder(), trackOrder()

Implementation:

 During implementation, developers translate the solution domain model into source code.
 This includes implementing the attributes and methods of each object and integrating all the objects such
that they function as a single system.
 The implementation activity spans the gap between the detailed object design model and a complete set
of source code files that can be compiled.

Real-World Example:
For the e-commerce platform, implementation would involve:

 Writing the frontend code (e.g., HTML, CSS, JavaScript) to create the user interface for browsing
products and checking out.
 Developing backend code (e.g., Node.js, Express) to handle server requests, process payments, and
manage the database.
 Integrating third-party services like payment gateways (e.g., PayPal, Paytm).

Testing:

 During testing, developers find differences between the system and its models by executing the system
(or parts of it) with sample input data sets.
 During unit testing, developers compare the object design model with each object and subsystem. During
integration testing, combinations of subsystems are integrated together and compared with the system
design model.
 During system testing, typical and exception cases are run through the system and compared with the
requirements model.
 The goal of testing is to discover as many faults as possible such that they can be repaired before the
delivery of the system.
 The planning of test phases occurs in parallel to the other development activities: System tests are
planned during requirements elicitation and analysis, integration tests are planned during system design,
and unit tests are planned during object design.

Real-World Example:
For the e-commerce platform, testing would involve:

 Unit testing: Verifying individual functions, such as checking if the placeOrder() function works
correctly.
 Integration testing: Ensuring that the product catalog integrates with the checkout process.
 User acceptance testing (UAT): A small group of users might test the platform to confirm that it’s easy
to use, the checkout process is smooth, and the payment system works.
3. Explain the various activities involved in Managing Software Development.
Management activities focus on planning the project, monitoring its status, tracking changes, and
coordinating resources such that a high-quality product is delivered on time and within budget. Management
activities not only involve managers, but also most of the other project participants as well.
Management activities include,
 Communication
 Rationale Management
 Software Configuration Management
 Project Management
 Software Life Cycle

Communication:
 Communication is the most critical and time-consuming activity in software engineering.
 Misunderstandings and omissions often lead to faults and delays that are expensive to correct later in
the development.
 Communication includes the exchange of models and documents about the system and its application
domain, reporting the status of work products, providing feedback on the quality of work products,
raising and negotiating issues, and communicating decisions.
 Communication is made difficult by the diversity of participants’ backgrounds, by their geographic
distribution, and by the volume, complexity, and evolution of the information exchanged.
 To deal with communication issues, project participants have many tools available.
 The most effective one is conventions: When participants agree on notations for representing
information, on tools for manipulating information, and on procedures for raising and resolving issues,
they already have eliminated substantial sources of misunderstanding.
Rationale Management:
 Rationale is the justification of decisions. Given a decision, its rationale includes the problem that it
addresses, the alternatives that developers considered, the criteria that developers used to evaluate the
alternatives, the debate developers went through to achieve consensus, and the decision.
 Rationale is the most important information developers need when changing the system.
 If a criterion changes, developers can reevaluate all decisions that depend on this criterion.
 If a new alternative becomes available, it can be compared with all the other alternatives that were
already evaluated.
 If a decision is questioned, they can recover its rationale to justify it.
 Unfortunately, rationale is also the most complex information developers deal with during development,
and thus, the most difficult to update and maintain.
 To deal with this challenge, developers capture rationale during meetings and on-line discussions,
represent rationale with issue models, and access rationale during changes.
Software Configuration Management:

 Software configuration management is the process that monitors and controls changes in work products.
 Change pervades software development. Requirements change as the client requests new features and
as developers improve their understanding of the application domain.
 The hardware/software platform on which the system is built changes as new technology becomes
available.
  The system changes as faults are discovered during testing and are repaired.
 Software configuration management used to be in the realm of maintenance, when improvements are
incrementally introduced in the system.
 In modern development processes, however, changes occur much earlier than maintenance does. Thus,
changes during development can be dealt with using configuration management at all stages.

 Configuration management enables developers to track changes. The system is represented as a number
of configuration items that are independently revised.
 For each configuration item, its evolution is tracked as a series of versions. Selecting versions enables
developers to roll back to a well-defined state of the system when a change fails.

 Configuration management also enables developers to control change. After a baseline has been defined,
any change needs to be assessed and approved before being implemented.
 This enables management to ensure that the system is evolving according to project goals and that the
number of problems introduced into the system is limited.

Project Management:

 Project management does not produce any artifact of its own. Instead, project management includes the
oversight activities that ensure the delivery of a high-quality system on time and within budget.
 This includes planning and budgeting the project during negotiations with the client, hiring developers
and organizing them into teams, monitoring the status of the project, and intervening when deviations
occur.
 however, the project management activities that are visible to the developers and techniques that make
the development–management communication more effective.

Software Life Cycle:

 We describe software engineering as a modeling activity. Developers build models of the application
and solution domains to deal with their complexity.
 By ignoring irrelevant details and focusing only on what is relevant to a specific issue, developers can
more effectively resolve issues and answer questions.
 The process of developing software can also be viewed as a complex system with inputs, outputs,
activities, and resources.
 It is not surprising, then, that the same modeling techniques applied to software artifacts are used for
modeling software processes.
 A general model of the software development process is called a software life cycle.

4. Explain in brief, the five UML notations.

UML (Unified Modeling Language) is a standardized visual language used for specifying, visualizing,
constructing, and documenting the artifacts of a software system. UML uses a set of notations to represent
different aspects of a system, such as structure, behavior, and interactions. These notations help developers,
designers, and stakeholders understand and communicate the design of a system.
The five UML notations are:
 Use Case Diagrams
 Class Diagrams
 Interaction Diagrams
 State Machine Diagrams
 Activity Diagrams

Use Case Diagrams:

 Use cases are used during requirements elicitation and analysis to represent the functionality of the system.
 Use cases focus on the behavior of the system from an external point of view. A use case describes a function
provided by the system that yields a visible result for an actor.
 An actor describes any entity that interacts with the system (e.g., a user, another system, the system’s
physical environment).
 The identification of actors and use cases results in the definition of the boundary of the system, that is, in
differentiating the tasks accomplished by the system and the tasks accomplished by its environment.
 The actors are outside the boundary of the system, whereas the use cases are inside the boundary of the
system.

Real-World-Example:
For a banking system:

 Actors: Customer, Bank Teller, Admin

 Use Cases:
o Customer can log in, check balance, transfer money, and withdraw funds.
o Bank Teller can view account details and assist customers with transactions.
o Admin can manage users, view system logs, and set interest rates.

The diagram would show actors like "Customer" and "Admin" linked to use cases like "Log In," "Transfer
Money," and "View Balance."

Class Diagrams:

 Class diagrams are used to describe the structure of the system. Classes are abstractions that specify the
common structure and behavior of a set of objects.
 Objects are instances of classes that are created, modified, and destroyed during the execution of the system.
 An object has state that includes the values of its attributes and its links with other objects.
 Class diagrams describe the system in terms of objects, classes, attributes, operations, and their associations.

Real-World-Example:
For an e-commerce system:

 Classes: Customer, Product, Order

 Attributes: Customer might have attributes like name, address, email, and phone.
 Methods: Order class might have methods like placeOrder(), cancelOrder().
 Relationships:
o The Customer class might be associated with multiple Order objects (one-to-many relationship).
o The Order class might have a relationship with Product objects (many-to-many relationship).

This diagram would show how these classes relate and interact within the system.

Interaction Diagrams:
 Interaction diagrams are used to formalize the dynamic behavior of the system and to visualize the
communication among objects.
  They are useful for identifying additional objects that participate in the use cases. We call objects
involved in a use case participating objects.
 An interaction diagram represents the interactions that take place among these objects.

Real-World-Example:
For a login process in a web application:

 Sequence Diagram might show:

o User enters credentials into the login page (actor).
o The LoginPage sends the credentials to the AuthenticationService (object).
o The AuthenticationService verifies the credentials and sends a response back to the
LoginPage.
o If credentials are correct, the user is granted access; if incorrect, an error message is shown.

This diagram represents how the system’s components communicate in sequence during the login process.

State Machine Diagrams:

 State machine diagrams describe the dynamic behavior of an individual object as a number of states and
transitions between these states.
 A state represents a particular set of values for an object. Given a state, a transition represents a future state
the object can move to and the conditions associated with the change of state.
 The sequence diagram focuses on the messages exchanged between objects as a result of external events
created by actors.
 The state machine diagram focuses on the transitions between states as a result of external events for an
individual object.

Real-World-Example:
For an Order Processing System:

 States: OrderPlaced, OrderShipped, OrderDelivered, OrderCanceled

 Events: ShipOrder, DeliverOrder, CancelOrder
 Transitions:
o When an Order is placed, it transitions from OrderPlaced to OrderShipped.
o If the order is delivered, it moves from OrderShipped to OrderDelivered.
o If canceled, it transitions to OrderCanceled.

This diagram would show the lifecycle of an order as it moves through different stages based on events like
shipping and delivery.

Activity Diagrams:

 An activity diagram describes the behavior of a system in terms of activities.

 Activities are modeling elements that represent the execution of a set of operations. The execution of an
activity can be triggered by the completion of other activities, by the availability of objects, or by external
events.
 Activity diagrams are similar to flowchart diagrams in that they can be used to represent control flow (i.e.,
the order in which operations occur) and data flow (i.e., the objects that are exchanged among operations).
Real-World-Example:
For a user registration process:
 Activities:
o Start the registration process
o Enter user details (e.g., name, email, password)
o Validate input (e.g., check if email is valid)
o Confirm registration via email
o Store user data in the database
o Finish the registration process
The diagram would show each activity in a sequence, with decision points (e.g., if the email is valid or invalid)
and the flow from one activity to another.

5. Explain Use Case Diagrams with an example.

Use Case Diagrams:

 Use cases are used during requirements elicitation and analysis to represent the functionality of the system.
 Use cases focus on the behavior of the system from an external point of view. A use case describes a function
provided by the system that yields a visible result for an actor.
 An actor describes any entity that interacts with the system (e.g., a user, another system, the system’s
physical environment).
 The identification of actors and use cases results in the definition of the boundary of the system, that is, in
differentiating the tasks accomplished by the system and the tasks accomplished by its environment.
 The actors are outside the boundary of the system, whereas the use cases are inside the boundary of the
system.

Real-World-Example:
For an Online banking system:
 1. A Customer is required to create an account to avail services offered by Bank. Bank verifies detail and
creates new account for each new customer. Each customer is an actor for the Use-Case Diagram and
the functionality offered by Online Banking System to Add Account is Use-Case.
2. Each customer can check the balance in bank account and initiate request to transfer an account across
distinct branches of Bank. Cashier is an employee at bank who supports service to the customer.
3. A customer can execute cash transactions where the customer must either add cash value to bank account
or withdraw cash from account. Either of two or both that is credit as well as debit cash, might be
executed to successfully execute one or multiple transactions.
4. After each successful transaction customer might or might not want to get details for action. Manager
can check interest value for each account corresponding to transaction to ensure and authenticate details.
5. A customer can also request loan from bank where customer must add request for loan with the
appropriate details.
6. The type of loan in accordance with purpose or the need for loan and term or duration to pay back the
loan must be provided by customer.
7. The manager of each branch of bank has choice to either accept or approve loan to initiate process further
or just reject request for loan based on terms and conditions.
8. The record for each employee of bank is maintained by bank and bank manages all employees of each
branch of bank. The manager of each branch has choice to offer bonus to employees. Note here that
each employee is paid as part of management of staff but promotion or bonus might or might not be
offered certainly to each employee.

Benefits of Use Case Diagrams:

 They help stakeholders understand system functionality.

 They provide a clear overview of user interactions.
 They are useful in defining requirements.
 They help in communicating with both technical and non-technical team members.

6. Explain State Machine Diagrams with an example.

State Machine Diagrams:

 State machine diagrams describe the dynamic behavior of an individual object as a number of states and
transitions between these states.
 A state represents a particular set of values for an object. Given a state, a transition represents a future state
the object can move to and the conditions associated with the change of state.
 The sequence diagram focuses on the messages exchanged between objects as a result of external events
created by actors.
 The state machine diagram focuses on the transitions between states as a result of external events for an
individual object.
Example:

 On the event of an order being received, we transit from our initial state to Unprocessed order state.
 The unprocessed order is then checked.
 If the order is rejected, we transit to the Rejected Order state.
 If the order is accepted and we have the items available, we transit to the fulfilled order state.
 However, if the items are not available we transit to the Pending Order state.
 After the order is fulfilled, we transit to the final state. In this example, we merge the two states i.e. Fulfilled
order and Rejected order into one final state.

7. Explain Interaction Diagrams with an example.

Interaction(Sequence) Diagrams:
 Interaction diagrams are used to formalize the dynamic behavior of the system and to visualize the
communication among objects.
 They are useful for identifying additional objects that participate in the use cases. We call objects involved
in a use case participating objects.
 An interaction diagram represents the interactions that take place among these objects.
Example:
Login process

 This sequence diagram starts when a user visits a login page. The user enters their username and password
and hits the login button.
 The login page sends a message to the database with the user login data to be checked.
 Once the database has checked the username and password, two possible paths emerge (alternative
fragment).
 If the login data is correct, the database sends a message that the user login has been accepted. If the login
data was incorrect, the system sends the user a message indicating so.
 The system clears the password field. Then the user can enter the password again.

8. Define Project. Write UML class diagram for Model of a project and explain.
Projects can be defined formally or informally.
Formal definition of a project: A signed contract between a Company and a client requiring the delivery of a
software system in fixed time for a decided amount of money.
Work Product:
 A Work Product is a tangible or intangible output created as a result of project work. It refers to the
deliverables or artifacts that are produced during the course of the project.
 These are the outcomes or deliverables of the project that can be either intermediate or final results. They
represent the actual work products generated from various tasks or activities.
 Example: i. In a software development project, work products could be: Source code files, User
documentation, Test cases or test reports etc…
ii. In a construction project, work products could be: Architectural blueprints, building structures,
Construction materials used etc…

Schedule:
 The Schedule is a detailed timeline that specifies when project tasks and activities need to be completed. It
includes start and end dates, milestones, deadlines, and dependencies between tasks.
 The schedule helps manage time and resources effectively. It outlines the sequence of events, dependencies
between tasks, and the timeline within which the work needs to be completed. It helps ensure that the project
stays on track.
Task:

 A Task is a specific activity or action that needs to be performed to accomplish a part of the project. It is a
smaller, manageable unit of work that contributes to the completion of project objectives.
 Tasks are the building blocks of the project and are often broken down from larger phases or objectives.
Each task has a defined purpose, timeline, and required resources to be completed.

Participant:

 A Participant is any person or group involved in the project who contributes to the completion of tasks,
decision-making, or any other aspect of the project. They can include team members, stakeholders, clients,
or external contractors.
 Participants play different roles in the project, each responsible for specific tasks, decisions, or deliverables.
They contribute their expertise, effort, and time to ensure the project’s success.
 Example: In a software project, participants could be: Developers, Designers, Testers, Stakeholders etc…
Example of a Project with the 4 Components:

Project: Developing a Mobile Application for Online Shopping

 Work Product:
o A fully functional mobile application (iOS/Android) for online shopping.
o User manual and documentation for using the application.
 Schedule:
o Requirement Gathering: May 1 – May 7
o Design Phase: May 8 – May 15
o Development Phase: May 16 – July 15
o Testing Phase: July 16 – July 25
o Deployment and Maintenance: July 26 onwards
 Task:
o Requirement Gathering: Meet with the client to gather the features for the app (tasks include
creating surveys, customer interviews).
o UI Design: Design the interface for different screens (login, product catalog, checkout).
o Development: Implement the app’s front-end and back-end, including payment gateway
integration.
o Testing: Test the application on multiple devices for bugs, usability, and performance.
 Participants:
o Project Manager: Oversees the project’s progress, handles communication with the client, and
ensures tasks are completed on time.
o Software Developers: Responsible for coding the application.
o UI/UX Designers: Create the user interface and ensure that the app is intuitive.
o Quality Assurance Testers: Test the application for bugs and report issues to developers.
o Clients/End Users: Provide feedback and approval after each phase.

9. What is Planned Communication? Explain in brief the events involved in Planned

Communication.
Planned communication in a project refers to a deliberate and structured approach to exchanging information
among project stakeholders, outlining exactly what information needs to be shared, who should receive it, when
it should be delivered, and through which communication channels, all documented within a communication
plan to ensure effective and coordinated communication throughout the project lifecycle.
Planned communication events include,
 Problem presentation
 Client reviews
 Project reviews
 Peer reviews
 Status reviews
 Brainstorming
 Releases
 Postmortem reviews
Problem presentation:
 The focus of problem presentation is the presentation of the Problem Statement that describes the problem,
the application domain, and the desired functionality of the system.
 It also contains nonfunctional requirements such as platform specification or speed constraints.
 The problem statement does not include a complete specification of the system.
 It is merely a preliminary requirements activity that establishes common ground between the client and the
project team.

Client reviews:
 The goal of client reviews is for the client to assess the progress of the development and for the developers
to confirm or change the requirements of the system.
 The client review is used to manage expectations on both sides and to increase the shared understanding
among participants.
 The focus of the review is on what the system does and what constraints are relevant to the client (e.g.,
performance, platform).
 In most cases, the review should not focus on the design or implementation of the system unless they affect
the client or the user.
 A client review is conducted as a formal presentation during which the developers focus on specific
functionality with the client.
 The review is preceded by the release of a work product, such as a specification document, an interface
mock-up, or an evaluation prototype.
 At the outcome of the review, the client provides feedback to the developers. This feedback may consist of
a general approval or a request for detailed changes in functionality or schedule.

Project reviews:

 The goals of a project review are for the project manager to assess status and for teams to review subsystem
interfaces.
 Project reviews can also encourage the exchange of operational knowledge across teams, such as common
problems encountered with tools or the system.
 The focus of the review depends on the deliverable under review. For system design, the decomposition and
high-level subsystem interfaces are reviewed.
 For object design, the object interfaces are reviewed. For integration and testing, the tests and their results
are reviewed.
 A project review is typically conducted as a formal presentation during which each team presents its
subsystem to the management or to teams that depend on the subsystem.

Peer reviews:

 The objective of code inspections and walkthroughs is to increase the quality of a subsystem through peer
review.
 During walkthrough, a developer presents to the other members of her team line-by-line the code she has
written.
 The other team members challenge any suspicious code and attempt to discover as many errors as possible.
The role of the developer is to facilitate the presentation and answer the team’s questions.
 During inspections, the members of the team focus on the compliance of the code with a predefined list of
criteria. (For example, does the code implement the specified algorithm? Does the code correctly use
dependent subsystem interfaces?)
 During inspections, the team leads the discussion, and the developer answers questions. The focus of the
inspection or walkthrough is on the code, not on the programmer or the design.
 Communication among participants is code based. The actual code is used as a common frame of reference.
Inspections are similar to project reviews in their objective to increase quality and disseminate operational
information.

Status reviews:

 Unlike client and project reviews that focus on the system, status reviews focus on tasks. Status reviews are
primarily conducted in a team (e.g., weekly) and occasionally conducted in a project (e.g., monthly).
 The objective of status reviews is to detect deviations from the task plan and to correct them. Status reviews
also encourage developers to complete pending tasks.
 The review of task status encourages the discussion of open issues and unanticipated problems, and, thus,
encourages informal communication among team members.
 Often, solutions to common issues can be shared and operational knowledge disseminated more effectively
when discussed within the scope of a team (as opposed to within the scope of the project).

Brainstorming:

 The goal of the brainstorming process is to generate a large number of solutions to a problem, regardless of
their merit, then evaluate them.
 Brainstorming is usually done in face-to-face meetings, but can also be done via E-mail or groupware.
 The fundamental idea behind brainstorming is that ideas, however invalid, proposed by any participant can
trigger other ideas and proposals from other participants.
 In particularly difficult problems, the solution often comes from an idea that initially sounded very wrong.
Brainstorming encourages thinking “outside the box.”
 When many ideas have been generated, begin evaluating them. Brainstorming also has two beneficial side
effects: evaluating proposals within the group will lead to more explicit evaluation criteria, and the
brainstorming process itself has the effect of building consensus for the chosen solution.

Releases:

 The goal of a release is to make a work product available to other project participants, often replacing an
older version of the artifact.
 A release can be as simple as a two-line electronic message, or it can consist of several pieces of information:
the new version of the artifact, a list of changes made since the last release of the artifact, a list of problems
or issues yet to be addressed, and an author.
 Releases are used to make a large amount of information available in a controlled manner by batching,
documenting, and reviewing many changes together.
 Project and client reviews are typically preceded by a release of one or more deliverables.
Postmortem reviews:

 Postmortem reviews focus on extracting lessons from the development team once the software is delivered.
Postmortem reviews need to be conducted shortly after the end of the project so that minimal information
is lost or distorted by subsequent experience.
 The end of the project is usually a good point in time to assess which techniques, methods, and tools have
worked and have been critical to the success (or failure) of the system.
 A postmortem can be conducted as a brainstorming session, a structured questionnaire followed by
interviews, or individual reports written by teams (or participants).
 In all cases, the areas covered should include the tools, methods, organization, and procedures used by the
project.
 Even if the results of post mortems are not disseminated through the company via formal channels (e.g.,
technical reports), they can still be disseminated indirectly to the project participants.
 Project participants are frequently reassigned to different projects or functions and often disseminate the
lessons learned from the old project to other parts of the company.
 Hence, postmortem reviews are ideal for crystallizing the lessons learned from a recently completed (or
canceled) project.

10.What is Unplanned Communication? Explain the events involved in Unplanned

Communication.
Unplanned communication in a project refers to any form of communication that occurs without prior planning,
structure, or scheduling. It is often spontaneous, informal, and can arise from unexpected issues, changes, or
opportunities that emerge during the course of a project.
Unplanned communication includes,
 Requests for clarification
 Requests for changes
 Issue resolution.

Requests for clarification:

 Requests for clarification represent the bulk of the communication among developers, clients, and users.
Requests for clarification are unplanned.
 A participant may request clarification about any aspect of the system that seems ambiguous.
 Requests for clarification may occur during informal meetings, phone calls, E-mail, or any other
communication mechanism available to the project.
 Situations in which most information needs are handled through requests for clarifications are symptoms of
a defective communication infrastructure.
 Such projects often face serious failures downstream resulting from misunderstandings and missing and
misplaced information.

Requests for changes:

 During a request for change, a participant reports a problem and, in some cases, proposes solutions. The
participant reports a problem with the system itself, its documentation, the development process, or the
project organization.
 Requests for change are often formalized when the number of participants and the system size is substantial.
 Change requests contain a classification (e.g., severe defect, feature request, comment), a description of the
problem, a description of the context in which it occurs, and any supporting material.
 Change request forms have been popularized by defects-tracking software. They can be applied to other
aspects of the project (e.g., task plan, development process, testing procedures).

Issue resolution:

 Once problems have been reported and solutions proposed and evaluated, a single solution must be selected,
communicated, and implemented.
 A flat organization may select a solution through the brainstorming process. A hierarchical organization or
a crisis situation may require a single individual to select and impose a solution.
 In all cases, the decision needs to be documented and communicated to the relevant participants.
 Documentation of the resolution allows participants to refer back to the decision later in the project, in case
of a misunderstanding.
 Effective communication of the decision enables participants to remain synchronized.
 An issue base can serve as a communication mechanism for supporting problem tracking and issue
resolution.