Question

Q1

Compare and contrast between Waterfall model and Incremental development model.

Define Capability Maturity Model (CMM) and the different levels of CMM.

Compare between functional and non-functional requirements with example for each.

Distinguish among the fundamental architectural views proposed in Krutchen’s 4+ 1 model.

Define different types of UML diagram needed to represent the essential features of a system?

Answer 1

Compare and contrast between Waterfall model and Incremental development model.

Sr. No.	Key	Incremental Model	WaterFall Model
1	Definition	Incremental Model is the development model in which the entire model is divided into various sub development phase where corresponding testing phase for each development phase is practices. In other words we can say that for every stage in the development cycle, there is an associated testing phase and corresponding testing phase of the development phase is planned in parallel.	On other hand Waterfall model there is first development of the application and after which the different testing of application take place. In other words we can say that in WaterFall the complete process is divided into several phases among which one phase should be completed in order to reach the next phase and testing is almost at end phase of the development.
2	Type/Nature	As mentioned above that in Incremental Model the execution of the phases i.e., development and testing happens in a sequential manner so type of Incremental Model is Sequential/Parallel in nature.	On other hand WaterFall Model is a relatively linear sequential design approach as each phase should be completed in order to reach the next phase. So type of this model is Continuous in nature.
3	Testing and Validation	In Incremental Model each development phase get tested at its own level and hence no pending testing occurs in this model also if any validation requires to be implemented then it could be implemented at that phase.	On other hand in case of WaterFall Model the testing occurs after development is completed and thus if any missing validation is identified to be implemented then first that phase of development needs to be recognized and then that validation get implemented.
4	Cost and Complexity	As sequential phases need to be functional hence the cost is higher as compared to that of WaterFall Model also the complexity is more than WaterFall.	On other hand in WaterFall Model due to linear development only one phase of development is operational and hence cost and complexity is low as compared to that of Incremental Model.
5	Defects	In Incremental Model the probability of total number of defects in the development of application is low as testing is done in parallel to the development.	On other hand in WaterFall Model the probability of total number of defects in the development of application is high as testing is done post development.

Define Capability Maturity Model (CMM) and the different levels of CMM.

The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies an increasing series of levels of a software development organization. The higher the level, the better the software development process, hence reaching each level is an expensive and time-consuming process.

Levels of CMM

• Level One :Initial - The software process is characterized as inconsistent, and occasionally even chaotic. Defined processes and standard practices that exist are abandoned during a crisis. Success of the organization majorly depends on an individual effort, talent, and heroics. The heroes eventually move on to other organizations taking their wealth of knowledge or lessons learnt with them.

• Level Two: Repeatable - This level of Software Development Organization has a basic and consistent project management processes to track cost, schedule, and functionality. The process is in place to repeat the earlier successes on projects with similar applications. Program management is a key characteristic of a level two organization.

• Level Three: Defined - The software process for both management and engineering activities are documented, standardized, and integrated into a standard software process for the entire organization and all projects across the organization use an approved, tailored version of the organization's standard software process for developing,testing and maintaining the application.

• Level Four: Managed - Management can effectively control the software development effort using precise measurements. At this level, organization set a quantitative quality goal for both software process and software maintenance. At this maturity level, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable.

• Level Five: Optimizing - The Key characteristic of this level is focusing on continually improving process performance through both incremental and innovative technological improvements. At this level, changes to the process are to improve the process performance and at the same time maintaining statistical probability to achieve the established quantitative process-improvement objectives.

Compare between functional and non-functional requirements with example for each.

Requirements analysis is very critical process that enables the success of a system or software project to be assessed. Requirements are generally split into two types: Functional and Non-functional requirements.

Functional Requirements: These are the requirements that the end user specifically demands as basic facilities that the system should offer. All these functionalities need to be necessarily incorporated into the system as a part of the contract. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements.

Non-functional requirements: These are basically the quality constraints that the system must satisfy according to the project contract. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioral requirements.
They basically deal with issues like:

Following are the differences between Functional and Non Functional Requirements

