UNIT-II

2.1. Software Management Process Framework

Standardizing on a common process is a courageous undertaking for a software
organization, and there is a wide spectrum of implementations. The process
framework recommended in comprises only a handful of specific standards: life-
cycle phases, life-cycle artifacts, life-cycle workflows, and life-cycle checkpoints.
These elements are key discriminators in making the transition from the
conventional approach to an iterative, line-of-business approach. I have seen
organizations attempt to do less {too little, or no, standardization) and more
(too much standardization), with little success in improving software return on
investment. Process standardization requires a balanced approach.
The chapters in Part II describe the framework of a modern, iterative software
management process: the life-cycle phases, the artifacts, the workflows, and the
checkpoints. Architecture first is a key theme integrated throughout these chapters,
and a chapter on architecture is sandwiched in with the others. Although this book is
not intended to be about architecture, the management perspective of architecture
and of the architecture's emphasis is vital to the success of the whole approach.
Frameworks typically offer a combination of libraries, tools, and application
programming interfaces (APIs) that simplify the development process by
abstracting away common functionalities, such as handling input/output, database
interactions, user interface rendering, networking, and much more.

2.1.1 Origins of software frameworks

The concept of software frameworks began to emerge in the late 1960s and early
1970s as a response to the growing complexity of software development. During
this time, programmers realized the need for reusable and standardized components
that could simplify the development process and promote code reuse.
One of the pioneering figures in the development of software frameworks was
Douglas C. Engelbart. Engelbart, often called the “father of the computer mouse,”
envisioned a collaborative computing system and developed the NLS (oN-Line
System) in the 1960s.
NLS can be considered one of the earliest examples of a software framework, as it
supplied a set of tools and components to create interactive applications and
organize information.

2.1.2 Frameworks vs. architecture: What’s the difference?

Software framework
A software framework offers a structure for application development with a set
of predefined rules, guidelines, libraries, and tools that simplify the
development process by abstracting common functionalities.
Frameworks offer reusable components and establish conventions that
developers can build upon for specific application requirements. Their primary
 UNIT-II
goal is to provide a standardized structure and promote code reuse to enhance
productivity and maintainability.

Software architecture
In comparison, software architecture defines the overall structure and
organization of a software system or an application. It encompasses the high-
level design decisions, principles, and patterns that guide the development and
deployment of an application.
It focuses on strategic concerns such as system scalability, performance,
security, reliability, and maintainability. It outlines the relationships between
different components or modules, the flow of data, and the interaction between
various systems within the application
2.1.3 Types of Frameworks
.

Fig. No. 2.1.1 Software Framework

2.1.3.1 Web application frameworks

These frameworks are designed to simplify the development of web applications
by providing a structure and set of tools. They often include features like
routing, database integration, session management, and user authentication. For
example, Ruby on Rails follows the MVC architectural pattern and includes a
wide range of built-in functionalities, making it efficient for building web
applications.

2.1.3.2 Mobile application frameworks

Mobile app frameworks enable developers to create applications that can run on
multiple platforms, such as iOS and Android. They offer tools to build user
interfaces, handle device-specific features, and access native device APIs. React
Native, for instance, allows developers to write code once and deploy it on both
platforms, resulting in time and cost savings.
 UNIT-II
2.1.3.3 Front-end frameworks
These frameworks focus on the client-side development of web applications,
primarily dealing with user interface (UI) components and interactivity. They
provide libraries, templates, and utilities to build responsive and visually
appealing interfaces. AngularJS, for example, offers data binding, modular
architecture, and dependency injection, making it easier to manage complex
front-end projects.

2.1.3.4 Backend frameworks

Backend frameworks are used for server-side development, handling tasks such
as request processing, database integration, and business logic implementation.
They come with abstractions and tools to streamline the development process.
Express.js, a popular backend framework for Node.js, simplifies route
handling, middleware management, and API development.

2.1.3.5 Testing frameworks

Testing frameworks assist in automating the testing process of software

applications, ensuring the reliability and correctness of the code. They offer
functions for writing test cases, executing tests, and generating reports. JUnit,
for instance, is a widely used testing framework for Java applications,
facilitating unit testing and test-driven development practices.

2.1.3.6 Game development frameworks

Game development frameworks simplify the creation of video games with their
range of tools and features. They often include game physics engines, asset
management systems, and rendering capabilities. Unity is a popular framework
that allows developers to build games for multiple platforms with its visual
editor and extensive library of resources.

2.1.3.7 Machine learning (ML) frameworks

Machine learning frameworks offer a collection of algorithms, tools, and
libraries for developing machine learning models with abstractions for handling
data preprocessing, model training, and deployment. TensorFlow, one of the
most widely used ML frameworks, supports deep learning, neural networks, and
distributed computing.

2.1.3.8 Enterprise application frameworks

These frameworks are designed to develop large-scale enterprise applications
that often require complex functionalities and integration with existing systems.
They provide features for security, scalability, and modular architecture. Java
EE, for example, offers a comprehensive set of APIs for building enterprise
 UNIT-II
applications, including support for database connectivity, messaging, and web
services.

2.1.3.9 Graphical user interface (GUI) frameworks

GUI frameworks simplify creating graphical user interfaces for desktop or

mobile applications with tools to design UI components, handle user input, and
manage events. Qt, a popular GUI framework, supports cross-platform
development, allowing developers to create native-looking interfaces for various
operating systems.
2.1.4 Framework Examples
Here are six top examples of frameworks across different
types of domains:

2.1.4.1 Ruby on Rails (Rails)

