MVP vs POC vs prototype

•  Proof of Concept (POC)

Approach: Is the idea feasible? 

Implementation: Developing a POC is the quickest and most accurate way to validate or invalidate assumptions about your target users and app concept. 

Mobile App Prototype

Approach: How will this product function? 

Implementation: Mobile app prototyping is a form of user research to validate the strategic design direction of a product. A prototype is a preliminary visualization of a working product. Prototypes build an understanding of the mobile app’s look and feel, which helps test how customers use and react to the overall user experience (UX) design. Using a prototype for usability testing gives you enough time to make changes to critical design issues before the product reaches development and it’s too late (and too expensive) to make major changes to the UX. 

Minimum Viable Product (MVP)

Approach: What are the product’s core functionalities and value proposition? 

Implementation: A mobile app MVP is a minimal and usable form of your complete product to release and test in the app market. The MVP development method allows your team to learn how the product’s target users experience and respond to the app’s core business purpose. Using the insight and learnings from real users, you can allocate your time, effort and budget to areas that best satisfy your overall business objectives. Building an MVP is an iterative process designed to identify user pain points and determine the proper functionality to address those needs over time.

What is a POC? 

A POC will provide a definitive “yes” or “no” answer; either the concept is viable or it’s not.

The POC approach to product validation is about demonstrating functionality and verifying whether a particular idea is feasible for development.

Even if a POC proves that the concept won’t work, it’s possible to find other solutions from the same starting point. 

What is a Mobile App Prototype? 

While a POC shows a product concept can be done, a mobile app prototype shows how it will be done.

The purpose of a prototype is to communicate a product’s design and navigation flow to maximize the efficiency of development. Prototyping is a valuable exercise which results in visualization of how the app will function by demonstrating user flows and depicting a working design and layout. Naturally, there will be errors in a prototype, but discovering these errors during the early stages of a project is one of the purposes of a prototype. 

What is a Minimum Viable Product?

Prototypes often influence an MVP and the two work together to create a successful end product.

An MVP is a minimal form of your complete product that is tested in the market.

This approach to development allows you to learn how your users will react to your product before you waste a lot of money and resources building something no one wants or needs.

While prototypes solve problems during the early stages of development, an MVP’s iterative process is designed to identify users’ pain points when the product is actually tested in the market. 

The risk of developing more (or less) than you need is why validating your product assumptions with an MVP is so important. 

Starting with a core feature, learning how users react to that feature and building in accordance with user feedback is essential for determining the appropriate amount of functionality your product needs to acquire and retain users. Over time, the learnings that come from an MVP define your product roadmap and guide the evolution of your app. 

An MVP is a version of a product that includes only the features it needs to be marketable. With the MVP process, you can verify the following: 

    Product viability 

    Product assumptions 

    Usability 

    Market demand 

MVPs provide immediate value while minimizing development costs.

Ultimately, an MVP allows you to build a product with minimal features and iteratively build it out to create a better, more polished product while leveraging user intelligence to make the best decisions possible. With every release version, the product evolves to maximize ROI and move towards a fully mature application. 

https://clearbridgemobile.com/beginners-guide-poc-vs-mvp-vs-prototype/

• What is the Difference Between MVP vs POC vs Prototype and why does it matter?

Factor:Role 

POC

Is this concept even feasible? The POC can be used to validate assumptions about the idea.

Prototype:

How will the product or solution actually function?

MVP:

What is the value proposition of the product and how will it function?

Factor:Development

POC

Demonstrates that a solution could be built

Prototype:

Shows how the solution will be built and how it will work.

MVP:

Is a built version of the product that tests the market for it.

Factor:Audiences

POC

Tends to be rather small and used internally to showcase an idea.

Prototype:

Usually used internally to see how the development work will be carried out.

MVP:

Is used externally to gauge market interest and see how it could be improved.

Factor:Issues

Prototype:

Deals with issues at the early stage of development.

MVP:

Takes an iterative approach to development looking at issues the client has with the product when it is in the market.

Factor: Function

POC

Does not function as a fully working product.

Helps to understand whether it is feasible to go ahead with the product.

Prototype:

Does not function as a fully working product.

Helps to see how the product will look and how it will feel for the user.

MVP:

Functions fully as a working product using the basic but most essential functionality.

Helps to see how the product will be used.

