CE220.

01 Software Engineering
Assignment Group-2

1. Write 5 levels of SEI-CMM. (14CE006)

- A maturity level is a well-defined evolutionary plateau toward achieving a mature software
process. Each maturity level provides a layer in the foundation for continuous process
improvement.

1) Initial - At maturity level 1, processes are usually ad hoc and chaotic. The organization usually
does not provide a stable environment. Success in these organizations depends on the
competence and heroics of the people in the organization and not on the use of proven
processes. Maturity level 1 organizations often produce products and services that work;
however, they frequently exceed the budget and schedule of their projects.

2) Managed - At maturity level 2, an organization has achieved all the specific and generic

goals of the maturity level 2 process areas. At maturity level 2, requirements, processes, work
products, and services are managed. The status of the work products and the delivery of
services are visible to management at defined points. Commitments are established among
relevant stakeholders and are revised as needed. Work products are reviewed with
stakeholders and are controlled.

3) Defined - At maturity level 3, an organization has achieved all the specific and generic

goals of the process areas assigned to maturity levels 2. At maturity level 3, the standards,
process descriptions, and procedures for a project are tailored from the organization's set of
standard processes to suit a particular project or organizational unit. The organization's set of
standard processes includes the processes addressed at maturity level 2 and maturity level 3.
As a result, the processes that are performed across the organization are consistent except for
the differences allowed by the tailoring guidelines. Processes are typically described in more
detail and more rigorously than at maturity level 2. At maturity level 3, processes are managed
more proactively.

4) Quantitatively Managed - At maturity level 4, an organization has achieved all the specific

goals of the process areas assigned to maturity levels 2, 3, and 4 and the generic goals assigned
to maturity levels 2 and 3. Quantitative objectives for quality and process performance are
established and used as criteria in managing processes. Quantitative objectives are based on
the needs of the customer, end users, organization, and process implementers. Quality and
process performance are understood in statistical terms and are managed throughout the life
of the processes. For these processes, detailed measures of process performance are collected
and statistically analyzed. Special causes of process variation are identified and, where
appropriate, the sources of special causes are corrected to prevent future occurrences. A
critical distinction between maturity level 3 and maturity level 4 is the predictability of process
performance.

5) Optimizing - At maturity level 5, an organization has achieved all the specific goals of the
process areas assigned to maturity levels 2, 3, 4, and 5 and the generic goals assigned to
maturity levels 2 and 3. Processes are continually improved based on a quantitative
understanding of the common causes of variation inherent in processes. Maturity level 5
focuses on continually improving process performance through both incremental and
innovative technological improvements. Optimizing processes that are agile and innovative
depends on the participation of an empowered workforce aligned with the business values and
objectives of the organization. The organization's ability to rapidly respond to changes and
opportunities is enhanced by finding ways to accelerate and share learning. A critical distinction
between maturity level 4 and maturity level 5 is the type of process variation addressed.

2. What are “Umbrella Activities”? What activities does it include or encompass? (14CE008)
- Any standard software process model would primarily consist of two types of activities: A set
of framework activities, which are always applicable, regardless of the project type, and a set of
umbrella activities, which are the non SDLC activities that span across the entire software
development life cycle.
- Umbrella activities span all the stages of the SDLC. They are not specific to any particular life
cycle stage.
- Following are some Umbrella Activities:
 Software Project Management
  Formal Technical Reviews
 Software Quality Assurance
 Software Configuration Management
 Reusability Management
 Measurement
 Document Preparation And Production
 Risk Management

3. Write a short note on “Prototyping models”. (14CE011)

- Software prototyping is the development approach of activities during software development,
the creation of prototype. I.e. incomplete versions of the software program being developed.
 Basic principles:
 Not a standalone, complete development methodology but rather on approach to
handling selected parts of a larger more traditional development methodology.
 Attempts to reduce inherent project risk by breaking a project into smaller segments
and providing more case of change during the development process.
 User is involved throughout the development process, which increases the like hood of
the user acceptance of the final implementation.
 Small scale mockups of the system are developed following an iterative modification
process until the prototype evolves to meet the user’s requirement.
 While most prototypes are developed with the expectation that they will be declared, it
is possible in some cases to evolve from prototype to working system.
 A basic understanding of fundamental business problem is necessary to avoid solving
the wrong problem.

Prototyping Model
 Application:
 Software Prototyping is most useful in development of systems having high level of user
interactions such as online systems. Systems which need users to fill out forms or go
through various screens before data is processed can use prototyping very effectively to
give the exact look and feel even before the actual software is developed.
 Software that involves too much of data processing and most of the functionality is
internal with very little user interface does not usually benefit from prototyping.
Prototype development could be an extra overhead in such projects and may need lot of
extra efforts.

 Pros:
 Increased user involvement in the product even before implementation
 Since a working model of the system is displayed, the users get a better understanding
of the system being developed.
 Reduces time and cost as the defects can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily.
 Confusing or difficult functions can be identified.

 Cons:
 Risk of insufficient requirement analysis owing to too much dependency on prototype.
 Users may get confused in the prototypes and actual systems.
 Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
 Developers may try to reuse the existing prototypes to build the actual system, even
when it’s not technically feasible.
 The effort invested in building prototypes may be too much if not monitored properly
4. Write a note on waterfall model. (14CE009)
- The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-
sequential life cycle model.

 it is also referred as a linear sequential life cycle model.

 Considered as the traditional method of explaining the software development process in
software engineering.
 Waterfall model happens to clarify the process into a linear flow with a specified sequence
to let the users that further level is made progressive on completion of the previous one.
 Moreover this methodology also talks about the fact that going back to deal with the
changes is not possible.

 Life cycle includes the following phases:

1. Feasibility study: The main aim of feasibility study is determine whether it would be
financially and technically feasible to develop the project(product).
2. Requirement Analysis and specification: The aim of the Requirement Analysis and
specification phase is to understand the exact requirement of the
customer & document them properly.
3. Design: The goal of the design phase is to transform the requirements specified in the
SRS document into a structure that is suitable for implementation in some
programming language. Types: Traditional design approach & object oriented
approach.
4. Coding & Testing: The purpose of this phase is to translate the software design into
source code. Each component of the design is implemented as a program
module. The end product of this phase is a set of program modules that
have been individually tested.
5. Integration & System testing: During the integration and system testing phase the
modules are integrated in a planned manner. The different modules
making up a software are almost never integrated in one shot.
Integration is normally carried out incrementally over a number of
steps. The goal of system testing is to ensure that the developed system
conforms to its requirements laid out in the SRS document.
6. Maintenance: Maintenance of a typical software product require much more than the
effort necessary to develop the product itself. It provides: corrective
 maintenance, Perfective maintenance, Adaptive maintenance.

 Application:
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.

 Pros:
 Simple and easy to understand and use.
 Easy to manage due to the rigidity of the model. Each phase has specific deliverables
and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

 Cons:
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing. So risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow identifying
any technological or business bottleneck or challenges early.

5. Draw Use case diagram for “Online Library Management System”. (14CE007)

Use Cases:
1) Log in - Username, Password 6) Purchase Books - Credit Card, Debit Card
2) Register - Username, Password 7) Manage Books - Delete Books, Add Books
3) Read Book - Bookmark
4) Search Book - Title, Author Name, Category
5) Download Books - PDF, DOC

Sign Convention:
1) - Association
2) <<extend>> - Extends
3) <<include>> - Includes
4) - Generalization