Rails, also called Ruby on Rails, is a web application framework written in
Ruby programming language. It follows the MVC architectural pattern,
providing a structured approach to building web applications. Rails emphasizes
convention over configuration, which means it includes sensible default
configurations and conventions that help developers write clean and
maintainable code.It offers features like automatic database table creation,
RESTful routing, and built-in support for data validation and security. Rails also
has a vast ecosystem with a strong community, extensive documentation, and
numerous libraries (gems) that extend its functionality.
2.1.4.2 Django
Django is a high-level Python web framework renowned for its simplicity,
scalability, and rapid development capabilities. It follows the MVC architectural
pattern and focuses on “batteries included,” meaning it includes a range of built-
in features and functionalities out of the box.Django offers an object-relational
mapper (ORM) for database handling, robust authentication and authorization
systems, automatic admin interface generation, and powerful templating. It
promotes code reusability through modularity and supports the creation of
complex web applications efficiently.
2.1.4.3 AngularJS
AngularJS is a popular front-end JavaScript framework developed by Google. It
facilitates the development of dynamic, single-page applications (SPAs).
AngularJS follows the MVVM (Model-View-ViewModel) architectural pattern,
enabling developers to build responsive and interactive user interfaces. It
provides powerful data binding, dependency injection, and component-based
architecture.AngularJS allows developers to create reusable HTML components
and offers features like form validation, routing, and testing support. With its
comprehensive documentation, active community, and TypeScript support in
newer versions (Angular), it remains a go-to choice for large-scale front-end
development.
 UNIT-II
2.1.4.4 Express.js
Express.js is a minimalistic, fast, and flexible backend web application
framework for Node.js. It provides a lightweight layer on top of Node.js,
simplifying the creation of server-side web applications and APIs.Express.js
offers robust features such as routing, middleware support, template engines,
and easy integration with databases. It allows developers to build scalable and
modular applications following the middleware-based architecture quickly. Its
simplicity and wide adoption make it popular for building lightweight or
microservice-oriented applications.
2.1.4.5 Spring
Spring is a Java-based framework for building enterprise-level applications. It is
known for its lightweight nature and extensive support for modular
development. Spring provides features like dependency injection, aspect-
oriented programming, and declarative transaction management. It also
integrates well with other Java-based technologies and frameworks, making it
suitable for building robust and scalable enterprise applications.
2.1.4.6 TensorFlow
TensorFlow is an open-source machine learning framework developed by
Google. It provides a comprehensive ecosystem for building and deploying
machine learning models. TensorFlow supports both deep learning and
traditional ML algorithms, allowing developers to create complex models for
tasks like image recognition, natural language processing, and predictive
analytics.
Ref 1 :https://www.spiceworks.com/tech/tech-general/articles/what-is-
framework/#:~:text=Is%20a%20Framework%3F-,A%20software
%20framework%20is%20a%20set%20of%20reusable%20software
%20components,and%20enabling%20more%20efficient%20development.
Ref2: Software Project Management by Walker Royce

2.2. Life cycle phase

The project management lifecycle is a step-by-step framework of best
practices used to monitor a project from its beginning to its end. It provides
project managers with a structured way to create, execute, and finish a
project.
This project management process generally includes four phases: initiating,
planning, executing, and closing. Some may also include a fifth
“monitoring and controlling” phase between the executing and closing
 UNIT-II
stages. Each step plays a crucial role in making sure the project has the best
chance of achieving its goals.
The project management lifecycle provides projects with structure and
tools to ensure they have the best chance of being successful. As a project
manager, it is a process you will want to know well.

Life cycle phases consist of various separated modules with defined

functionalities. Life cycle phases describe the various phases of project
management. Life cycle phases are mainly divided into two broad
categories:
2.2.1. Engineering Phase: Less predictable but smaller teams doing design
and production activities. This stage is decomposed into two distinct
Phases inception and elaboration.
2.2.1.1 Inception Phase – The inception Phase involves
establishing goals and gathering the requirements needed for the software
development. It involves cost estimation and identifying the risk factors. In
the inception phase, we mainly work on the scope of the project and
architecture. Feasibility analysis is also an important part of the inception
phase.
2.2.2.2 Elaboration Phase – The elaboration phase involves in-
depth evaluation and study as well as establishing a strong architecture and
infrastructure. In the elaboration phase, we work on the efficiency of our
architecture. In this phase, we also analyze use cases and other software
diagrams. We reduce the risk to a certain extent and a preliminary user
module is prepared in this phase.

2.2.2. Production Phase More predictable but larger teams doing

construction, test, and deployment activities. This stage is also decomposed
into two distinct Phases construction and transition.
2.2.2.1 Construction Phase – In the construction phase, we
perform the implementation of our software. In this phase, we minimize
the risk and eliminate it. All the features and components are integrated
into an application. In this phase, we perform strict testing, and process
optimization is done. We minimize the development cost and work to
improve its efficiency. The construction phase mainly focuses on the
implementation and testing of our software.
2.2.2.2 Transition Phase – In the Transition phase, we perform
strict testing mainly beta testing and deployment of software or project.
After receiving the feedback from the user, we performed some changes in
our software to make it more efficacious. In this phase, the developer
works on a project with a user’s view to make the software more
supportable and user-friendly.
 UNIT-II
Table No. 2.2.1 The Two Stages of the Life Cycle: Engineering and Production
Stages
S no. Life Cycle Engineering Stage Emphasis Production Stage
Aspects Emphasis
1 Risk Reduction Schedule, Technical, Feasibility Cost
2 Products Architecture baseline Product release baseline
3 Activities Analysis, Design, Planning Implementation, Testing
4 Assessment Demonstration, Inspection, Analysis Testing
5 Economics Resolving diseconomies of scale Exploiting Economies of
scale
6 Management Planning Operations

