Page 3 of 7

INTRODUCTION

Project planning is an essential task in software development projects. According to Sommerville (2007), good management cannot guarantee the success of a software project, but bad management usually reflects in the failure of the projects. In the software project management Risk Analysis is a key subject to be included in the project plan.

As a job of project managers, identifying and documenting the risks will allow the whole development team to take actions to mitigate it to do not let the project to fail.

As seen in the picture below, project risks should be identified, analyzed, planned and monitored in order to allow the actions to mitigate them to do not let the project to have problems, which will delay or even make it fail.

riskstableFigure 1 The risk management process

My discussion relates below the three risks a project may have and how they can lead to negative impacts on a software project.

RISK #1 SCOPE CREEP

Scope creep can be defined as anything which is added to the project and was not part of the initial scope or plan. According to Kendrick (2015), by adding little value, the project will get more and more delayed, and the changes in scope delay so much that the ultimate deliverable has no value anymore because the need will no longer press or met by other means. Scope creep may lead a project to real negative impacts, and this is a very common subject in the project planning.

RISK #2 WRONG ARCHITECTURAL CHOICE

Based on my experience, since the beginning of the Project, after gathering the non-functional and even functional requirements, a good architecture solution must be designed. If you consider the Java environment, for instance, you may have different approaches to work with web applications. Component-based approaches may lead to a better user experience, depending on the solution it is required to be met, using component-based approaches may lead to performance issues in the user browser and even in the application server, on the other hand going with action controller based applications, it may lead to more performance, however less productivity.

Less performance may lead to a project to fail if we consider a platform which allows millions of users to be online at the same time. Less productivity also may lead to the project to fail, if the project-budget is limited.

RISK #3 COMPANY TURNOVER

If we consider a software process like RUP, for instance, where most of the artifacts keep the project information, an often company turn-over would not let a project to have more than 80% of having loss, however if we consider a project where the agile methodologies are being used, the company turn-over may lead the project to have many losses or even to fail, and I’d say in more than 80% of chances. The weak documentation or even the lack of resources to understand the project would make the new stakeholders to a big delay in terms of deliveries and the outcome might not meet the software initial requirements.

REFERENCES

Sommerville, I, 2007. Software Engineering. 8th. England: Pearson. pp. 104-113.

Kendrick, T, 2015. Identifying and Managing Project Risk. 1st. New York: Amacom. pp. 52-53.

INTRODUCTION

The 4+1 view model was designed to describe the system in different views, for different stakeholders, being separated in ‘logical’, ‘development’, ‘process’ and ‘physical’ views, which helps in graphically representing and describing the architectural solution designed (Kruchten, 1995). The idea of the 4+1 view model was to come up with a representational graphical manner to separate the different aspects of a software system into different views of the system.

THE 4+1 VIEW MODEL

The 4+1 view model proposed in 1995 suggests that the software architecture is represented in 5 segregated views, which are commented below (Staveley, 2011):

  • The logical view: Demonstrating the object model of the design (e.g Class Diagram, Sequence Diagram, State machine Diagrams);

  • The process view: Refers to the synchronization and concurrency aspects of a solution design (e.g Activity Diagrams);

  • The physical view: Refers to the deployment aspects, such as how many nodes will be used and what will be deployed in that node (e.g Deployment Diagram);

  • The development view: Refers to the software modules and subsystems (e.g Package and component diagrams);

  • Use case view: Refers to the functionality of the system (e.g Use Case Diagram).

THE UNIFIED MODELLING LANGUAGE

The Unified Modelling Language (UML) came up after 2 years of the 4+1 view model and today it is a standard in software development to represent graphically object-oriented software development complexity to make understandable the technical aspects of a designed solution.

The main objective of this small article is to introduce the sequence diagram which may be cataloged in the logical view of the 4+1 view model, discuss some of the advantages of using this diagram and disadvantages.

THE SEQUENCE DIAGRAM

The sequence diagram represents an exemplary snippet of a software system process (B. Rumpe, 2016). The communication between objects, the system flow, and even parameters in object messages can be represented through the sequence diagram.

sequencediagram

Figure 1 An example of a sequence diagram

The representation of the diagram above, simply describes the web process of an Actor call a findStudent() method, going through many layers of an imaginary software and returning the result back.

Based on my experience, when a software solution design contemplates a sequence diagram, it is much easier to follow the flow proposed in the architecture, but there is a point very important to bring up: the more you have in the UML documentation the easier will be to a developer understand what is meant to be done. Considering UML not only for documentation but for development, If you consider distributed teams geographically dispersed, as much as you have in documentation using graphical representation like the UML sequence diagram, the easier will be to the developers to come up with the right solution.

