Mastery 14 – OO and Agile

--Originally published at Sierra's Blog

Agile life cycle works like this:

agile

https://number8.com/common-mistakes-using-agile-method/

It is a new way to see the development team, Agile is flexible, doesn’t have guidelines, creativity is valued, there is freedom to fail.

Agile believes that the team is aware of their responsibilities and that they will the necessary and adequate things in order to accomplish their tasks.

Scrum adapts this beliefs in the development process, a sprint meeting is about the desired output, not about the how since the software developers are the experienced members of the team that actually knows what should they do to correctly get the output.

This methodology also allows that the whole team decides what to do, there’s not a leader selecting tasks among subordinates. Nonetheless, there is a leader role called the Scrum Master which will led the team and supervise if they are following the scrum methodology correctly. In addition, there’s one extra position called the product owner which represents the business, customer or user and its main job is to led the team towards developing the correct tool.

sprints are time segments that could last between one week and no more than one month.

At the start of the sprint, there is a meeting were the objectives of the sprint are selected and the team members commit to aboard them. At the end, a registry that contains the tasks that are going to be done during that sprint is generated.

After the initial meeting, the team participate daily in a 15 minutes long meeting to keep track of who is doing what and what has already been done.

 

References

https://number8.com/common-mistakes-using-agile-method/

http://www.mountaingoatsoftware.com/agile/scrum

Lisp: Good News, Bad News, How to Win Big

--Originally published at Hackerman's house

Lisp: Good News, Bad News, How to Win Big is an essay written by the American computer scientist Richard P. Gabriel in 1991. At that time, he worked a lot on the Lisp programming language. The main topic of the essay is the advantages and disadvantages of that programming language, and how accepted it was by the programmers, as well as some of its uses.

Lisp’s successes

Standardization

One of the biggest successes in Lisp is that there is a standard Lisp called Common Lisp. This wasn’t considered the best Lisp but it was the one ready to be standardized. There was a Common Lisp committee formed by users of different Lisps across the United States; Common Lisp was a coalescence of the Lisps these people cared about.

Performance

It used modern compiler technology of that time, so compared to older Lisps it had a very good performance. It also had multitasking and non-intrusive garbage collection, both were great features that weren’t possible before that time.

Good environments

The environments had a lot of good qualities like windowing, fancy editing and good debugging. Almost every Lisp system had these kinds of environments; a lot of attention had been paid to the software lifecycle.

Good integration

Lisp code would coexist with C, Pascal, Fortran and other languages. Lisp could invoke them and be invoked by them. This was useful to manipulate external data and foreign code.

Resultado de imagen para c language

Object-Oriented programming

At the moment it had the most powerful, comprehensive object-oriented extensions of any language. This was really important because OO was the new trend.

Lisp’s failures

The rise of worse is better

One of the biggest problems of Lisp was the tension between two opposing philosophies. The right thing and worse is better. Lisp designers used the right thing, while Unix and C

Resultado de imagen para hard to program
Continue reading "Lisp: Good News, Bad News, How to Win Big"

Object Oriented and Agile

--Originally published at Newbie Programmer

The Agile software development it’s a set of methods and practices expressed in the Agile Manifesto, this solutions evolve through the collaboration of teams in their context, the manifesto is based in twelve principles, customer satisfaction, welcome changing requirements, software delivery frequently, daily cooperation between people and developers, face to face communication, working software is a measure of progress, sustainable development, attention to technical excellence and good design, simplicity, best architecture, requirements, and design for emerging teams and the teams reflects how to be more effective. One of this type of methods are the Extreme Programming.

The extreme programming it’s an intense methodology that is focused on improving the quality of the code and to adapt to a rapidly change of the customer requirements, as a part of agile software development it has frequent releases and short development cycles to adjust to the new requirements more quickly, in this methodology we can found things like code revision, this is done for avoid programming features that are not needed, this gives the code simplicity and clarity that is moldable for changes, for doing this is a must a frequent communication with the customer and developers, the name was taken from the software practices that are taken at extreme levels.

38891650224_6ec3e98246_k.jpg

Agile 101

Extreme Programming: A gentle introduction

Code revision

--Originally published at Hackerman's house

Code review (also called peer review) is a software quality assurance activity in which one or more developers check a program by reviewing and reading parts of its source code. At least one of the reviewers must not be the code’s author, the purpose of this is to have another point of view, and different ideas to judge the code in a more objective way. The people performing the checking (except for the author of the code) are called reviewers.

Resultado de imagen para peer programming

The main objective of this process is to detect quality problems, although it can be used to reach more goals. Better code quality: improve the readability, maintainability and understandability. Finding defects: finding performance problems, security vulnerabilities among other flaws. There are many more goals that can be achieved through this process, but the general idea is to create better software and to avoid errors.

Types of review processes

Formal inspection

This is the traditional method of review. Software developers attend a series of meetings where the code is reviewed line by line. This method has been proven to be very effective in finding defects in the code.

Regular change-based code review

This is a more lightweight type of code review. This type uses something called Version Control, it is basically a system that records changes to a file or a set of files over the time. Github is one of the most popular applications that does this; the developers are constantly checking the changes made by every member of the team. They can see who is the responsible for the code and they can check it, but they do not dedicate the time to read it line by line.

Resultado de imagen para git

Source:

https://en.wikipedia.org/wiki/Code_review

OO and Agile

--Originally published at Hackerman's house

There are lot of agile methodologies, each one has its own practices and characteristics, but in general they share the same philosophy. These ideas were expressed in the Manifesto for Agile Software Development.