These four phases of lifecycle process are loosely mapped to the conceptual framework of the
spiral model is as shown in the following table:

Table No.2.2.2 Four phases of life cycle

 In the above figure the size of the spiral corresponds to the inactivity of the
project with respect to the breadth and depth of the artifacts that have been
developed.
 This inertia manifests itself in maintaining artifact consistency, regression
testing, documentation, quality analyses, and configuration control.
 Increased inertia may have little, or at least very straightforward, impact on
changing any given discrete component or activity.
 However, the reaction time for accommodating major architectural changes,
major requirements changes, major planning shifts, or major organizational
perturbations clearly increases in subsequent phases.

Ref 1: Software Project Management by Walker Royce

Ref 2: https://www.geeksforgeeks.org/phases-of-project-management
 UNIT-II

2.3. Inception

In the first phase of software project management, IT organizations identify the

requirements, product features, risks, constraints, and scope of the development project.
Your team will devise a plan to meet the intended budget and support the technical and
business case of the end-product. This is the starting period of your project when you
should demonstrate the undertaking has value and is feasible. This stage incorporates
making a business case, to legitimize the requirement for the undertaking, and an
achievable study to show that it very well may be executed within a sensible time and
cost. This is likewise an opportunity to make a task contract, a record that sets out
precisely the thing the venture will convey.
 UNIT-II
 Documentation: Each project has documentation that should be finished before the
undertaking can start vigorously. For instance, there’s a business case, which records
the reasons why the undertaking is required and what the profit from speculation will
be. There’s likewise an attainability study to decide whether the undertaking is even
conceivable with thought to an association’s assets. The venture sanction gives an
overall outline of the task by characterizing the undertaking’s goals, benefits,
partners, imperatives, and suspicions, among different angles.

 Undertaking a feasibility study: Identify the essential issue your task will tackle
and whether your venture will convey an answer for that issue.

 Recognizing extension: Define the profundity and broadness of the undertaking.

 Assemble of the team: You need resources to execute any project. Before you can
make a project schedule, you need to create a project team with the skill sets and
experience that the project demands.

 Recognizing expectations: Define the product or administration to provide.

 Recognizing project partners: Figure out whom the venture influences and what
their requirements might be.

 Building up a business case: Use the above standards to think about the possible
expenses and advantages of the task to decide whether it pushes ahead.

 Building up an explanation of work: Document the undertaking’s goals,

extensions, and expectations that you have distinguished already as a working
understanding between the venture proprietor and those chipping away at the task.
The main goal of this phase is to achieve agreement among stakeholders on the
life-cycle objectives for the project.

Primary Objectives:
1) Establishing the project’s scope and boundary conditions.
2) Distinguishing the critical use cases of the system and the primary scenarios of
operation.
3) Demonstrating at least one candidate architecture against some of the primary
scenarios.
4) Estimating cost and schedule for the entire project.
5) Estimating potential risks.

Essential Activities:
1) Formulating the scope of the project.
 UNIT-II
2) Synthesizing the architecture.
3) Planning and preparing a business case.

Fig. No. 2.3.1 Inception

Ref 1: Software Project Management by Walker Royce

Ref 2: https://www.geeksforgeeks.org/phases-of-project-management/

2.4. Elaboration
In the second phase of software project management, you will complete and
validate the project plan and the architectural design. Then, identify any risks and
manage them accordingly. You’ve already agreed to the project vision and requirements,
so you’ll follow these tasks to achieve the project goals:
 Managing the risk. Understand how risk can be mitigated and managed.
Develop a playbook that covers probable risk areas and best-practice
response guidelines.
 Modeling & design. Visualize or simulate the system and environment
models of the technology stack, product architecture, and the SDLC
 UNIT-II
framework. The model considers all interactions between the system
components and appropriate external factors. Some of the popular SDLC
models include DevOps and Agile.
 Executing the project plan. Assign the roles and responsibilities for teams,
managers, and employees. Identify the required tools and services, and
provision them through a systematic governance framework.
 It is the most critical phase among the four phases.
 Depending upon the scope, size, risk, and freshness of the project, an
executable architecture prototype is built in one or more iterations.
 At most of the time the process may accommodate changes, the elaboration
phase activities must ensure that the architecture, requirements, and plans are
stable. And also the cost and schedule for the completion of the development
can be predicted within an acceptable range.
Primary Objectives
1. Base lining the architecture as rapidly as practical.
2. Base lining the vision.
3. Base lining a high-reliability plan for the
construction phase
4. Demonstrating that the baseline architecture will
support the
vision at a reasonable cost in a reasonable time.

Essential Activities
1 Elaborating the vision.
2 Elaborating the process and infrastructure.
3 Elaborating the architecture and selecting components.

Ref 1: Software Project Management by Walker Royce

Ref 2: https://www.geeksforgeeks.org/phases-of-project-management/

2.5 Construction
Managing resource provision
The third phase of software project management deals directly with the development
process. Monitor the progress of the development process against the defined
requirements and user expectations—make sure you’re staying on track for timelines
and expectations. Here, you might also provide employees supporting the project
with any necessary training, education, and support.
Key tasks followed during this phase include:
 UNIT-II
Designing the details. Describe how the documentation and architectural design
guides the development of software product components, builds, and features.
Explain the design patterns and follow them systematically.
Managing the quality. Identify the activities and the qualitative and quantitative
measures of software quality. Understand which metrics can be analyzed through
the software testing process to achieve high quality as intended.