Factor: Feedback

POC

Does not provide an opportunity for feedback from actual or possible customers. Might sometimes be used with investors to attract funding.

Prototype:

Can allow the firm to get feedback from a few possible customers.

MVP:

Allows the firm to gather feedback from a lot of customers, potentially.

Factor: Customer growth

POC

Does not grow the customer base.

Prototype:

Does not grow the customer base.

MVP:

Grows the customer base at the same time as iterative development is taking place.

Factor: Revenues

POC

Will not bring in revenues from customers.

Prototype:

Will not bring in revenues from customers.

MVP:

Can bring in revenues from customers.

https://enkonix.com/blog/mvp-vs-poc-vs-prototype/

Reflection

• Reflection is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine.

http://docs.oracle.com/javase/tutorial/reflect/index.html

• Reflection allows the examination/modification of classes/objects at runtime. Personally I have only used it to implement a factory pattern. This is where there are a number of classes/subclasses that could be used to create objects at runtime. Based on some variable I can create the correct object by loading the class I want.

Class<?> c = Class.forName(someclass);
superTypeOfClass = c.newInstance();

I believe the instanceOf (isInstance() maybe) is also part of the Reflection API allowing you to discover the run time type of an object. Hope this helps.


Another example is Spring core framework's depedency injection. It is done through Reflection API.


Reflection API helps to manipulate classes and its properties at run time. You can create instance for class and can execute all methods (including private).
For example, To test private methods in JUnit.
http://www.linkedin.com/groups/What-is-Reflection-API-Can-70526.S.225700742?view=&srchtype=discussedNews&gid=70526&item=225700742&type=member&trk=eml-anet_dig-b_pd-ttl-cn&ut=0j-X2_38EiZRE1

CMMI Maturity Levels

Here is a list of all the corresponding process areas defined for a S/W organization. These process areas may be different for different organization.

Level	Focus	Key Process Area	Result
5 Optimizing	Continuous Process Improvement	Organizational Innovation and Deployment Causal Analysis and Resolution	Highest Quality / Lowest Risk
4 Quantitatively Managed	Quantitatively Managed	Organizational Process Performance Quantitative Project Management	Higher Quality / Lower Risk
3 Defined	Process Standardization	Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Mgmt (with IPPD extras) Risk Management Decision Analysis and Resolution Integrated Teaming (IPPD only) Org. Environment for Integration (IPPD only) Integrated Supplier Management (SS only)	Medium Quality / Medium Risk
2 Managed	Basic Project Management	Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management	Low Quality / High Risk
1 Initial	Process is informal and Adhoc		Lowest Quality / Highest Risk

http://www.tutorialspoint.com/cmmi/cmmi-maturity-levels.htm

• Process Area Organization

In CMMI models, the process areas are organized in alphabetical order according to their acronym. However, process areas can be grouped according to maturity levels or process area categories.

Maturity Levels: CMMI for Development

There are Five maturity levels. However, maturity level ratings are awarded for levels 2 through 5. The process areas below and their maturity levels are listed for the CMMI for Development model:
Maturity Level 2 - Managed

• CM - Configuration Management
• MA - Measurement and Analysis
• PMC - Project Monitoring and Control
• PP - Project Planning
• PPQA - Process and Product Quality Assurance
• REQM - Requirements Management
• SAM - Supplier Agreement Management

Maturity Level 3 - Defined

• DAR - Decision Analysis and Resolution
• IPM - Integrated Project Management
• OPD - Organizational Process Definition
• OPF - Organizational Process Focus
• OT - Organizational Training
• PI - Product Integration
• RD - Requirements Development
• RSKM - Risk Management
• TS - Technical Solution
• VAL - Validation
• VER - Verification

Maturity Level 4 - Quantitatively Managed

• OPP - Organizational Process Performance
• QPM - Quantitative Project Management

Maturity Level 5 - Optimizing

• CAR - Causal Analysis and Resolution
• OPM - Organizational Performance Management

Maturity Levels: CMMI for Services

The process areas below and their maturity levels are listed for the CMMI for Services model:
Maturity Level 2 - Managed

• CM - Configuration Management
• MA - Measurement and Analysis
• PPQA - Process and Product Quality Assurance
• REQM - Requirements Management
• SAM - Supplier Agreement Management
• SD - Service Delivery
• WMC - Work Monitoring and Control
• WP - Work Planning