FUNCTIONAL REQUIREMENTS	NON FUNCTIONAL REQUIREMENTS
A functional requirement defines a system or its component.	A non-functional requirement defines the quality attribute of a software system.
It specifies “What should the software system do?”	It places constraints on “How should the software system fulfill the functional requirements?”
Functional requirement is specified by User.	Non-functional requirement is specified by technical peoples e.g. Architect, Technical leaders and software developers.
It is mandatory.	It is not mandatory.
It is captured in use case.	It is captured as a quality attribute.
Defined at a component level.	Applied to a system as a whole.
Helps you verify the functionality of the software.	Helps you to verify the performance of the software.
Functional Testing like System, Integration, End to End, API testing, etc are done.	Non-Functional Testing like Performance, Stress, Usability, Security testing, etc are done.
Usually easy to define.	Usually more difficult to define.
Example 1) Authentication of user whenever he/she logs into the system. 2) System shutdown in case of a cyber attack. 3) A Verification email is sent to user whenever he/she registers for the first time on some software system.	Example 1) Emails should be sent with a latency of no greater than 12 hours from such an activity. 2) The processing of each request should be done within 10 seconds 3) The site should load in 3 seconds when the number of simultaneous users are > 10000

• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility

Distinguish among the fundamental architectural views proposed in Krutchen’s 4+ 1 model.

Architecture View Model

A model is a complete, basic, and simplified description of software architecture which is composed of multiple views from a particular perspective or viewpoint.

A view is a representation of an entire system from the perspective of a related set of concerns. It is used to describe the system from the viewpoint of different stakeholders such as end-users, developers, project managers, and testers.

4+1 View Model

The 4+1 View Model was designed by Philippe Kruchten to describe the architecture of a software–intensive system based on the use of multiple and concurrent views. It is a multiple view model that addresses different features and concerns of the system. It standardizes the software design documents and makes the design easy to understand by all stakeholders.

It is an architecture verification method for studying and documenting software architecture design and covers all the aspects of software architecture for all stakeholders. It provides four essential views −

• The logical view or conceptual view − It describes the object model of the design.

• The process view − It describes the activities of the system, captures the concurrency and synchronization aspects of the design.

• The physical view − It describes the mapping of software onto hardware and reflects its distributed aspect.

• The development view − It describes the static organization or structure of the software in its development of environment.

This view model can be extended by adding one more view called scenario view or use case view for end-users or customers of software systems. It is coherent with other four views and are utilized to illustrate the architecture serving as “plus one” view, (4+1) view model. The following figure describes the software architecture using five concurrent views (4+1) model.

Why is it called 4+1 instead of 5?

The use case view has a special significance as it details the high level requirement of a system while other views details — how those requirements are realized. When all other four views are completed, it’s effectively redundant. However, all other views would not be possible without it. The following image and table shows the 4+1 view in detail −

	Logical	Process	Development	Physical	Scenario
Description	Shows the component (Object) of system as well as their interaction	Shows the processes / Workflow rules of system and how those processes communicate, focuses on dynamic view of system	Gives building block views of system and describe static organization of the system modules	Shows the installation, configuration and deployment of software application	Shows the design is complete by performing validation and illustration
Viewer / Stake holder	End-User, Analysts and Designer	Integrators & developers	Programmer and software project managers	System engineer, operators, system administrators and system installers	All the views of their views and evaluators
Consider	Functional requirements	Non Functional Requirements	Software Module organization (Software management reuse, constraint of tools)	Nonfunctional requirement regarding to underlying hardware	System Consistency and validity
UML – Diagram	Class, State, Object, sequence, Communication Diagram	Activity Diagram	Component, Package diagram	Deployment diagram	Use case diagram

Define different types of UML diagram needed to represent the essential features of a system?

UML stands for Unified Modeling Language. It’s a rich language to model software solutions, application structures, system behavior and business processes. There are 14 UML diagram types to help you model these behaviors.

You can draw UML diagrams online using our software, or check out some UML diagram examples at our diagramming community.

List of UML Diagram Types

So what are the different UML diagram types? There are two main categories; structure diagrams and behavioral diagrams. Click on the links to learn more about a specific diagram type.

• Structure Diagrams
  • Class Diagram
  • Component Diagram
  • Deployment Diagram
  • Object Diagram
  • Package Diagram
  • Profile Diagram
  • Composite Structure Diagram
• Behavioral Diagrams
  • Use Case Diagram
  • Activity Diagram
  • State Machine Diagram
  • Sequence Diagram
  • Communication Diagram
  • Interaction Overview Diagram
  • Timing Diagram

Structure diagrams show the things in the modeled system. In a more technical term, they show different objects in a system. Behavioral diagrams show what should happen in a system. They describe how the objects interact with each other to create a functioning system.

Class Diagram

Class diagrams are the main building block of any object-oriented solution. It shows the classes in a system, attributes, and operations of each class and the relationship between each class.