REFERENCES

Kruchten, P, 1995. Architectural Blueprints—The “4+1” View Model of Software Architecture. IEEE Software 12, [Online]. 6, 42-50. Available at: http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf [Accessed 18 June 2017].

Alex Staveley. 2011. The “4+1” View Model of Software Architecture. [ONLINE] Available at: https://dzone.com/articles/%E2%80%9C41%E2%80%9D-view-model-software. [Accessed 18 June 2017].

Rumpe, B, 2016. Modeling with UML. 1st ed. Switzerland: Springer International.

INTRODUCTION TO SOCIO-TECHNICAL SYSTEMS

A system can be defined as a collection of components working together to achieve a common objective (Sommerville, 2013). People as well interact with technology in order to achieve some goal in organizations bringing up the concept of socio-technical systems, which is basically technological resources which help people to interact themselves and organizations to achieve their goals.

According to the Interaction Design Foundation, 2017, these below are examples of socio-technical (STS) systems:

  • E-mail;

  • Twitter;

  • Facebook;

  • YouTube;

  • Chat;

The technology we have today allows us to have more friendly contact with our family, friends, coworkers, and people involved in our lives. If we consider today we can chat live with many people in different localizations and in a high-resolution online meeting via Skype, for instance, we can see the impact of technology in the people interaction.

The way we work today in multi-cultural companies, especially in multinational companies are much more dynamic and the impact of the socio-technical systems, allows this kind of not only communication improvements but also of collaborative work to flow better, the way tools helps a lot this kind of activity.

COPING WITH THE FAILURE

System failure may occur in any system because of hardware or even software issues. If we consider that systems should be tolerant to failure because of the software engineering methods to do not be developed enough to produce systems with no-failure.

In the past, when systems used to be written in C and C++, the probability of a system to produce failure was far beyond higher than the technology it is written today in the Java and .NET, which are more modern platforms. The introduction of the high-level programming languages allowed developers to focus more on the software to be developed based on the business solution they want to achieve and focus less on the low-level machine instructions and memory management issues in which may lead to system failures.

PROJECT PLANNING

Software products are usually developed as projects in software house companies, which may have a start and an end. Software Engineers in order to produce software systems, are based on the development of the software engineering and project management studies, which are understood and allowed by the research distributed and shared all over the world based on the experience acquired by all the individuals which may share it in masters or doctoral studies like this one we have at the University of Liverpool Online.

The impact on socio-technical systems comes out when software needs changes and upgrades because considering we have changes in the business operations and changes caused by technological advances, for instance, it all comes to planning in which is responsible to continuously improve the software based on its needs.

REFERENCES

Ian Sommerville. (2013). Introducing sociotechnical systems. [Online Video]. 23 November 2013. Available from: https://www.youtube.com/watch?v=xdFftbIToV0. [Accessed: 14 June 2017].

Interaction Design Foundation. 2017. The Encyclopedia of Human-Computer Interaction, 2nd Ed.. [ONLINE] Available at: https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed/socio-technical-system-design. [Accessed 15 June 2017].

The agile culture in the software engineering science started with the Agile Manifesto (Cunningham et al., 2001), written in 2001 by seventeen visionaries in which where working to find new ways of developing better software, which where also brought some principles commented based on my point of view and listed in the enumeration below:

  • Individuals and interactions over processes and tools: Most software engineering processes started to produce thousands of pages and design models, diagrams, process workflow, etc… This principle changes dramatically the way things are organized in software development;

  • Working software over comprehensive documentation: Instead of writing a lot of comprehensive documentation, this principle put the idea of writing deliverable software instead of documentation first or to do not have documentation – it depends on the project;

  • Customer collaboration over contract negotiation: Tends to have the customer involved in your process and not only and simply negotiating contracts; Iterative incremental approaches helps on that way to produce with better software quality.

  • Responding to change over following a plan: Iterations in the software development process may answer to changes and not follow a plan. Moreover, with the introduction of the concept of DevOps and continuous integration, for instance, you see that the agile principles written in the agile manifesto are pertinent until today.

Based on those principles, many processes tools and approaches where being produced over all these years in order to improve software development approaches. In the following items, I enumerate some of the advantages and disadvantages of using the agile methodology, considering processes, delivery, maintenance, test automation, and software documentation.

ADVANTAGES

Faster deliveries: With the implementation of the agile culture in terms on software process in software development, it can be observed that most of the software developed with iterative incremental approaches such as Scrum leads to faster deliveries, since based on its principles, Scrum, for instance, works with a prioritized product backlog, in which may lead to a faster impression on the results of the project, which also may lead to a big change in the project.