Fig. No. 2.5.1 Construction Phase

During this phase all the remaining components and application features are
integrated into the application and all features are thoroughly tested. Newly
developed software is integrated where ever required. If it is a big project then
parallel construction increments are generated.

Primary Objectives
 Minimizing development costs.
 Achieving adequate quality as rapidly as practical.
 Achieving useful version (alpha, beta, and other releases) as rapidly as practical

Essential Activities
 Resource management, control, and process optimization.
 Complete component development and testing evaluation
criteria
 Assessment of product release criteria of the vision

Ref 1: Software Project Management by Walker Royce

Ref 2: https://www.geeksforgeeks.org/phases-of-project-management

2.6 Training phase

Releasing the product

In the final phase of the software project management, you’ll validate the final product
build against all technical and business requirements. You’ll complete the necessary
artifacts and the development team must prepare for the next iteration of the software
 UNIT-II
development cycle. You’ve already learned lessons from the first iteration, so apply these
to support continual improvement. Depending on the SDLC methodology you’re using,
you may release specific feature updates, components, or the complete product to end-
users.

Key tasks in the Transition phase include:

 Evolving. Describing how software development teams can transition to the next
iteration of the project. The iteration may produce a software build or a functioning feature
component, depending on the chosen SDLC framework.
 Seeking feedback. Identify the opportunities and challenges you experienced
during prior iterations and apply the lessons in the next iteration of the SDLC. The DevOps
feedback loop is perfect for this. For organizations following Agile and DevOps SDLC
frameworks, the feedback process is an integral element of the SDLC process. In subsequent
iterations of the development process, there may be limited but ongoing improvements and
changes in requirements. Provisions for such changes should already be included during the
first three phases of the software project management model.
 Closing the project. Success is measured following project completion. Project
managers are required to identify project performance and determine whether the project
goals were achieved within the agreed scope and constraints (time, cost, quality, other). Then,
document the project closure and conduct a and post-implementation reviews. Account for,
reallocate, or retrieve unused resources for future project implementations. Finally, debrief
the relevant teams on the project performance and evolution.

Transition Phase
Whenever a project is grown-up completely and to be deployed in the end-user
domain this phase is called transition phase. It includes the following activities:
1) Beta testing to validate the new system against user expectations
2) Beta testing and parallel operation relative to a legacy system it is replacing
3) Conversion of operational databases
4) Training of users and maintainers

Primary Objectives
1) Achieving user self-supportability
2) Achieving stakeholder concurrence
3) Achieving final product baseline as rapidly and cost-effectively as practical

Essential Activities
1) Synchronization and integration of concurrent construction increments into
consistent deployment baselines
2) Deployment-specific engineering
3) Assessment of deployment baselines against the complete vision and
acceptance criteria in the requirement set.
 UNIT-II

Ref 1: Software Project Management by Walker Royce

Ref 2: https://www.geeksforgeeks.org/phases-of-project-management

2.7 Artifacts of the Process-

Artifact is highly associated and related to specific methods or processes of

development. Methods or processes can be project plans, business cases, or risk
assessments. Distinct gathering and collections of detailed information are generally
organized and incorporated into artifact sets. A set generally represents complete aspect
of system. This is simply done to make development and establishment of complete
software system in manageable manner.
 UNIT-II
Conventional software projects focused on the sequential development of software
artifacts: build the requirements, construct a design model traceable to the
requirements, build an implementation traceable to the design model, and
compile and test the implementation for deployment. This process can work for
small-scale, purely custom developments in which the design representation,
implementation representation, and deployment representation are closely aligned.
For example, a single program that is intended to run on a single computer of a single
type and is composed entirely of special-purpose custom components can be constructed
with straightforward traceability among all the representations.
 Conventional s/w projects focused on the sequential development of
s/w artifacts:
 Build the requirements
 Construct a design model traceable to the requirements
 Compile and test the implementation for deployment.
 This process can work for small-scale, purely custom developments
in which the design representation, implementation representation
and deployment representation are closely aligned.
 This approach is doesn't work for most of today’s s/w systems why
because of having complexity and are composed of numerous
components some are custom, some reused, some commercial
products.

Fig. No. 2.7.1 Types of Artifacts

Ref 1: Software Project Management by Walker Royce

Ref 2: https://www.geeksforgeeks.org/phases-of-project-management
2.8 The artifact sets

To make the development of a complete software system manageable, distinct collections

of information are organized into artifact sets. Each set comprises related artifacts that
are persistent and in a uniform representation format (such as English text, C++, Visual
Basic, Java, a standard document template, a standard spreadsheet template, or a UML
model). While a set represents a complete aspect of the system, an artifact represents
cohesive information that typically is developed and reviewed as a single entity. In any
given organization, project, or system, some of these artifacts and even some sets-
 UNIT-II
may be trivial or unnecessary. In general, however, some information needs to be
captured in each set to satisfy all stakeholders.

Life-cycle software artifacts are organized into five distinct sets that are roughly
partitioned by the underlying language of the set: management (ad hoc textual
formats), requirements.(organized text and models of the problem space), design
(models of the solution space), implementation (human-readable programming language
and associated source files), and deployment (machine-process able languages and
associated files).The emergence of rigorous and more powerful engineering notations
for requirements and design artifacts that support architecture-first development was
a major technology advance. In particular, the Unified Modeling Language has evolved
into a suitable representation format, namely visual models with a well-specified
syntax and semantics for requirements and design artifacts. Visual modeling using
UML is a primitive notation for early life-cycle artifacts.

