Projects in Software Development

Firstly, let's introduce some key concepts:

Project: Any work that has a particular purpose and a definite time to do it. For example Admissions system of ITESM.

Program: Group projects linked with a common purpose. For example, program for any college admissions system

Portafolio: Group of programs linked by a target. They are handled separately because they have different goals. Portfolio universities.

Nevertheless the most important concept on here is the project, which will be the main focus of the rest of this blog post.

What is a project?

Temporary, projects will always have a start and a finish

• They start when you decide what you are going to do
• They end when you create the product or service you set out to create
• Sometime.they end because you decide to stop doing the project
• But they are never ongoing.
• Operations are ongoing. 

Creating a unique result

• When you create the product of your project, it is measurable.
• If you start a project to create a piece of software or build a building, you can tell that software or that building from any other one that has been produced

Progressively elaborate

• You learn more and more about a project as it goes on.
• When you start, you have goals and a plan, but there is always new information to deal with as your project goes on and you’ll always have to make decisions to keep it on track.

Importance of planning in software development

Examples of problems in software development:
 

One very common problem is when the boss sets a delivery date before the project can actually be done.

Running out of budget without finishing the project is also a problem.

Planning without considering risks. (natural disasters, not understanding the problem, schedule, etc).

However, these problems aren't insurmountable, one common tool we can use to avoid solve these problems in the Project Manager Book of Knowledge (PMBoK)

 PMBoK:

• International standard
• Collection of knowledge of project management experts around the world
• Guide to deal with the most recurring problems
• Learn from others
• Learn how to plan
• Estimating tasks, sequences, resources
• Costs
• Defects  

What do we need to be able to plan effectively?

• Knowledge
• reading, tracking trends
• Performance
• Having the work finished, is about going beyond theory
• Personal skills
• Emotional intelligence, leadership, incentives

 

Mind Map

These concepts might be overwhelming, so here is a mind-map that explains most of these concepts.

 
Note!!
If the last image was too small, here is a link to see it full size.
http://imgur.com/WPzF6dW

 

Software Process Models II

1) RUP

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

One of the main characteristics of the Rational Unified Process, is that instead of other types of software development which start working on one specific element of the software development cycle, RUP is divided in many iterations. During each iteration there is a specific time investment being delegated towards some of the areas of the software development cycle, for example at the beginning most of the work is focused on business modelling and requirements, whereas, near the end, there is a large emphasis on project and change management. Regardless of this, it is still noted that almost every area of the software development cycle will be worked on during every iteration, but the focus on each area might shift during the different iterations.

4 main phases can be identified in the RUP, which are
a) Inception: Where the project is defined and the scope is identified.
b) Elaboration: Where possible risk elements are attempted to be mitigated and the system’s architecture is defined.
c) Construction: Where the actual software solution is being made.
d) Transition: Where the project is moved from development into production and the end users finally understand it.

2)  Spiral ModelThe process begins at the center position. From there it moves clockwise in traversals. Each traversal of the spiral usually results in a deliverable. It is not clearly defined what this deliverable is. This changes from traversal to traversal. For example, the first traversals may result in a requirement specification. The second will result in a prototype, and the next one will result in another prototype or sample of a product, until the last traversal leads to a product which is suitable to be sold. Consequently the related activities and their documentation will also mature towards the outer traversals. E.g. a formal design and testing session would be placed into the last traversal.

The most important element of the Spiral Model is that it is focused on risk management, there is a very large emphasis placed on possible constraints and risks, which makes it one of the safest paradigms to apply on risky projects.

3) Agile

   Emphasis on flexibility in producing software quickly and capably

--------Agile manifesto---------

·         Value individual and interactions over process and tools

·         Prefer to invest time in producing working software rather than in producing comprehensive documentation

·         Focus on customers collaboration rather than contract negotiation

·         Concentrate on responding to change rather than on creating a plan and then following it

Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. These principles support the definition and continuing evolution of many software development methods.

Examples of agile process

• Extreme programming (XP)

1.- Communication: continual interchange between customers and developers

2.- Simplicity: select the simplest design or implementation

3.- Courage: commitment to delivering functionality early and often

4.- Feedback: loops built into the various activities during the development process

TWELVE FACETS OF XP

The planning game(Customer defines value)	Pair programming
Small release	Collective Ownership
Metaphor (Common vision, common names)	Continuous integration (Small increments)
Simple design	Sustainable pace(40 hrs/week)
Writing tests first	On-site customer
Refactoring	Coding standard