Maturity Level 3 - Defined

• CAM - Capacity and Availability Management
• DAR - Decision Analysis and Resolution
• IRP - Incident Resolution and Prevention
• IWM - Integrated Work Management
• OPD - Organizational Process Definition
• OPF - Organizational Process Focus
• OT - Organizational Training
• RSKM - Risk Management
• SCON - Service Continuity
• SSD - Service System Development
• SST - Service System Transition
• STSM - Strategic Service Management

Maturity Level 4 - Quantitatively Managed

• OPP - Organizational Process Performance
• QPM - Quantitative Project Management

Maturity Level 5 - Optimizing

• CAR - Causal Analysis and Resolution
• OPM - Organizational Performance Management

Maturity Levels: CMMI for Acquisition

The process areas below and their maturity levels are listed for the CMMI for Acquisition model:
Maturity Level 2 - Managed

• AM - Agreement Management
• ARD - Acquisition Requirements Development
• CM - Configuration Management
• MA - Measurement and Analysis
• PMC - Project Monitoring and Control
• PP - Project Planning
• PPQA - Process and Product Quality Assurance
• REQM - Requirements Management
• SSAD - Solicitation and Supplier Agreement Development

Maturity Level 3 - Defined

• ATM - Acquisition Technical Management
• AVAL - Acquisition Validation
• AVER - Acquisition Verification
• DAR - Decision Analysis and Resolution
• IPM - Integrated Project Management
• OPD - Organizational Process Definition
• OPF - Organizational Process Focus
• OT - Organizational Training
• RSKM - Risk Management

Maturity Level 4 - Quantitatively Managed

• OPP - Organizational Process Performance
• QPM - Quantitative Project Management

Maturity Level 5 - Optimizing

• CAR - Causal Analysis and Resolution
• OPM - Organizational Performance Management

http://en.wikipedia.org/wiki/Process_area_%28CMMI%29

• What is CMMI and what's the advantage of implementing it in an organization?

 It is a process improvement approach that provides companies with the essential elements of an effective process. CMMI can serve as a good guide for process improvement across a project, organization, or division.

 the areas which CMMI addresses:
 Systems engineering: This covers development of total systems. System engineers concentrate on converting customer needs to product solutions and supports them throughout the product lifecycle.

Software engineering: Software engineers concentrate on the application of systematic, disciplined, and quantifiable approaches to the development, operation, and maintenance of software.

Integrated Product and Process Development (IPPD): Integrated Product and Process Development (IPPD) is a systematic approach that achieves a timely collaboration of relevant stakeholders throughout the life of the product to better satisfy customer needs, expectations, and requirements. This section mostly concentrates on the integration part of the project for different processes. For instance, it's possible that your project is using services of some other third party component. In such situations the integration is a big task itself, and if approached in a systematic manner, can be handled with ease.

Software acquisition: Many times an organization has to acquire products from other organizations. Acquisition is itself a big step for any organization and if not handled in a proper manner means a disaster is sure to happen.

What's the difference between implementation and institutionalization?
Institutionalization is the output of implementing the process again and again. The difference between implementation and institutionalization is in implementation if the person who implemented the process leaves the company the process is not followed, but if the process is institutionalized then even if the person leaves the organization, the process is still followed.

http://www.indiabix.com/technical/software-testing/cmmi/

• A maturity model is a business tool used to assess people/culture, processes/structures, and objects/technology.[1] Two approaches for designing maturity models exist. With a top-down approach, such as proposed by Becker et al.,[2] a fixed number of maturity stages or levels is specified first and further corroborated with characteristics (typically in form of specific assessment items) that support the initial assumptions about how maturity evolves. When using a bottom-up approach, such as suggested by Lahrmann et al.,[3] distinct characteristics or assessment items are determined first and clustered in a second step into maturity levels to induce a more general view of the different steps of maturity evolution. Topics that are covered in maturity models include

https://en.wikipedia.org/wiki/Maturity_model#PLM

• What is a Maturity Model, and why use one?

The use of a maturity model allows an organization to have its methods and processes assessed according to management best practice, against a clear set of external benchmarks. Maturity is indicated by the award of a particular "Maturity Level"
http://www.apmg-international.com/en/consulting/what-maturity-model.aspx