Artifacts of the life-cycle of software are generally organized and divided into two sets
i.e., Management set and Engineering set. These sets are further divided or partitioned by
underlying language of set. These artifact sets are shown below in diagram :

Fig. No. 2.8.1

Ref 1: Software Project Management by Walker Royce

Ref 2: https://www.geeksforgeeks.org/artifact-software-development

2.8 Management artifacts

The management set captures the artifacts associated with process planning and execution.
These artifacts use ad hoc notations, including text, graphics, or whatever representation is
required to capture the "contracts" among project personnel (project management,
architects, developers, testers, marketers, administrators), among stakeholders (funding
authority, user, software project manager, organization manager, regulatory agency), and
between project personnel and stakeholders. Specific artifacts included in this set are the
 UNIT-II
work breakdown structure (activity breakdown and finan cial tracking mechanism), the
business case (cost, schedule, profit expectations), the release specifications (scope, plan,
objectives for release baselines), the software development plan (project process
instance), the release descriptions (results of release baselines), the status assessments
(periodic snapshots of project progress), the software change orders (descriptions of discrete
baseline changes), the deployment documents (cutover plan, training course, sales
rollout kit), and the environment (hardware and software tools, process automation,
documentation, training collateral necessary to support the execution of the process described
in the software development plan and the production of the engineering artifacts).
Management set artifacts are evaluated, assessed, and measured through a combination of
the following:

Relevant stakeholder review

 Analysis of changes between the current version of the artifact and previous
versions (management trends and project performance changes in terms of cost,
schedule, and quality)
 Major milestone demonstrations of the balance among all artifacts and, in particular, the
accuracy of the business case and vision artifacts

2.8.1 Some types of Management Artifacts :

2.8.1.1 Business Case
The business case generally provides justification for initiating project,
task, program, or portfolio. This justification is simply based on the estimated
cost of the development and implementation against risks and issues and
evaluated business benefits and savings to be gained.
It is created and developed during early stages of project and simply explains
why, what, how, and who necessary to decide whether if it is worthwhile
continuing or initiating project. A business case is good if describes problems and
issues, determines all the possible options to address it, and gives permission to
the decision-makers to decide which of the course of the action will be best for
organization. The main goal of business case to convert vision into economic
teams so that organization can develop exact and accurate ROI (Return on
Investment) assessment.

2.8.1.2 Software Development Plan (SDP)

Software development plan aims to lay out whole plan which is necessary and
required in order to develop, modify, and upgrade software system. It is ready-
made solution for managers for software development. It provides acquirer
insight and tool for checking processes that have to be followed for
development of software.
It simply indicates two things: Periodic updating and understanding and
approval by managers and practitioners alike.

2.8.1.3 Work Breakdown Structure (WBS)

 UNIT-II

Work breakdown structure is deliverable-oriented breakdown of project into

component of small size. WBS is created and developed to establish similar
understanding of scope of project.
It is hierarchical tree structure that layout project and simply breaks it down into
smaller and manageable portions or components. It is vehicle for budgeting and
collecting or gathering costs.

2.8.1.4 Software Change Order Database

For Iterative development process, primary task to manage change. A project can
iterate (perform repeatedly) more productively with large change freedom. This
change of freedom has been gained due to automation.

2.8.1.5 Release Specification

Release specifications generally mean tests and limit against that which raw
material, intermediate and end product are accurately measured just before use or
release.
Two important forms of requirements in release specifications are Vision
Statement (captures contract between development group and buyer) and
Evaluation Criteria (management-oriented requirements that can be showed and
represented using use cases, use cases realizations, etc).

2.8.1.6 Deployment
The deployment includes numerous subsets of documents for transitioning
product into operational status. It is simply application code as it runs on
production: built, bundled, compiled, etc. It is process of putting artifact where it
is necessary and performing any tasks it needs so as to achieve its purpose. It can
also include computer system operations manuals, software installations manuals,
plans and procedures for cutover, etc.

2.8.1.7 Environment –
Automation of development process needs and important to get supported by
robust development environment. It must include following points :
 Management of requirements.
 Visual Modeling.
 Automation of document.
 Automated regression testing.
 Tools of host and target programming.
 Tracking of features and defects or errors
Ref 1: https://www.geeksforgeeks.org/management-artifacts-and-its-types

2.9 Engineering artifacts

The engineering sets consist of the requirements set, the design set, the
implementation set, and the deployment set. The primary mechanism for
evaluating the evolving quality of each artifact set is the transitioning of
information from set to set, thereby maintaining a balance of understanding
 UNIT-II
among the requirements, design, implementation, and deployment artifacts.
Each of these components of the system description evolves over time.

2.9.1 Requirements Set

Structured text is used for the vision statement, which documents the
project scope that supports the contract between the funding authority and
the project team. Ad hoc formats may also be used for supplementary
specifications (such as regulatory requirements) and user mockups or other
prototypes that capture requirements. UML notation is used for engineering
representations of requirements models (use case models, domain models). The
requirements set are the primary engineering context for evaluating the other
three engineering artifact sets and is the basis for test cases.
Requirements artifacts are evaluated, assessed, and measured through a
combination of the following:
 Analysis of consistency with the release specifications of the
Management set.
 Analysis of consistency between the vision and the requirements
Models.
 Mapping against the design, implementation, and deployment sets
to evaluate the consistency and completeness and the semantic
balance between information in the different sets
 Analysis of changes between the current version of requirements
