In this chapter we are gonna see if our software is really ready to be published or delivered, it has gotta be more than just the code you are making, it has to fullfill its actual purpose.
For starters when we launch our project to the real world wee may come with new issues by the same or new customers or users, meaning that our new user may have a different set of parameters and or environment which will make our project work differently. It would obviusly be better to know all of these cases before to solve it before it happens, but sometimes we can´t
When this happens the first thing we need to do is identify the problems that new users can have, this by removing variables of the enviroment that can chage our results. and later on plan the solution for this. for this stage you also need to use the use cases or maybe write some new ones, all this without forgettig stuff like delegation to improve the software protection
I usually don’t find much value in reading technology books that are more than a few years old. The industry changes so rapidly that most of the ideas and examples are already irrelevant. With this in mind, The Cathedral and the Bazaar by Eric S. Raymond should be outdated many times over. It was written in 1999. Before Y2K. 8 years before the iPhone. Before Wikipedia.
But this book is different. It’s not just about technology. It’s about a mindset around technology. In particular, it’s about the open source development mindset.
Broadly speaking, there are two main ways to create software – closed source and open source. Closed source usually entails a company creating a software program using in-house talent. The source code for the program is kept locked up so as not to reveal the magic behind the program. Open source development releases an original version of software into the wild and makes it possible for people around the world to contribute to and improve a piece of software.
In this book, closed source is described as a cathedral development model and open source as a bazaar development model. A cathedral is largely centrally planned. It takes a long time to create. It’s not very open to change. If you build the Notre Dame Cathedral on the Île de la Cité in Paris, you’re not going to pick it up and move it across the Seine if necessary.
Open source is described as the bazaar development model. The bazaar is lively and consists of a variety of buyers and sellers. If the bazaar is set up in an undesirable location, it can be moved to another side of the city in as little as a week. It’s flexible and can quickly be adjusted to meet the needs of the buyers and sellers.
I’m always amazed when I see closed and open source decisions presented to my clients. For example, a few years ago, one of my university clients was making the choice of what content management system to use for their website. One was a closed source option and the other an open source option. The closed source option cost $10k a website. A university puts out a ton of websites, so using the closed source option was costing them a ton of money. But it was also costing them a ton in lost functionality. At most, this closed source option had 10 developers working on the software. The open source solution was free to use and had thousands of people around the world continually perfecting it. I wrote more about this choice in this blog post
Eric Raymond had a great quote in this book about this choice (remember, this was back in 1999):
The logic is compelling; closed source code is an unacceptable strategic business risk. So much so that I believe it will not be very long until closed-source single-vendor acquisitions will be viewed as fiduciary irresponsibility when there is an open-source alternative.
It was very interesting to read this book because it came out before the creation of Wikipedia and WordPress, along with a variety of other open source projects. This book has been called a manifesto for the open source movement, a “shot heard around the world” that got people thinking about development in a new way. I recommend the book, even though it is 17 years old. Along with Hackers, it’s one of those books that helps you see the path we have taken with technology.
Unified Modeling Language—abbreviated as UML—is a graphical language officially defined by Object Management Group (OMG) for visualizing, specifying, constructing, and documenting the artifacts of a software system [106]. An artifact in software development is an item created or collected during the development process (example of artifacts includes use cases, requirements, design, code, executable files, etc.). UML offers a standard way to write system’s blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components [37]. Despite that UML is designed for specifying, visualizing, constructing, and documenting software systems, it is not restricted only for software modeling. UML has been used for modeling hardware, and is used for business process modeling, systems engineering modeling and representing organizational structure, among many other domains [125].
The first UML specification (version 1.1) was published by OMG at 1997. Since then there has been continuously ongoing work to improve both the language and its corresponding specification. Additionally, we should admit that UML versions 1.4.2 and 2.4.1 have been published under International Organization for Standardization (ISO) [44] and International Electronical Commission (IEC) [43] as a standard. In year 2005, the version 1.4.2 was published as ISO/IEC 19501:2005 [46]. Following in year 2012, the version 2.4.1 was published as ISO/IEC 19505-1 [47] and ISO/IEC 19505-2 [48]. You should ask—why there are two separate ISO/IEC standards for single UML version? The answer hides in fact that beginning with UML version 2.0 its specification was divided in two parts (i.e., two separate documents)—so-called Infrastructure and Superstructure. Accordingly, the ISO/IEC standard is based on this separation. But what a surprise—UML version 2.5 specification [79] again is a single document.
During the two major and a number of revision versions of UML, the definition of UML is evolving. UML version 2.4.1 specification [77,78][78][78] defines the language as follows: “UML is a visual language for specifying, constructing, and documenting the artifacts of systems. It is a general-purpose modeling language that can be used with all major object and component methods, and that can be applied to all application domains (e.g., health, finance, telecom, aerospace) and implementation platforms (e.g., J2EE, .NET).”
The UML originally was developed in middle of 1990s as a combination of previously competing object-oriented analysis and design approaches:•
Booch method by Booch [13],•
Object-Modeling Technique (OMT) by Rumbaugh, Blaha, Premerlani, Eddy, and Lorensen [105],•
A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous.
A use case (or set of use cases) has these characteristics:
Organizes functional requirements
Models the goals of system/actor (user) interactions
Records paths (called scenarios) from trigger events to goals
Describes one main flow of events (also called a basic course of action), and possibly other ones, called exceptional flows of events (also called alternate courses of action)
Is multi-level, so that one use case can use the functionality of another one.
Use cases can be employed during several stages of software development, such as planning system requirements, validating design, testing software, and creating an outline for online help and user manuals.
Bibliography
-Peter Zielczynski (May 2006). «Traceability from Use Cases to Test Cases». IBM developerWorks. – «Alistair.Cockburn.us – Structuring use cases with goals». alistair.cockburn.us. Retrieved 16 March 2018. -Pete Deemer; Gabrielle Benefield; Craig Larman; Bas Vodde (2012-12-17). «The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum (Version 2.0)». InfoQ. -Larman, Craig. Applying UML and patterns. Prentice Hall. pp. 63–64. ISBN 0-13-148906-2.
This phrase is the beginning of the chapter because as anything develops we always want more of it, some things we didn´t even knew we wanted. As the software develops or even when it is finished some of its requirements may change, and there are many reason for this, one can be that simply the customer needs something they didnt need before, or maybe they needed it before they just didn´t know,sometimes its just not quite good enough anymore.
Anytime this happens, requirements are modified or added we need to make the whole process again to make sure the new requirements dont mess up the old ones and that we can actually do it and work in a smooth way. And always remembering the customer is always rigth.
In software the only thing that is a constant, is change, software will almost never be finished nor at the first try nor at the first version, and you have to be careful and define in the best way to determine the use cases when you modify your proyect cause that is how you are gonna test and prove your proyect is well done and does exactly what it needs to do they way it needs to do it.
In this chapter, as the title says we saw how to gather the requirements to give the customer something as close as we can to what he needs, not what he says or thinks he wants.
The best way to do this is to do a list of requirements where the customer and project manager define explicitly what the software has to do, this way when you and the customer check the proyect you guys will have something to check it with like a rubric.
Antoher thing, is that sometimes the list is not possible because requiremnts are not explicit, so you need to, before you start working, define what would work and be useful for the client, for that you need to understand what the customer needs it for, also planning for things you may need to change or improve your proyect.
A way to do the last thing stated, is to do some cases of use, what could the user do in it and what should the result be, remembering to cover all the cases, includding alternate paths and things you will have to test later on keeping in mind you may need to correct add and or substarct things.
The Unified Software Development Process or Unified Process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP). Other examples are OpenUP and Agile Unified Process.
The Unified Process is not simply a process, but rather an extensible framework which should be customized for specific organizations or projects. The Rational Unified Process is, similarly, a customizable framework. As a result, it is often impossible to say whether a refinement of the process was derived from UP or from RUP, and so the names tend to be used interchangeably.
The name Unified Process as opposed to Rational Unified Process is generally used to describe the generic process, including those elements which are common to most refinements. The Unified Process name is also used to avoid potential issues of trademark infringement since Rational Unified Process and RUP are trademarks of IBM. The first book to describe the process was titled The Unified Software Development Process(ISBN 0-201-57169-2) and published in 1999 by Ivar Jacobson, Grady Booch and James Rumbaugh. Since then various authors unaffiliated with Rational Software have published books and articles using the name Unified Process, whereas authors affiliated with Rational Software have favored the name Rational Unified Process.
In 2012 the Disciplined Agile Delivery framework was released, a hybrid framework that adopts and extends strategies from Unified Process, Scrum, XP, and other methods.
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.[1] 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.
Bibliography
Kruchten, Philippe (2004). The Rational Unified Process: An Introduction (3rd Ed.). ISBN0-321-19770-4.
There are lots of things that can define great software, but some are more important than others, not meaning that we have to do some things and not the others, but meaning if we have to choose, there are somethings we would need to do first. To start, we need to pick which aproach we want, maybe we want our project to be strictly OO or we need our project to be well-designed, well coded and easy to maintain, reuse or extend or maybe we care more about what the customer sees and needs. This last 2 are the main things we need in a great software. If we were to put it on a list of steps or checklist we would have the followwing: First you need to make sure that it does whats the customer wants it to do, the you need to use the good practices in OO to add flexibility, and last but not least, you have to strive for a maintainable and reusable design, this last is maily cause you want your code to be easy to understand in case you need some debugging or you just want to ad new stuff.
Also we need to know how to look for problems, and for this we need to define our problem and then look in our code whats is wrong and update it when necessary being carefull not to change the things we did before if they mess with our 3 steps. 4 Very important terms we need to lear are, Flexibility, meaning pur code can be used for more stuff, Encapsulation, if we need to send stuff, its better to put it in a «Capsule» and send it to ensure that you wont lose stuff on the way, Functionality, if the software does not work… well you know what would happen, and last Desing pattern, you need to follow a pattern in your design if you dont code will be messy. We also need to make our applications strong and consistent to avoid or minimize bugs and problems, and if necessary make some objects delegate stuff to others.
Reflection
In this chapter i learned lots of good practices to keep my code object oriented, nice and neat. All of this in an easy way using OOA&D
SDLC or Software Developmet Life Cycle is the process that the application/projcet goes through, it includes analysis, planning, creating, testing and deploying (maintenance is also requiered), stages can repeat themselves, its not always a linear cycle nor circular, meaning you can go from any stage backwards if you need to. All of this applies to a range of hardware and software configurations.
More in depth, SDLC is a cycle, that allows or software to be developed correctly and systematicly, there are certain methodologies such as scrum which dont follow this cycle. This is because it has some strengths and some weaknesses.
There is also something called SAD or System Analysis and Design, «it interacts strongly with distributed enterprise architecture, enterprise I.T. Architecture, and business architecture, and relies heavily on concepts such as partitioning, interfaces, personae and roles, and deployment/operational modeling to arrive at a high-level system description. » (Wikipedia,2019)
Let me explain the process of a life cycle.
Analysis: The analysis stage includes 2 patrts, first we do the preliminary analysis where we need to know costs, benefits, weaknesses and if there is a better way to achieve the same result, after this we need to make a list of functional and not functional requirements, we need to specify what we need our project to do before we know how to do it.
Planning: At the planning stage we need to determine the documentation like process diagrams, pseudocodes, features, etc…
Creating:Here is were de coding takes place, where we make the proyect.
Testing: After completing what we think our project is we need to do several thing to ensure it is what we need, we bring all the pieces together and test it. We check for errors, bugs, and interoperability.
Deploying: After we are done testing we need to deliver the product, install it or do what ever is necesarry to have it running, here a second testing happens made by the client.
Maintenance: In case new functioalities are needed or existing ones need to be fixed we need to go through maintenance.
References:
-SELECTING A DEVELOPMENT APPROACH. Retrieved 17 July 2014. -Parag C. Pendharkara; James A. Rodgerb; Girish H. Subramanian (November 2008). «An empirical study of the Cobb–Douglas production function properties of software development effort». Information and Software Technology. 50 (12): 1181–1188. doi:10.1016/j.infsof.2007.10.019. -«Systems Development Life Cycle from». FOLDOC. Retrieved 2013-06-14. -Software Development Life Cycle (SDLC), PowerPoint – Powered by Google Docs -James Taylor (2004). Managing Information Technology Projects. p.39. -Geoffrey Elliott & Josh Strachan (2004) Global Business Information Technology. p.87. -US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT Chapter 1. Introduction. -Everatt, G.D.; McLeod Jr., R. (2007). «Chapter 2: The Software Development Life Cycle». Software Testing: Testing Across the Entire Software Development Life Cycle. John Wiley & Sons. pp. 29–58. ISBN 9780470146347. -Unhelkar, B. (2016). The Art of Agile Practice: A Composite Approach for Projects and Organizations. CRC Press. pp. 56–59. ISBN 9781439851197. -Land, S.K.; Smith, D.B.; Walz, J.W. (2012). Practical Support for Lean Six Sigma Software Process Definition: Using IEEE Software Engineering Standards. John Wiley & Sons. pp. 341–3. ISBN 9780470289952. -Kay, Russell (May 14, 2002). «QuickStudy: System Development Life Cycle». ComputerWorld. -Taylor, G.D. (2008). Introduction to Logistics Engineering. CRC Press. pp. 12.6–12.18. ISBN 9781420088571. -Control and Audit, Information Systems. SDLC (August 2013 ed.). Chapter 5: Institute of Chartered Accountants of India. p. 5.28. -Radack, S. (n.d.). «The system development life cycle (SDLC)» (PDF). National Institute of Standards and Technology. -Marakas, James A. O’Brien, George M. (2010). Management information systems (10th ed.). New York: McGraw-Hill/Irwin. pp. 485–489. ISBN 0073376817. -U.S. House of Representatives (1999). Systems Development Life-Cycle Policy. p.13. -Blanchard, B. S., & Fabrycky, W. J.(2006) Systems engineering and analysis (4th ed.) New Jersey: Prentice Hall. p.31 Post, G., & Anderson, D., (2006). Management information systems: Solving business problems with information technology. (4th ed.). New York: McGraw-Hill Irwin. -Blanchard and Fabrycky (2006). Systems Engineering and Analysis, Fourth Edition. Prentice Hall. p. 19. -Dr. Joahn Gouws (2007). Introduction to Engineering, System Engineering. Melikon Pty Ltd. -Cunningham, James. «HERC Maintenance». Fargo. XXI (North Avenue): 49. Retrieved 13 May 2009.
Esta es tu primera entrada. Haz clic en el enlace «Editar» para modificarla o eliminarla, o bien crea una entrada. Si lo prefieres, puedes utilizar esta entrada para contar a los lectores por qué has empezado este blog y qué tienes previsto hacer con él. Si necesitas ayuda, contacta con los simpáticos miembros de los foros de ayuda.
Juan Torres Blog 