• A maturity model is a tool that helps people assess the current effectiveness of a person or group and supports figuring out what capabilities they need to acquire next in order to improve their performance. 

http://martinfowler.com/bliki/MaturityModel.html
 

Event-driven architecture

• Event-driven architecture

Event-driven architecture (EDA) is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.
http://en.wikipedia.org/wiki/Event-driven_architecture

quizes,tests,exams

CSC407H Exercises: Summer 2006
http://www.cdf.utoronto.ca/~csc407h/summer/exercises.shtml

course pages

CSC407H: Software Architecture -- Summer 2006
http://www.cdf.toronto.edu/~csc407h/summer/


CSC407 Software Architecture
Winter 2007
http://www.cdf.toronto.edu/~csc407h/winter/


CSC407 Software Architecture
Fall 2006
http://www.cdf.toronto.edu/~csc407h/fall/

Reflection vs introspection

• Reflection is a feature in the Java programming language. It allows an executing Java program to examine or "introspect" upon itself, and manipulate internal properties of the program. For example, it's possible for a Java class to obtain the names of all its members and display them.

The ability to examine and manipulate a Java class from within itself may not sound like very much, but in other programming languages this feature simply doesn't exist. For example, there is no way in a Pascal, C, or C++ program to obtain information about the functions defined within that program.

http://java.sun.com/developer/technicalArticles/ALT/Reflection/
http://yzgrafik.ege.edu.tr/~tekrei/dosyalar/projeler/JavaReflection.pdf
http://www.slideshare.net/upen.rockin/reflection-in-java

• In computer science, reflection is the ability of a computer program to examine (see type introspection) and modify the structure and behavior (specifically the values, meta-data, properties and functions) of an object at runtime.[1]

Reflection is most commonly used in high-level virtual machine programming languages like Smalltalk and scripting languages and also in manifestly typed or statically typed programming languages such as Java, C, ML and Haskell.
http://en.wikipedia.org/wiki/Reflection_(computer_programming)

• ReflectionApis

Reflection is a programming technique used to build code that is flexible by giving the programmer the power to modify and examine the behaviour of a program at runtime. Reflection gives the code access to internal structures of classes - constructors, fields and methods. It falls under the broad area of Metaprogramming - programs that write other programs.Reflection can be very powerful for late binding, creating new types duing run-time, examining types etc.

Reflective Languages

The concept of reflective programming was started late back in the 80's. Since then, there have been many languages that provide reflection capabilities. Reflection requires dynamic modification of the program. For this reason, compilers would have to have some metadata format to look back at it's own code. Java and C# do this through the Java virtual machine and the .NET VM respectively. On the other hand, since dynamic languages like Python and Ruby only try to interpret the code at run-time, more powerful forms of reflection can be achieved. Other languages like C, C++ lack reflection capabilities largely because of the metadata that they fail to maintain. The following are a few languages that support reflection:

   • Java
   • C#
   • Ruby
   • Smalltalk
   • Python
   • Eiffel
 
 
   Is reflection "Built-in"?
 
   Reflection naturally comes to interpreted languages. Ruby, Python, Smalltalk would not have to go out of their usual way to implement and exhibit reflective properties.
 
   Java and .NET look at the intermediate code to figure out the structure of a class and then try to add more at run-time.
   This, obviously takes a performance hit since the code cannot be compiled and optimized. Java and Microsoft .NET both have references to objects as well as built-in types. Wrappers for built-in types exist that provide reflection on primitive types.
 
   Languages like C, C++ lack reflective capabilities. They are based on the philosophy of "You don't pay for what you don't use". Maintaining information about types, methods and the like involve significant overhead. Moreover, performance can become a bottleneck, not to mention a few security concerns with reflection. C and C++ compilers optimize code to maximize performance and are not open to trade performance and overhead.
 
   If reflection is deemed necessary for such languages, there would have to be another library or a tool to take care of parsing the source code, building abstract syntax trees containing every detail of the program, build symbol tables, extract control and data flows by building a graphical representation and have custom analysers analyse this representation. The DMS Software Reengineering Toolkit is one such toolkit for C, C++ and COBOL.
 


 Java

