tag:blogger.com,1999:blog-73633455642343664912024-03-12T18:13:17.855-07:00The thoughts of a DummyIDummyhttp://www.blogger.com/profile/11500622199898795501noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-7363345564234366491.post-83498994644231306952010-04-22T01:47:00.000-07:002010-04-22T01:50:40.405-07:00How to choose a UML modeling tool?Choosing an UML tool is a complex and time consuming task. The decision on the tool to be selected should be based on an in-depth analysis of the present and future use of the tool. The following list presents the criteria that are commonly used when evaluating an UML tool. <br />
<strong>1. collaborative use of the tool</strong><br />
Real-life projects usually require several engineers working together on the same UML mode, so the tool must have support for collaborative work. The support for collaboration can be achieved in several ways, most common being the following two: repository support<br />
UML models are stored in a repository that provides model sharing and concurrent model development. <br />
- integration with configuration management tools that support collaborative work<br />
The support for sharing and concurrency is deferred to a configuration management tool. This alternative is preferred because the model is stored “close” to the code and other related artefacts (test cases, documents, etc). Additionally, the overhead required to manage the UML models repository is eliminated. <br />
The support for collaborative use of the UML tool requires support for versioning model elements, for comparing different versions of a model element and for merging concurrent versions of the same model element. <br />
<strong>2. integration with configuration management tools</strong><br />
Best practices for software development require the development artefacts (documents, code, tests, models, etc) to be stored using a configuration management (CM) tool. The level of integration may range from exporting the model in XMI format and storing the XMI under configuration management control to advanced integration that allows direct connection between UML and CM tools (usually based on plugins), including check in/check out of model elements, model synchronization between workarea and CM tool database, model elements versioning, etc.<br />
This criterion should be analysed in conjunction with collaborative use support criterion.<br />
<strong>3. round-trip engineering</strong><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Round-trip engineering is the ability to generate code from UML model (forward engineering) and to generate the UML model from the code (reverse engineering). There are multiple levels of support for round-trip engineering, ranging from generating method stubs from class diagrams or updating the method description in the model when the method signature is changed in code, to full automatic synchronization between model and code.</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Most of the UML tools offer an intermediate level of support for round-trip engineering, some tools offering one way engineering only. Full automatic synchronization between model and code is provided by highly specialized tools only; the model and the code have to adhere to restrictive rules to allow this type of synchronization.</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><strong>4. generation of documentation from model</strong></div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Many engineers working with an UML model require only read-only access. The UML tool should provide the capabilities for generating easily accessible static views of the model (usually HTML and PDF formats are used for generating the static view). These static views should be as close as possible to the tool view of the model from the point of view of navigation, display and informational content.</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">An UML model contains a significant amount of information that usually has to be presented in other documents like requirements documents, design documents, etc. Some of the modeling tools have the capability to generate documents with customisable format and content. This feature is valuable when the model contains enough information so an almost complete document can be generated. </div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><strong>5. UML standard support</strong></div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">UML standard is vast and complex and although most of the tools claim full support for an UML release, probably no tool really does it. Real life shows that full support for UML standard is not required. Therefore, when conducting an evaluation for an UML tool, the evaluation team should decide on a subset of UML standard that is required to be supported and the evaluation should be conducted for this subset. </div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><strong>6. diagramming features</strong></div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Ultimately, an UML tool is used for drawing diagrams and the ease of creating diagrams is of top importance when evaluating the tool. Features like auto-completion, quick-pick lists, tool-tips, copy-paste for model </div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none; text-align: right;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><span><img alt="" border="0" height="1" src="http://www.assoc-amazon.com/e/ir?t=thethough-20&l=bil&camp=213689&creative=392969&o=1&a=6130370717" style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none; margin: 0px; padding-bottom: 0px! important; padding-left: 0px! important; padding-right: 0px! important; padding-top: 0px! important;" width="1" /></span>elements, etc should be considered for assessing the diagramming capabilities.</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">The criteria described above should be considered in the context of the forecasted use of the UML tool. One criterion of the above ones may not apply, other may apply partially, others may be weighted differently. This list describe only the most common criteria, but other relevant criteria for selecting the UML tool (e.g. data modelling, multi-platform support, model analysis features, etc) should be considered too.</div><div class="separator" style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none; clear: both; text-align: center;"><a href="http://www.amazon.com/UML-Tool-Application-Software-Modeling/dp/6130370717?ie=UTF8&tag=thethough-20&link_code=bil&camp=213689&creative=392969" imageanchor="1" style="clear: right; cssfloat: right; float: right; margin-bottom: 1em; margin-left: 1em;" target="_blank"></a></div>IDummyhttp://www.blogger.com/profile/11500622199898795501noreply@blogger.com1tag:blogger.com,1999:blog-7363345564234366491.post-35576937741432049982010-04-16T06:59:00.000-07:002010-04-16T07:00:56.566-07:00How to define a software development life cycle?Defining a software development lifecycle (SDLC) is a complex task, but it can be done by following several simple steps:<br />
1. clearly define the scope and purpose of the SDLC<br />
The scope and purpose should be documented and presented to the management of the organization and to the people that will be affected by the SDLC. Getting a wide acceptance for the initiative is probably the most important factor for success.<br />
2. establish a strategy for SDLC definition using one of the following commonly used ones:<br />
- SDLC improvement<br />
- SDLC reengineering<br />
- new SDLC adoption<br />
The strategy should be chosen based on the desired magnitude of the change (SDLC improvement has the lowest change magnitude, new SDLC adoption has the highest magnitude), on the people available to drive the initiative, on the time constraints, on the acceptable risks for the SDLC definition project, etc.<br />
3. define and document the SDLC<br />
Whenever possible use graphical notations to document the processes that make up the SDLC.<br />
4. validate the SDLC for several pilot projects<br />
It’s a good time to see what is working, what have to be fixed or enhanced and to get the success storied to be later used for marketing the new SDLC.<br />
5. release the SDLC<br />
All the people that will be affected by the new SDLC will have to attend extensive trainings to get both a general understanding and a job specific understanding of the SDLC.<br />
6. continuously improve the process<br />
SDLC definition is a never-ending task so it should be continuously improved an d adapted.<br />
<br />
Throughout the SDLC definition project, communication plays a vital role for the overall success of the initiative. All the people that will be affected by the new SDLC should be kept in-loop with details on the progress and on the new SDLC. They should be constantly asked for feedback.<br />
Whenever possible, reuse! A lot of things have been discovered and documented about software development processes so instead of re-investing the wheel check if it’s not already available. ISO standards like ISO12207 and ISO15288, standard process models like Waterfall Model, V-Model, Agile Models, etc process improvement approaches like CMMI, etc, should be consulted while defining the process.<br />
<br />
Please check some SDLC secrets in <span><a href="http://www.amazon.com/SDLC-100-Success-Secrets-Methodologies/dp/1921523158?ie=UTF8&tag=thethough-20&link_code=btl&camp=213689&creative=392969" target="_blank">SDLC 100 Success Secrets - Software Development Life Cycle (SDLC) 100 Most asked Questions, SDLC Methodologies, Tools, Process and Business Models</a><img alt="" border="0" height="1" src="http://www.assoc-amazon.com/e/ir?t=thethough-20&l=btl&camp=213689&creative=392969&o=1&a=1921523158" style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none; margin: 0px; padding-bottom: 0px! important; padding-left: 0px! important; padding-right: 0px! important; padding-top: 0px! important;" width="1" />.</span>IDummyhttp://www.blogger.com/profile/11500622199898795501noreply@blogger.com0tag:blogger.com,1999:blog-7363345564234366491.post-77310883892324788992010-04-15T06:27:00.000-07:002010-04-15T06:29:04.866-07:00The "unknown" and effort estimation for a software projectsThe definition for effort estimation that I like the most is the following one from Wikipedia:<br />
"....effort estimation is the process of predicting the most realistic use of effort required to develop or maintain software based on incomplete, uncertain and/or noisy input"<br />
Starting from this definition, it's obvious that any estimation is based on "unknown" - sometime it's a <span style="font-size: large;">big</span> "unknown", sometime it's a <span style="font-size: x-small;">small </span><span style="font-size: small;">one, but it's always present (if it's not present it's not an estimation). Mathematically speaking, the reliability of the estimation is inversely proportional with the size of the "unknown", so to determine the reliability of the estimation you have to quantify the "unknown". </span><br />
Like the devil, the "unknown" has many faces - it may be a missing or incomplete requirement, a new technology, a set of open points and assertions that have to clarified/confirmed, a changing project team, etc.<br />
One thing to remember is that the output of the estimation process must be represented by a prediction for the effort accompanied by a list of factors (the "unknown") that influence the predicted effort and a reliability indicator of the estimated effort.IDummyhttp://www.blogger.com/profile/11500622199898795501noreply@blogger.com0tag:blogger.com,1999:blog-7363345564234366491.post-76725775329862233682010-03-30T04:39:00.000-07:002010-03-30T07:45:29.826-07:00Effort estimation for software development - the agile wayEstimating how long it will take to develop a software product is hard task. There are several approaches to be considered for effort estimation:<br />
1. expert estimation: the figures are produced through a judgement process by experienced people<br />
2. formal estimation methods: the figures are computed in an algorithmic way, usually based on historical data and on the parameters of the project to be estimated<br />
3. a combination of the previous methods: some activities and tasks are estimated by experts, other using formal methods.<br />
Historically speaking there are no studies that prove beyond doubt that one approach is better than the other or a method that is superior to others. Ideally each organization should choose the estimation method(s)that best fit the types of projects to be estimated.<br />
I personally prefer expert estimation methods because are lightweight and additionally I tend to give credit to a person instead of an algorithm. On the other hand I don’t like "wild guessing", even if an expert is guessing. Considering this, my favourite estimation way of estimating is the following agile method:<br />
1. decompose the project into phases, activities, tasks (i.e. work break down structure)<br />
2. classify each task by complexity (e.g simple, medium, complex) and size (e.g. small, medium, large)<br />
Note: there may be more complexity and size levels, but usually 5 is the upper limit.<br />
3. define for each complexity-size category the estimated time for completion ( this should not be "wild guessing", but an estimation based on experience :) )<br />
4. aggregate the estimations for tasks in a bottom-up manner to get the project estimation.<br />
One thing to remember is to revisit and refine the estimates as the project progresses, assumptions are clarified, open points are closed and more information is available.<br />
<iframe align="left" frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?t=thethough-20&o=1&p=8&l=bpl&asins=0596527675&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="align: left; height: 245px; padding-right: 10px; padding-top: 5px; width: 131px;"></iframe><iframe align="left" frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?t=thethough-20&o=1&p=8&l=bpl&asins=0131111558&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="align: left; height: 245px; padding-right: 10px; padding-top: 5px; width: 131px;"></iframe><iframe align="left" frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?t=thethough-20&o=1&p=8&l=bpl&asins=0735605351&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="align: left; height: 245px; padding-right: 10px; padding-top: 5px; width: 131px;"></iframe>IDummyhttp://www.blogger.com/profile/11500622199898795501noreply@blogger.com2tag:blogger.com,1999:blog-7363345564234366491.post-43950817049652256642010-02-03T08:04:00.001-08:002010-02-05T05:19:05.749-08:00What is sofware development?<div>Software development (SWD for short) is the technical and artistic act of creating software. Althouhg many people think of SWD as beeing the same with computer programming, it is a more complex human activity that ususally includes research, development, training, maintenance, re-engineering, overall management, etc. SWD is ususally conducted based on a development methodology that best fits the purpose of developing the software product . The development methodology defines proceses and methods that, when followed, ensure the successful completion of software product creation. </div><iframe align="left" frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?t=thethough-20&o=1&p=8&l=bpl&asins=0596527357&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="align: left; height: 245px; padding-right: 10px; padding-top: 5px; width: 131px;"></iframe><iframe align="left" frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?t=thethough-20&o=1&p=8&l=bpl&asins=0735619670&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="align: left; height: 245px; padding-right: 10px; padding-top: 5px; width: 131px;"></iframe><iframe align="left" frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?t=thethough-20&o=1&p=8&l=bpl&asins=1556158238&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="align: left; height: 245px; padding-right: 10px; padding-top: 5px; width: 131px;"></iframe>IDummyhttp://www.blogger.com/profile/11500622199898795501noreply@blogger.com0tag:blogger.com,1999:blog-7363345564234366491.post-50864461425451680282010-02-03T07:35:00.000-08:002010-02-03T08:03:15.506-08:00It's alive ... my blog!!!Today I've started my blogger life, few clicks and I'm free to share my thoughts with the citizens of the blogosphere. Mathematically speaking, the set of citizens interested about my thought is probably an empty set today :), but, who knows, probably the situation will change over time!<br /><br /><br />PS: I hope my blog will not die youngIDummyhttp://www.blogger.com/profile/11500622199898795501noreply@blogger.com0