artifacts and previous versions (scrap, rework, and defect
elimination trends) Subjective review of other dimensions of
quality
2.9.2 Design Set
UML notation is used to engineer the design models for the solution. The
design set contains varying levels of abstraction that represent the components
of the solution space (their identities, attributes, static relationships, dynamic
interactions). The design models include enough structural and behavioral
information to ascertain a bill of materials (quantity and specification of
primitive parts and materials, labor, and other direct costs). Design model
information can be straightforwardly and, in many cases, automatically
translated into a subset of the implementation and deployment set artifacts.
Specific design set artifacts includes the design model, the test model, and the
software architecture description (an extract of information from the design
model that is pertinent to describing architecture).
The design set is evaluated, assessed, and measured through a combination of
the following:
• Analysis of the internal consistency and quality of the design model
• Analysis of consistency with the requirements models
• Translation into implementation and deployment sets and notations (for
example, traceability, source code generation, compilation, linking) to
evaluate the consistency and completeness and the semantic balance
between information in the sets
 UNIT-II
• Analysis of changes between the current version of the design model
and previous versions (scrap, rework, and defect elimination trends)
• Subjective review of other dimensions of quality
Because the level of automated analysis available on design models is currently
limited, human analysis must be relied on. This situation should change over the next
few years with the maturity of design model analysis tools that support metrics
collection, complexity analysis, style analysis, heuristic analysis, and consistency
analysis.

2.9.3 Implementation Set

The implementation set includes source code (programming language

notations) that represents the tangible implementations of components (their
form, interface, and dependency relationships) and any executables
necessary for stand-alone testing of components. These executables are the
primitive parts needed to construct the end product, including custom
components, application programming interfaces (APls) of commercial
components, and APis or reusable or legacy components in a programming
language source (such as Ada 95, C++, Visual Basic, Java, or Assembly).
Implementation set artifacts can also be translated (compiled and linked) into a
subset of
The deployment set (end-target executables). Specific artifacts include self-
documenting product source code baselines and associated files (compilation
scripts, configuration management infrastructure, data files), self-
documenting test source code baselines and associated files (input test data
files, test result files), stand-alone component executables, and component test
driver executables.
Implementation sets are human-readable formats that are evaluated, assessed,
and measured through a combination of the following:
• Analysis of consistency with the design models
• Translation into deployment set notations (for example, compilation
and linking) to evaluate the consistency and completeness among
artifact sets
• Assessment of component source or executable files against relevant
evaluation criteria through inspection, analysis, demonstration, or testing.
• Execution of stand-alone component test cases that automatically
compare expected results with actual results
• Analysis of changes between the current version of the implementation
set and previous versions (scrap, rework, and defect elimination trends)
2.9.4 Deployment Set
The deployment set includes user deliverables and machine language
notations, executable software, and the build scripts, installation scripts,
and executable target specific data necessary to use the product in its target
environment. These machine language notations represent the product
 UNIT-II
components in the target form intended for distribution to users. Deployment
set information can be installed, executed against scenarios of use (tested),
and dynamically reconfigured to support the features required in the end
product. Specific artifacts include executable baselines and associated run-time
files, and the user manual.
Deployment sets are evaluated, assessed, and measured through a combination
of the following:
• Testing against the usage scenarios and quality attributes defined in the
requirements set to evaluate the consistency and completeness and the
semantic balance between information in the two sets
• Testing the partitioning, replication, and allocation strategies in mapping
components of the implementation set to physical resources of the deployment
system (platform type, number, network topology)
• Testing against the defined usage scenarios in the user manual such as
installation, user-oriented dynamic reconfiguration, mainstream usage, and
anomaly management
• Analysis of changes between the current version of the deployment set and
previous versions (defect elimination trends, performance changes)
• Subjective review of other dimensions of quality
The rationale for selecting the management, requirements, design,
implementation, and deployment sets was not scientific. The goal was to
optimize presentation of the process activities, artifacts, and objectives. Some
of the rationale that resulted in this conceptual framework is described next.
Although there are several minor exceptions to these generalizations, they are
useful in understanding the overall artifact sets.

Ref 1: Software Project Management by Walker Royce

Ref 2: https://www.geeksforgeeks.org/engineering-artifacts

2.10 Pragmatics artifacts

 People want to review information but don't understand the language of
the artifact. Many interested reviewers of a particular artifact will resist
having to learn the engineering language in which the artifact is written.
 UNIT-II
It is not uncommon to find people (such as veteran software managers,
veteran quality assurance specialists, or an auditing authority from a
regulatory agency) who react as follows: "I'm not going to learn UML,
but I want to review the design of this software, so give me a separate
description such as some flowcharts and text that I can understand."

 People want to review the information but don't have access to the
tools. It is not very common for the development organization to be
fully tooled; it is extremely rare that the/other stakeholders have any
Capability to review the engineering artifacts on-line. Consequently,
organizations are forced to exchange paper documents. Standardized
formats (such as UML, spreadsheets, Visual Basic, C++, and Ada
95), visualization tools, and the Web are rapidly making it
economically feasible for all stakeholders to exchange information
electronically

 Human-readable engineering artifacts should use rigorous notations that

are complete, consistent, and used in a self-documenting manner.
Properly spelled English words should be used for all identifiers and
descriptions. Acronyms and abbreviations should be used only where
they are well accepted jargon in the context of the component's usage.
Readability should be emphasized and the use of proper English words
should be required in all engineering artifacts. This practice enables
understandable representations, browse able formats (paperless review),
more-rigorous notations, and reduced error rates.

 Useful documentation is self-defining: It is documentation that gets used.

 Paper is tangible; electronic artifacts are too easy to change. On-line