Resultado de imagen para agile manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The origin of these methodologies arises in 1990s in a world shaped by two major influences: Object-Oriented programming replacing procedural programming as the programming paradigm favored by the industry; the other influence was the rise of the internet. This situation made that the requirements started to rapidly change and shorter product life-cycles were required; this was incompatible with the traditional methods of software development. There was a need for new methodologies that could adapt to this new world.

Extreme programming

Extreme programming is a methodology which is intended to improve software quality. It advocates frequent releases in short development cycles; it uses checkpoints at which new customer requirements may be added. Other main elements of this methodology is pair programming, extensive code review, unit testing of all the code, avoiding to develop features until they are actually needed, and one of the most important ones is constant communication between the client and the programmers to assure all the requirements are being fulfilled. The origin of the name is that traditional software engineering practices are taken to extreme levels, such as pair programming that is basically extreme code review.

Resultado de imagen para extreme programming

Sources:

https://en.wikipedia.org/wiki/Extreme_programming

http://agilemanifesto.org/

Testing in Object-Oriented

--Originally published at Newbie Programmer

Testing is one of the most important parts in development, because we need to make sure we are doing right and to find errors we may have and how to solve them, and this gives to the code more stability, scalability, etc.

Testing Object-Oriented Systems

Unit Testing

In this part the classes are tested individually, this test that the attributes, methods, and interfaces have no errors and are implemented as designed.

Subsystem Testing

This is testing parts of the system, it involves testing the interaction with other subsystems and outside ones, this are used when a new version is released.

System testing

This is for testing the system entirely to know if every aspect is doing well, and its used when new features are released.

Object-Oriented Testing Techniques

Grey Box Testing

There are different test cases designed for texting object oriented that are called grey box, and some of this are: state model-based testing, use case-based testing, class diagram-based testing and sequence diagram-based testing, this test cases are based in the tools of object oriented discussed in UML.

Techniques for Subsystem Testing

Thread based testing: test each class that need a single use case.

Use based testing: Each level of hierarchy its tested, the test begins with the individual classes to small modules and finally the major subsystems.

Categories of System Testing

Alpha testing: It’s the product that is testing in the organization that develop the application.

Beta testing: A select group of operated customers.

Acceptance testing: This is by the customer before accepting the product.

25214666645_f3da198bf9_k.jpg
SpaceX Dragon Propulsive Descent Landing Test

OOAD – Testing & Quality Assurance

 

 

 

Verification and Validation

--Originally published at Newbie Programmer

This are two different concepts that can be similar, but they are different, this are used in the testing part of the development. Verification: is when you evaluate the products where it stills in development and it’s not a final product, this help to know if the product its built according to the requirements and Validation: this is done when the development is finished and it’s to make sure that the product is doing what is supposed to do and supply the customers’ requirements.

39201856305_af919293e0_o.jpg

Each product that we use needs to pass an international standard, this international standards are the result of different organization to suit for conditions of quality, materials, testing, that are labels that show us that the product that we are using its proved by a series of tests and to give to the customer  trust , for example in software we have the ISO/IEC/IEEE 29119 that is a series of five international standards for software testing or parts of testing, this defines the concepts and definitions, test processes, test documentation, test techniques and keyboard driven testing.

Concepts and definitions

This part one defines the definitions, concepts of the testing, and how to apply this to the other parts of the standard, this part has everything you need to know about the testing process.

Test Processes

The part two defines the test processes that can be used by the organizations that approve this standard, and this is based in a three-layer process that covers: organizational test specifications, test management and dynamic testing.

In this the risk-based approach is used, because this practice allows to focus in the most important features and quality attributes of the system that is testing.

Test Documentation

The part three as the name says its documentation. This is the documentation of Continue reading "Verification and Validation"

Code Revision

--Originally published at Newbie Programmer

Code revision as the name says it’s when something, someone or you check the code if its correct or can have a better implementation or to make it expandable. These practices can have a lot of advantages or disadvantages depending of the people that are going to help us for this revision, this theme is part of the agile development that is based in iterative models when the requirements are changing during the development of an application, one of the most common code revision practices are pair programming.

Pair programming it’s a practice where two software developers combine effort in a workplace, one person works in the code and the other think how to improve or the next things that are need to be coded, the advantages of this is that the developers maintain focus of the things that they need to do, the code quality is better, if one developer is stuck the other can solve that more quickly, it’s helpful for beginners to learn the knowledge of another person and they improve their social abilities, but the disadvantages are that the developer with more experience can find this practice tedious and they prefer to work alone, or if they don’t have the same schedules in the day and they can’t be in the same place to work.

In conclusion code revision is very helpful for those persons who don’t have a lot of experience coding, but it’s important to choose the right person to do this.

6424274071_65b40d3956_b.jpg

Photo by Breyten Ernsting

Classes to Code

--Originally published at Newbie Programmer

To convert the design of a diagram class to code in the object oriented paradigm its easy because UML in this case is made in an object oriented design so the design it’s the visual view of the code, and depending of the quality of the diagram, because if we see the structure of a class diagram is similar of how a class in object oriented is done, in the design we can see the name of the class, the attributes and type of variables, the methods and the inheritance between classes.

I wrote before the benefits of the class diagrams, but we have to consider that in this case UML is object oriented for instance only the object oriented languages can be easily to understand in UML, we need to avoid to make a mix of design and programming languages, for example to design code for COBOL we don’t use UML, we can use the UML for another languages but is not recommended for doing code but it is for only design, because UML is useful for having a big picture of the instances, relationships and how the system works.

To conclude, class to code are easy if we use the same paradigm, the trick is to choose the programming language that is our favorite and make a design is always a good idea but in preference for the same paradigm.

class diagram template for atm system