There is no perfect methodology for software development. All approaches, both adaptive and discipline-oriented, have a lot of pros and cons. Discipline-oriented methodologies are criticized due to its inflexibility, slow decision-making processes, the inability to adapt to change during the project, and the excessive production of documents.
Even Extreme Programming has its weaknesses. One of them is the requirement that the client works with a development team. Sometimes clients are very busy and cannot meet these requirements. In this case, XP would lack written documentation, which makes it difficult to implement a change in a complex system. Also, another disadvantage of XP is that it is too short for project planning.
CCNA Training – Resources (Intense)
The objectives that guided the development of the methodology XPrince were designed to combine adaptability with an XP process that enforces discipline and methodology known as Prince2.
Let’s go – you have a project?
Unfortunately, all of us have repeatedly found ourselves in a situation where we install computers, networks, and systems, and then train the users, but while our solution proved to be very useful for them, often it ends up unused or unpopular. The implementation of all projects in computer science involves making a number of technical processes: gathering requirements, developing software, designing a database, developing documentation, training users, installing equipment and systems, etc. This makes it relatively easy to forget a very important aspect of all projects: managing them.
In this mysterious concept lies the proper organization of work and its implementation in a manner consistent with the expectations of our client or Sponsor. After the business context is the second area of interest of Project Management: how to make our work end at the scheduled time, provide the product ordered by the user, and, in addition, not cost more than what’s allocated by the sponsor.
The advancements in the theory and practice of Project Management have been very significant, and it is one of the fastest growing social disciplines. We continuously publish new books and articles, have numerous professional associations, and do a lot of practical research. All these measures are aimed at one goal: to do projects better, more efficiently, more effectively, on time, and not too expensive.
Like signposts on the road are so-called Project Management methodologies, which are more or less formalized sets of rules, policies, practices and techniques of project management. The world has already created a lot of them, but after a closer look, one can easily find a common element in all methodologies: the satisfaction of customers and users, as well as ourselves. Projects should always be a warning to us like the bitter statement of one experienced professional: “Throughout my long career, I’ve contributed a lot of great information, but done useless projects.”
What features do a project carried out in conjunction with the methodology XPrince contain?
I looked at projects carried out through the methodology XPrince on two points. The first is the point of view of the person who manages the project. It seemed to me that this is the Prince2 methodology. But when I started to write code with many teams working with XPrince, it turned out that this is a project carried out according to the guidelines of the lightweight Extreme Programming methodologies.
XPrince uses all good software development practices. System requirements are described using the cases of use. Assessing and estimating software complexity is estimated using function points. The system architecture is analyzed by the method ATAM. Software quality standard shall be square. Also used was the GTD method.
The requirements are software documents with Use Cases. This allows us to design the system as a black box. We do not know the internal structure, but we know all reactions to stimuli. Writing use cases shows what the system is supposed to do, but does not show how to do it.
When we start designing, the use of use cases makes sense, but they never determine what we get in the final version. Activities can be repeated in different processes, but rarely does software support all steps in the process. Process modeling using Use Case is to understand and test what is really going on in the service system.
The use of function points
Function points are independent of programming language, platform, and application equipment. Scoring functions is always the same. Function point analysis provides an ideal mechanism for tracking and monitoring the scope of the project. At the end of the software development process, we can count function points. They define all actions taken in order to analyze and develop the code. If the project grew, it means that the number of function points has been poorly chosen. If the number of function points was reduced, it appears that improved communication with the user has occurred.
Architecture Trade-off Analysis Method
Why do I like ATAM? Thanks to ATAM methodology, I am able to accurately gather quality requirements when creating documents, which are useful for the initial creation of the architecture, and thus fully documents all architectural decisions. You can very quickly identify risk at the beginning of the software life cycle.
ATAM encourages better communication between the parties involved in the process of software development. It commands gathering the people interested in the project to analyze all business and qualitative factors, which will be used to create scenarios. Scenarios are then used to create architectural solutions and decisions to quickly develop an analysis of possible trade-offs, system vulnerabilities and risks in the process. Then you can quickly transform this analysis, and depending on the motives, start the process of software development and their impact on the project RISK. Then you repeat the process.
Getting Things Done
It is a disciplined methodology consisting of five major steps. The first is collecting. This is the process of collecting all the notes, plans and ideas in one space. Collecting allows you to transfer everything from the head to a specific location. It is necessary to regularly empty the cart through the process of analysis.
The second step is analysis. Ro is close decision procedure. The analysis begins with the LIFO principle, i.e. it starts from the last case. How does it work in practice? It decides whether a case requires some action. If not, it moves this to the archive or to other defined tasks on the matter. If the task requires two minutes of work, it must be done immediately. The basic rule is, if you do something in less than 2 minutes, do it right away and do not move this task to the next stage.
Another of the rules is to organize. Organizing tasks resulting from the previous step ensures the correct organization of work. If the next task is the smallest piece of work and is ready to be done immediately, it should have no internal steps. Tasks should be organized according to the context of their performance, so that when you perform one task, you have the next on hand, and more.
Each project is a “hole” in the commitments that require the implementation of more than one task. Each project should be assigned at least one task.
The next step is to review. An overview of the inspection is the responsibility of the daily task lists and calendar. At least once a week, Allen recommends a thorough review process of the affairs of the shopping cart and all tasks and projects.
The fifth stage is the realization. The implementation includes the performance of work that was planned, but also includes the execution of unplanned work. The implementation also includes planning work.
One source method popular for its flexibility, GTD provides processes which can be implemented in many ways. Therefore, a method often uses life-hacking supporters who adapt to the existing tools (text files, email clients, web-based wiki software for time management) or can create a new one. There are also some ways to use GTD based solely on paper materials, and there are now many computer programs supporting the work of the GTD method.
What are the strengths of the XPrince methodology?
XPrince is an agile methodology. It has all the basic assumptions of the XP methodology. It is focused on producing a working product as soon as possible. All stages of the production are short. Change management is carried out throughout the duration of the project. This allows the client to quickly receive subsequent versions of the product and have constant control over its scope.
XPrince also allows you to control the product on four levels. The first is to control changes to the project, the second is to control the risk in the project, the third is quality control, while the fourth is the job of the project manager, using all the features of PRINCE2 methodology.
XPrince maintains optimal level of technical documentation. The requirements are documented using the system and use cases using UML modeling. Every programmer knows these methods because they are proven and popular, and they reduce development time.
The methodology is a simple and efficient organizational structure. With XP, there is such a thing as a clear division of roles in the process. The hierarchy of the people involved in the project is optimized, so the responsibility for parts of the process is divided into team members.
XPrince introduces the main role of the analyst, who is responsible for all business drivers, and the architect, who is responsible for technological factors. The superior of the two specialists is the project manager, who uses project risk management and is guided by signals from both specialists.
The PRINCE2 methodology has taken another feature: the structure of the project is transparent to management. XPrince organizational structure helps senior management to look at the project. Management of the project, as a decision-making body, is separated from the daily work in the project and controls it on the basis of information from the project manager. In addition, the accuracy of the information provided to the project manager is verified by an inspection of the project (like the PRINCE2 methodology).
XPrince uses all the good programming practices. Version management, continuous integration, unit testing, acceptance testing, and implementation lead to practice tests that ensure product quality. The XP has also been taken to develop test solutions that XPrince uses at the beginning of the project, under development architecture. Test-driven development (TDD) is a software development technique that relies on the repetition of a very short development cycle: first, the developer writes a failing unit test case that defines a desired improvement or new function, and then he produces code to pass that test before he finally re-factors the new code to acceptable standards.
Agile methodologies are not conducive. Bureaucracy projects for a long time were devoted to the analysis and description of requirements, and it became too late to start coding. Creating applications starts relatively late and a lot of things come out in the wash. “Business” fears suddenly come to light, with half of the programmer’s work becoming pointless.
With agile methodology and experience, we can replace the five consultants and the two managers of the project. The application creation time will be reduced, the quality will be even better and the end product will be more suited to customer requirements because a lot of requirements vary during application development. Eliminating inaccuracies is why we created XPrince.
Is it worth using XPrince? Of course it is. The methodology takes into account all possible XPrince business concerns. The software is developed quickly, and the entire risk of the project is always under control. But it’s not an ideal methodology for everyone. XPrince is a tool, and like any tool, if it does not work, it can be removed and replaced with another.
Try XPrince, because it is really worth it, but if you have something else that’s equally good, stay with it. The tool may not be the best or the worst, but the tool must always be sufficient.