In most modeling tools, a class has three parts. Name at the top, attributes in the middle and operations or methods at the bottom. In a large system with many related classes, classes are grouped together to create class diagrams. Different relationships between classes are shown by different types of arrows.

Below is an image of a class diagram. Follow the link below for more class diagram examples or get started instantly with our class diagram templates.

Click on the image to edit the above class diagram (opens in new window)

Get More UML Class Diagram Examples >>

Component Diagram

A component diagram displays the structural relationship of components of a software system. These are mostly used when working with complex systems with many components. Components communicate with each other using interfaces. The interfaces are linked using connectors. The image below shows a component diagram.

You can use this component diagram template by clicking on the image

Get More Component Diagram Templates >>

Deployment Diagram

A deployment diagram shows the hardware of your system and the software in that hardware. Deployment diagrams are useful when your software solution is deployed across multiple machines with each having a unique configuration. Below is an example deployment diagram.

Click on the image to use this deployment diagram as a template

Get More Deployment Diagram Templates >>

Object Diagram

Object Diagrams, sometimes referred to as Instance diagrams are very similar to class diagrams. Like class diagrams, they also show the relationship between objects but they use real-world examples.

They show how a system will look like at a given time. Because there is data available in the objects, they are used to explain complex relationships between objects.

Click on the image to use the object diagram as a template

Get More Object Diagram Templates >>

Package Diagram

As the name suggests, a package diagram shows the dependencies between different packages in a system. Check out this wiki article to learn more about the dependencies and elements found in package diagrams.

Profile Diagram

Profile diagram is a new diagram type introduced in UML 2. This is a diagram type that is very rarely used in any specification. For more profile diagram templates, visit our diagram community.

Composite Structure Diagram

Composite structure diagrams are used to show the internal structure of a class. Some of the common composite structure diagrams.

Use Case Diagram

As the most known diagram type of the behavioral UML types, Use case diagrams give a graphic overview of the actors involved in a system, different functions needed by those actors and how these different functions interact.

It’s a great starting point for any project discussion because you can easily identify the main actors involved and the main processes of the system. You can create use case diagrams using our tool and/or get started instantly using our use case templates.

Use Case Diagram Relationships Explained with examples

Click on the image to edit this template

Get More Use Case Diagram Examples >>

Activity Diagram

Activity diagrams represent workflows in a graphical way. They can be used to describe the business workflow or the operational workflow of any component in a system. Sometimes activity diagrams are used as an alternative to State machine diagrams. Check out this wiki article to learn about symbols and usage of activity diagrams. You can also refer this easy guide to activity diagrams.

Get More Activity Diagram Templates >>

State Machine Diagram

State machine diagrams are similar to activity diagrams, although notations and usage change a bit. They are sometimes known as state diagrams or state chart diagrams as well. These are very useful to describe the behavior of objects that act differently according to the state they are in at the moment. The State machine diagram below shows the basic states and actions.

State Machine diagram in UML, sometimes referred to as State or State chart diagram

Get More State Chart Diagram Examples >>

Sequence Diagram

Sequence diagrams in UML show how objects interact with each other and the order those interactions occur. It’s important to note that they show the interactions for a particular scenario. The processes are represented vertically and interactions are shown as arrows. This article explains the purpose and the basics of Sequence diagrams. Also, check out this complete Sequence Diagram Tutorial to learn more about sequence diagrams.

You can also instantly start drawing using our sequence diagram templates.

Sequence diagram drawn using Creately

Communication Diagram

In UML 1 they were called collaboration diagrams. Communication diagrams are similar to sequence diagrams, but the focus is on messages passed between objects. The same information can be represented using a sequence diagram and different objects. Click here to understand the differences using an example.

Interaction Overview Diagram

Interaction overview diagrams are very similar to activity diagrams. While activity diagrams show a sequence of processes, Interaction overview diagrams show a sequence of interaction diagrams.

They are a collection of interaction diagrams and the order they happen. As mentioned before, there are seven types of interaction diagrams, so any one of them can be a node in an interaction overview diagram. ( image – http://www.sa-depot.com/?page_id=645 )

Timing Diagram

Timing diagrams are very similar to sequence diagrams. They represent the behavior of objects in a given time frame. If it’s only one object, the diagram is straightforward. But, if there is more than one object is involved, a Timing diagram is used to show interactions between objects during that time frame. ( image – http://blog.tangcs.com/2008/01/10/uml-2-diagrams/ )

Click here to create your timing diagram.

Mentioned above are all the UML diagram types. UML offers many diagram types, and sometimes two diagrams can explain the same thing using different notations.