The java virtual machine is capable of generating an instance of java.lang.Class for every object created. This Class consists of methods that can examine the properties of the object at runtime. In java, all the reference types are inherited from the Object class. The primitive types on the other hand have wrapper classes around them - for example int has the Integer class for it's wrapping. For example, to get the name of a class:



   Before using reflection, Java requires the user to import java.lang.reflect.*; This is the package that provides reflective capabilities. Java provides APIs for Retrieving class objects, Examining class modifiers and types and discovering class members. What Java lacks however is the finer granularity when compared to .NET. The Class objects that java uses tend to lose some information, for example, parameter names.

Java's reflection also includes useful methods that return classes themselves. The complete design of all the related classes can be captured using APIs such as:

    •getSuperClass()     : To return the classes' super class
    •getClasses() ;          : Return all members including inherited members
    •getEnclosingClass() : used in case of nested classes. Returns the immediate enclosing
 
 
http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_5_ReflectionApis

• In computing, type introspection is the ability for a program to examine the type or properties of an object at runtime. Some programming languages possess this capability.

Introspection should not be confused with reflection, which goes a step further and is the ability for a program to manipulate the values, meta-data, properties and/or functions of an object at runtime. Some programming languages also possess that capability.


The simplest example of type introspection in Java is the instanceof^[1] operator. The instanceofoperator determines whether a particular object belongs to a particular class (or a subclass of that class, or a class that implements that interface). For instance:

if(obj instanceof Person){
   Person p = (Person)obj;
   p.walk();
}

The java.lang.Class^[2] class is the basis of more advanced introspection.

For instance, if it is desirable to determine the actual class of an object (rather than whether it is a member of a particular class), Object.getClass() and Class.getName() can be used:

System.out.println(obj.getClass().getName());

http://en.wikipedia.org/wiki/Type_introspection

• Java Reflection vs Java Introspection

"Reflection" refers to the low-level API with which you can ask "what are the methods of this class", "what parameters does this method accept", "what is the parent class of this class", and so on. "Introspection" is a higher-level concept; it generally refers to using the reflection API to learn about a class. For example, the javax.beans.Introspector class will give you the list of JavaBeans properties of a class -- i.e., the pairs of matching "Y getX()"/"void setX(Y)" methods.

Introspection is concept of querying any reference (Object) RUNTIME for its type/class /method details ..
Reflection is Java API which provides this ability .


http://www.coderanch.com/t/521121/java/java/Java-Reflection-vs-Java-Introspection

• Reflection

    Reflection is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique and can enable applications to perform operations which would otherwise be impossible.

Introspection

    Introspection is the automatic process of analyzing a bean's design patterns to reveal the bean's properties, events, and methods. This process controls the publishing and discovery of bean operations and properties.

Introspection uses reflection, the relationship between Introspection and Reflection can be seen as similar to JavaBeans and other Java classes.

http://stackoverflow.com/questions/2044446/java-introspection-and-reflection

• Reflection and Introspection

The Reflection API allows Java code to examine classes and objects at run time and to dynamically access another class's methods and instance fields.

o java.lang.reflect

? i.e., The Field Class

• getfields(); getfield(); set(); etc.

? i.e., The Method Class

• getMethods(); getMethod(); invoke(); etc.


Reflection versus Introspection
The terms reflection and introspection are commonly interchanged because they provide very similar functionality: both allow programmatic access to a class's underlying methods and properties. The difference is that introspection, which uses the java.beans.Introspector class, provides a more JavaBean-centric view of a class. It provides a standard mechanism to learn about the properties, events, and methods of a class.

Reflection, on the other hand, is supported directly by the java.lang.Class class, and provides lower-level access to the underlying methods. In other words, reflection focuses on methods and not on class properties.
http://www.informit.com/guides/content.aspx?g=java&seqNum=362

• Introspection Uses Reflection

Reflection and introspection are very closely related. Reflection is a low-level facility that allows the code to examine the internals of any class or object at runtime. Introspection builds on this facility and provides a more convenient interface for examining Beans. In fact, the relationship between reflection and introspection is very similar to the relationship between JavaBeans and other Java classes. JavaBeans are simply normal Java objects with certain design patterns enforced in their nomenclature. Introspection assumes these design patterns on the object that it is inspecting and uses low-level reflection to examine the object's internals.

http://www2.sys-con.com/itsg/virtualcd/java/archives/0305/sagar2/index.html