Agile testing culture: The agile culture brought to us really good software development techniques such as TDD – Test Driven Development, in which allows to build testable software components, and more than that: to build software components with the test in mind leading to better software architectures(Clifton, 2014) and afterwards to be put in a continuous integration approach leading to regression testing which leads to a good practice looking over to keep the product integrity. Based on my experience, it can be only achieved with the agile culture in projects.

DISADVANTAGES

Difficult to work with big teams: Based on my experience, agile methods work better when you have a smaller group of people working together. To be more precise, if you compare to RUP, where all the requirements and guidance to develop the software is written within specifications, you see that working with bigger groups of people may have a better result with ‘standard’ software development processes.

Weak documentation: In spite of not being a principle of not producing documentation, but to put deliverable in bigger precedence, seems like there is a lack of documentation while working with agile methodologies, because of its dynamic process. Documenting requirements, interactions and workflows after having the product may seem like no sense in the agile culture.

Continuous UAT: The need for continuously validating with User Acceptance Tests, may lead to project cost to increase, in spite of possibly leading to better final software quality (Waters, 2007).

REFERENCES

Cunningham et al. 2017. Manifesto for Agile Software Development. [ONLINE] Available at: http://agilemanifesto.org/. [Accessed 11 June 2017].

Kelly Waters. 2007. Disadvantages of Agile Development. [ONLINE] Available at: http://www.allaboutagile.com/disadvantages-of-agile-development/. [Accessed 11 June 2017].

Marc Clifton. 2014. TDD is not the Failure, our Culture of Development Is. [ONLINE] Available at: https://marcclifton.wordpress.com/2014/05/11/tdd-is-not-the-failure-our-culture-of-development-is/. [Accessed 11 June 2017].

Today I am here to share with you something very interesting about what happened in the ’70s when the code was shared by hobbyists which used to develop software in the universities.

I just knew this after watching the movie Revolution OS (which is very nice indeed), and the purpose of this post is to show you who was the “enterprising” mind behind corporate software: Bill Gates — and I just don’t want to make the idea I am against him, of course not, since I believe he did a lot for computer science and Microsoft looks like is changing their minds to open source software since cloud computing took the scene.

There it follows the e-mail Bill Gates sent to the hobbyists encouraging them to make money with software and closing codes/patents — whatever:

bill_gates_letter_to_hobbyists-791x1024

p.s:  A very interesting movie to watch is the Revolution OS — a movie about Linux, which tells a bit about Linux, GNU the all the Open Source Software and initiatives. You can find it on http://topdocumentaryfilms.com/revolution-os/

INTRODUCTION

The objective of this small article is to give an introduction about threads, deadlocks and how a deadlock may occur illustrated with code using the Java programming language. In the end, I give my personal point of view about the subject.

MULTITHREADING

A thread can be defined simply by “a separated computation process” that may be children of other threads – or the main program (Savitch, 2010). Threads can also operate in a parallel manner, what means multiple computation processes sharing the same resources, and running for a common goal.

In Java, this can be achieved by using the Thread class, which offers support for implementing single and multithread applications.

deadlockFigure 1 Illustration of a Thread Program in Java

The code figure above shows a simple thread program coded up with the Java language. Basically, this illustrates one thread instanced by the Thread class. The ThreadExample1 class is just an implementation of Runnable, one of the ways of implementing threads with the Java programming language.

 deadlock2

Figure 2 Example of a Multithreading application in Java

When running the code above, will give the output of:

:/

:/

Is off

:/

Is on

Is off

Is on

Is off

Is on

Is off

:/

Table 1 Output of the program

DEADLOCK

Deadlock is defined by WhatIs.com, 2016 as A deadlock is a situation in which two computer programs sharing the same resource are effectively preventing each other from accessing the resource, resulting in both programs ceasing to function.

Figure 3 An illustration of a dead lock

The figure above illustrates a deadlock occurring on the traffic. What happens is that all the cars are trying to access the same resource at the same time, what locks the traffic to flow.

DEADLOCK IN JAVA

“When in doubt, synchronize.”

(Goetz, 2001)

The Java programming language offers synchronization resources in order to prevent deadlocks. What happens is that at every variable that is overwritten using multiple threads, it is strictly recommended that you use synchronization.

Example of a potential synchronization deadlock:

deadlock5

Figure 4 Using the synchronization resource (Goetz, 2001)

Image a scenario while thread A calls oneMethod(), while thread B calls anotherMethod(). What happens is that thread A gets the lock on cacheLock and at the same time thread b gets the lock on tableLock. Now the threads are deadlocked.