When extreme is Too extreme?

• Extreme programming practices are interdependent
• A vulnerability if one of them is modified

• Requirements expressed as a set of test cases must be passed by the software
• System passes the tests but is not what the customer is paying for.

• Refactoring issue
• Difficult to rework a system without degrading its architecture
•  

Agile's main characteristics:

a) Comunication:  interchange of ideas and opinions between customers and developers.

b) Simplicity: select the simplest design or implementation.

c) Courage: commitment to delivering functionality early and often

d) Feedback: loops built into the various activities during the development process.

SOFTWARE PROCESS MODELS:

1) WATERFALL MODEL:

• It's not flexible. Causes software failures. There is no iteration in waterfall model.

DRAWBACKS OF WF MODEL:

• No guidance on how to handle changes to products and activities during development.
• Views software development as manufacturing process rather than a creating process.
• There is no iterative activities  that lead to creating a final product
• Long wait before a final product.

V MODEL:

If problems are found during verification and validation, the left side of the V can be re-executed before testing on the right side is rebuilt.

 2) PROTOTYPING MODEL:

Allows repeated investigation of the requirements or design.

Reduces risk and uncertainty in the development.

3) OPERATIONAL SPECIFICATION MODEL:

• Requirements are executed and their implication evaluated early in the development process.
• Functionality and the design are allowed to be merged.

4) TRANSFORMATIONAL MODEL:

• Relies on formalism.
• Requires formal specification (to allow transformations)
• Fewer major development steps.

5) USIXML:

UsiXML is more than a XML-compliant markup language that describes the UI for multiple contexts of use such as Character User Interfaces (CUIs), Graphical User Interfaces (GUIs), Auditory User Interfaces, and Multimodal User Interfaces, it also considers models to support model-based User Interface development compliant with the cameleon reference framework.

Common software development myths:

Management myths:

1. -           Members of an organization acquire all the information they need from a manual. Standards are often incomplete, unadaptable and outdated. Developers are often unaware of established standards. Developers rarely follow the known standards.
   
2. -         If the project is behind schedule, increasing number of programmers can reduce time gap. New workers take longer to learn about the project, compared to those already working on the project.
   
3. -      If the project is outsourced to a third part, the management can relax and let the other firm develop software for them. Outsourcing software does not help the organization, which is incompetent in managing and controlling the software project internally.
   
4. -   Brief requirement stated in the initial process is enough to start development-, detailed requirements can be added at the later stages. Starting development with ambiguous requirement lead to software failure, you need a complete and formal description of requirements before starting. Adding requirements requires repeating the entire development process.
   
5. -        Software is flexible, hence software requirements changes can be added during any phase of the development process.  Incorporating change requests earlier in the development process cost lesser than those that occurs at later stages. This is because incorporating changes later may require redesigning and extra resources.
   

 

DEVELOPER MYTHS:

1. -    Software development is considered complete when the code is delivered. 50 to 70% of all the efforts are expended after the software is delivered to the user.
   
2. -        The success of a software project depends on the quality of the product produced. The quality of programs is not the only factor that makes the project successful instead the documentation and software configuration also play a crucial role.
3. -        Software engineering requires unnecessary documentation, which slows down the project. Software engineering is about creating quality at every level of the software project. Documentation enhances quality which results in reducing the amount of work.
   
4. -        The only product that is delivered after the completion of a project is the working program(s).  The deliverables of a successful project include not only the working program but also the documentation to guide the users for using the software.
   
5. -        Software quality can be assessed only after the program is executed.  The quality of software can be measured during any phase of development process by applying some quality assurance mechanism, one such mechanism is formal technical review that can be effectively used during each phase of development to uncover certain errors.
   
   

SOFTWARE DEVELOPMENT LIFE CYCLE:  

Requirements are:

• FUNCTIONAL (code) is what the software must do.
  
  
• NON-FUNCTIONAL is what do we expect from the software, like easy to use, useful, use it, esthetics, simple, free of errors, fast, usability, adaptable, reliable error handling, all nonfunctional requirements are subjective).
  

• DESIGN: Architecture, are blueprints of how to develop software. Models, is how different process are organized, process, task, domain – diagram models, dialog model (how the information gets in, how to interact with the software), stats model (states of each class for the system to work).

• IMPLEMENTATION: Programming.

• VERIFICATION: Consist on validate all the functional and nonfunctional requirements. The requirements must be measurable.

• MAINTENANCE: Is the modification of a software product after delivery to correct faults, to improve performance or other attributes