and Web-based artifacts can be changed easily and are viewed with
more skepticism because of their inherent volatility.

Ref 1: Software Project Management by Walker Royce

Ref 2: https://www.geeksforgeeks.org/engineering-artifacts

2.11 Model based software architectures

Software architecture is the central design problem of a complex
software system, in the same way that architecture is the central design
problem of a complex skyscraper. However, a software architecture has
 UNIT-II
several additional dimensions of complexity. In contrast to the architecture of a
large building, the critical performance attributes and features of a complex
software. System cannot be described through stable laws of physics. They are
not governed by any well-accepted form of mathematics. Thus, software
architects have no irrefutable first principles. There are many heuristics and
fuzzy guidelines, but the fundamental measures of goodness are highly
situation dependent. Lacking established theory, software architects must rely
on some form of experimentation in formulating software architectures. This
is one of the main reasons for transitioning to an iterative process, in which
early activities emphasize and promote architecture evolution through
prototyping and demonstration.
2.11.1 ARCHITECTURE: A MANAGEMENT PERSPECTIVE
The most critical technical product of a software project is its architecture:
the infrastructure, control, and data interfaces that permit software
components to cooperate as a system and software designers to cooperate
efficiently as a team. Establishing accurate and precise communications
among teams of people is a timeless problem in any organization. When the
communications media include multiple languages and intergroup literacy
varies, the communications problem can become extremely complex and even
unsolvable. If a software development team is to be successful, the
interproject communications, as captured in the software architecture, must be
both accurate and precise.From a management perspective, there are
three different aspects of an architecture.

1. An architecture (the intangible design concept) is the design of a

software system, as opposed to the design of a component. This includes all
engineering necessary to specify a complete bill of materials. Significant
make/ buy decisions are resolved, and all custom components are
elaborated so that individual component costs and construction/assembly
costs can be determined with confidence.
2. An architecture baseline (the tangible artifacts) is a slice of
information across the engineering artifact sets sufficient to satisfy all
stakeholders that the vision (function and quality) can be achieved within
the parameters of the business case (cost, profit, time, technology, people).
3. An architecture description (a human-readable representation of an
architecture, which is one of the components of an architecture baseline) is an
organized subset of information extracted from the design set model(s). It
includes the additional ad hoc notation (text and graphics) necessary to clarify
the information in the models. The architecture description communicates how
the intangible concept is realized in the tangible artifacts.

2.11.2 ARCHITECTURE: A TECHNICAL PERSPECTIVE

Although software architecture has been discussed at length over the past
decade, convergence on definitions, terminology, and principles has been
lacking. The following discussion draws generally on the foundations of
 UNIT-II
architecture developed at Rational Software Corporation and particularly
on Philippe Kruchten's concepts of software architecture.
Software architecture encompasses the structure of software systems (the
selection of elements and the composition of elements into progressively
larger subsystems), their behavior (collaborations among elements), and the
patterns that guide these elements, their collaborations, and their composition.
The context of software architecture structure, behavior, and patterns must
include functionality, performance, resilience, comprehensibility,
economic trade-offs, technology constraints, and aesthetic concerns.
An architecture framework is defined in terms of views that are abstractions of
the UML models in the design set. The design model includes the full
breadth and depth of information. An architecture view is an abstraction of the
design model; it contains only the architecturally significant information.
Most real-world systems require four views: design, process, component,
and deployment. The purposes of these views are as follows:
• Design: describes architecturally significant structures and functions of the
design model
• Process: describes concurrency and control thread relationships among the
design, component, and deployment views
• Component: describes the structure of the implementation set
• Deployment: describes the structure of the deployment set

Fig No. 2.11.1 Technical Perspective

Ref 1: Software Project Management by Walker Royce
Ref 2: https://www.geeksforgeeks.org/engineering-artifacts
Ref 3 : https://www.slideshare.net/Munazza-Mah-Jabeen/model-based-software-architectures

2.12 Workflows of the process

The term workflow means a thread of cohesive and mostly sequential activities.
In most of the cases a process is a sequence of activities why because of easy to
understand, represent, plan and conduct. But the simplistic activity sequences are not
 UNIT-II
realistic why because it includes many teams, making progress on many artifacts that
must be synchronized, cross-checked, homogenized, merged and integrated. In order to
manage complex software’s the workflow of the software process is to be changed that
is distributed. Modern software process avoids the life-cycle phases like inception,
elaboration, construction and transition. It tells only the state of the project rather than a
sequence of activities in each phase. The activities of the process are organized in to
seven major workflows:

1) Management
2) Environment
3) Requirements
4) Design
5) Implementation
6) Assessment
7) Deployment

There are seven top-level workflows:

1. Management workflow: controlling the process and ensuring win conditions for all
stakeholders.
2. Environment workflow: automating the process and evolving the maintenance
environment.
3. Requirements workflow: analyzing the problem space and evolving the
requirements artifacts.
4 .Design workflow: modeling the solution and evolving the architecture and design
artifacts.
5. Implementation workflow: programming the components and evolving the
implementation and deployment artifacts.
6. Assessment workflow: assessing the trends in process and product quality.
7. Deployment workflow: transitioning the end products to the user.

Table No.2.12.1 The ARTIFACTS and life-cycle emphases associated with each workflow
 UNIT-II
WORKFLOW ARTIFACTS LIFE CYCLE PHASE EMPHASIS

Management Business case Inception: Prepare business case and vision

Software development plan Elaboration: Plan development
Status assessments
Construction: Monitor and control
Vision
Work breakdown structure development
Transition: Monitor and control deployment