TIPS TO PREVENT DEADLOCKS IN JAVA

According to the StackOverflow, 2016 forum, some good tips to avoid deadlocks are:

  • Always use lock-free data-structures;

  • Release locks after a timeout period;

  • Always acquire the locks in the same order.

CONCLUSION

Deadlocks are a very sensible threat to every program which uses multithreading programs sharing the same resources. While debugging and simulating deadlocks are difficult because it needs timing and also it may not occur because of the environment and machine load. The Java programming language offers resources to deal with deadlock issues, however, it is more of a programmers responsibility to avoid this problem.

REFERENCES

Savitch, W, 2013. Absolute Java. 5th ed. USA: Pearson.

WhatIs.com. 2016. What is deadlock? – Definition from WhatIs.com. [ONLINE] Available at: http://whatis.techtarget.com/definition/deadlock. [Accessed 01 May 2016].

Blogspot. 2016. A figure of a deadlock. [ONLINE] Available at: http://3.bp.blogspot.com/-Whe-8HEWtRs/UAJwpICqPjI/AAAAAAAAAeQ/4XFtKnj1-JE/s1600/Comxf.jpeg. [Accessed 1 May 2016].

Brian Goetz. 2001. Avoid synchronization deadlocks | JavaWorld. [ONLINE] Available at: http://www.javaworld.com/article/2075692/java-concurrency/avoid-synchronization-deadlocks.html. [Accessed 01 May 2016].

Multithreading – Tips to prevent deadlocks in java. 2016. Stack Overflow. [ONLINE] Available at: http://stackoverflow.com/questions/16780937/tips-to-prevent-deadlocks-in-java. [Accessed 01 May 2016].

INTRODUCTION

The main objective of this small article is to provide an introduction about the multiple inheritance subject, give an overview of how it is implemented with the Java programming language and my considerations to conclude.

THE INHERITANCE CONCEPT

The concept of inheritance is very close to what we have in genealogy. Fathers share common attributes with sons, whom all share common attributes from its parents, grandparents and so on. Yet, all of them have their own particularities, like eye color, hair color, etc…

xid-94316198_6Figure 1 Illustration of Genealogy

THE INHERITANCE CONCEPT IN PROGRAMMING LANGUAGES

According to Sklenar, 1997, Simula is known and considered as the first object-oriented programming language. This is based on the concept of the conceptualization of the real world brought up to the computing space.

The key aspect of objected oriented programming is to simulate the real world conceptualization of how things are designed, organized and oriented. One of these aspects is the inheritance concept, which is defined and illustrated by Oracle, 2016 as object-oriented programming allows classes to inherit commonly used state and behavior from other classes. The figure below illustrates the inheritance in a bicycle illustrated analogy:

 

xid-94316199_6

Figure 2 Illustration of inheritance

MULTIPLE INHERITANCE

The concept of multiple inheritances can be illustrated with genealogy indeed. Father and mother share common aspects with their children the same way grandparents share commons aspects and particularities.

Although multiple inheritances to do not be implemented by some objected oriented programming languages, it is very common to happen in different manners.

IMPLEMENTATION ON THE JAVA PLATFORM

It is widely known that Java does not support multiple inheritances, however, Java 8 implements functional interfaces (a resource very similar and that can be compared pretty much the same) which are very similar to the concept of multiple inheritances. There is an example which illustrates its functionality below:

code1

(ProgramCreek.com, 2016)

CONCLUSION

In spite of being a powerful resource to the programmer, it is commonly criticized by its complication to debug and even to lead to unnecessary design complexity. The Java programming language does not support it directly; on the other hand, it implements resources (such as function interfaces) which may lead in such a manner to achieve the same functional result.

REFERENCES

ISOGG Wiki. 2016. Mitochondrial DNA tests. [ONLINE] Available at: http://isogg.org/wiki/Mitochondrial_DNA_tests. [Accessed 20 April 2016].

Sklenar J. 1997. INTRODUCTION TO OOP IN SIMULA. [ONLINE] Available at: http://staff.um.edu.mt/jskl1/talk.html#History_I. [Accessed 20 April 2016].

What Is Inheritance?. 2016. What Is Inheritance? ONLINE] Available at: https://docs.oracle.com/javase/tutorial/java/concepts/inheritance.html. [Accessed 19 April 2016].

Default Methods in Java 8 and Multiple Inheritance. 2016. ProgramCreek.com. [ONLINE] Available at: http://www.programcreek.com/2014/12/default-methods-in-java-8-and-multiple-inheritance/. [Accessed 19 April 2016].