Environment Environment Inception: Define development

Software change environment and change management
order Database infrastructure
Elaboration: Install development
environment and establish change
management database
Construction: Maintain development
Environment and
software change order database
Transition: Transition maintenance
environment and software change
order database
Requirements set Inception: Define operational concept
Release specifications Elaboration: Define architecture
Requirements Vision objectives
Construction: Define iteration objectives
Transition: Refine release objectives
Design Design set Inception: Formulate architecture concept
Elaboration: Achieve architecture
baseline
Construction: Design Components
Transition: Refine architecture and
components
Implementation Architecture description Inception: Support architecture
prototypes
Elaboration: Produce architecture
baseline
Construction: Produce complete
Component
Transition: Maintain components
Assessment Implementation Set Inception: Assess plans, vision,
prototypes Elaboration: Assess
architecture Construction: Assess internal
releases
Transition: Assess producer releases
Deployment Deployment Set Release Inception: Analyze user community
specifications Release Elaboration: Design user manual
Descriptions Construction: Prepare transition materials
User manuals Deployment Transition: Transition product to user
set Deployment Set

Ref 1: Software Project Management by Walker Royce

 UNIT-II
Ref 2: https://www.geeksforgeeks.org/engineering-artifacts

2.13 Checkpoints of the process.

I
It is always important to have visible mile• stones in the life cycle where various
stakeholders meet, face to face, to discuss progress and plans. The purpose of these events
is not only to demonstrate how well a project is per• forming but also to achieve the
following:
• Synchronize stakeholder expectations and achieve concurrence on three evolving
perspectives: the requirements, the design, and the plan
• Synchronize related artifacts into a con- sistent and balanced state
• Identify the important risks, issues, and out-of-tolerance conditions
Perform a global assessment for the whole life cycle, not just the current situation of an
individual perspective or intermediate product
Milestones must have well-defined expectations and provide tangible results. This does
not preclude the renegotiation of the milestone's objectives once the project has gained
further understanding of the trade-offs among the requirements, the design, and the plan.
Three types of joint management reviews are conducted throughout the process:
1. Major milestones. These systemwide events are held at the end of each
development phase. They provide visibility to systemwide issues, synchronize the
management and engineering perspectives, and verify that the aims of the phase have been
achieved. The most important major milestone is usually the event that transitions the
project from the elaboration phase into the construction phase. These are the system wide
events are held at the end of each development phase. They provide visibility to system
wide issues. Major milestones at the end of each phase use formal, stakeholder- approved
evaluation criteria and release descriptions. In an iterative model, the major milestones are
used to achieve concurrence among all stakeholders on the current state of the project.
Different stakeholders have different concerns:
Customers: schedule and budget estimates, feasibility, risk assessment, requirements
understanding, progress, product line compatibility.
Users: consistency with requirements and usage scenarios, potential for accommodating
growth, quality attributes.
Architects and systems engineers: product line compatibility, requirements changes, tradeoff
analyses, completeness and consistency, balance among risk, quality and usability.
Developers: Sufficiency of requirements detail and usage scenario descriptions, frameworks
for component selection or development, resolution of development risk, product line
compatibility, sufficiency of the development environment.
Maintainers: sufficiency of product and documentation artifacts, understandability,
interoperability with existing systems, sufficiency of maintenance environment.
Others: regulatory agencies, independent verification and validation contractors, venture
capital investors, subcontractors, associate contractors, and sales and marketing teams.
2. Minor milestones. These iteration-focused events are conducted to review the
content of an iteration in detail and to authorize continued work. The format and content of
minor milestones are highly dependent on the project and the organizational culture. These
 UNIT-II
are the iteration-focused events are conducted to review the content of an iteration in detail
and to authorize continued work. Minor milestones capture two artifacts: a release
specification and a release description. Minor milestones use informal, development-team-
controlled versions of these artifacts.
The number of iteration-specific, informal milestones needed depends on the content and
length of the iteration.
Iterations which have one-month to six-month duration have only two milestones are
needed: the iteration readiness review and iteration assessment review. For longer iterations
some other intermediate review points are added.
All iterations are not created equal . An iteration take different forms and priorities,
depending on where the project is in the life cycle.
Early iterations focus on analysis and design. Later iterations focus on completeness,
consistency, usability and change management.
Iteration Readiness Review: This informal milestone is conducted at the start of each
iteration to review the detailed iteration plan and the evaluation criteria that have been
allocated to this iteration.
Iteration Assessment Review: This informal milestone is conducted at the end of each
iteration to assess the degree to which the iteration achieved its objectives and to review
iteration results, test results, to determine amount of rework to be done, to review impact of
the iteration results on the plan for subsequent iterations.
3. Status assessments. These periodic events provide management with frequent and
regular insight into the progress being made Periodic status assessments are important for
focusing continuous attention on the evolving health of the project and its dynamic priorities.
These are periodic events provide management with frequent and regular insight into the
progress being made. These are management reviews conducted at regular intervals
(monthly, quarterly) to address progress and quality of project and maintain open
communication among all stakeholders. The main objective of this assessment is to
synchronize all Stakeholders expectations and also serve as project snapshots. Also provide,
A mechanism for openly addressing, communicating, and resolving management issues,
technical issues, and project risks.
A mechanism for broadcast process, progress, quality trends, practices, and experience
information to and from all stakeholders in an open forum. Objective data derived directly
from on-going activities and evolving product configurations.

Ref 1: Software Project Management by Walker Royce

Ref 2: https://www.geeksforgeeks.org/engineering-artifacts
UNIT-II
UNIT-II