RSS Toggle Comment Threads | Keyboard Shortcuts

  • Mike 3:43 pm on March 1, 2008 Permalink | Reply  

    Software Engineering Goals 

    I talk a lot, in conversation, about the software engineering goals. I don’t know who officially defined these as the goals of software engineering, but this is what the mountains of documentation that I was required to read and be tested on in the branch of the military that I served in defined as the “Software Engineering Goals.” So, since these have stuck with me over the past many years, and because I talk about them, and want to relate them to my previous post I thought now would be a good time to introduce them.

    They are, modifiability, understandability, reliability, and efficiency.

    Modifiability

    Modifiability is the hardest goal to attain, and it’s even harder to measure. Modifiability is controlled change to the software in which some parts are altered without increasing the complexity or obscuring the logic that has already been established. There are two reasons you might have to modify programs: to change the system due to a change in the original specifications or to correct an error made earlier in the development.

    Whenever you’re involved in designing a software system, you must try to structure it so that the logic is clear and consistent. Then, software can be modified effectively without increasing the intricacy of the original structure. As a maintainer, or one who is modifying the code, it is important that you follow the rules that have been established, and strive for consistency among that code base, even if the style that the code is in, is not your own.

    Understandability

    Understandable code is crucial in managing complex systems. Software that’s easily understood acts like a bridge between the problem and its solution. Understandability depends on the programming language: one that uses “English-like” constructs and control structures is more readable, making it easier to express design concepts.

    Understandability can also depend on things like design patterns, and a well defined domain. Understandability could also be minor things, like using a variable i vs index, or id vs userId.

    Reliability

    Reliability is critical for any software system that must operate for long periods without human intervention. Reliability is important in any software that is expected to be available 24×7, such as your typical public web application, or atypical nuclear power plant where the cost of failure is too great to allow anything less than the highest reliability possible.

    Efficiency

    The software system is efficient when it operates using available resources optimally. Resources can be divided into time resources and space resources. If the system must respond to real events, efficient use of time resources becomes critical. If space resources are important, such as in an automobile, efficiency of space resources can become more critical. You should use your judgment to select which resource to accompany each individual application.

    So there they are. I, and we are 72 Miles write web applications, typically with Java, so, given the nature of web development, I focus on Modifiability and Understandability, followed closely by Reliability. Efficiency isn’t always a huge concern, until an issue comes up.

    Here is an extended list of goals, that I frequently lookup.

    So how can you use Software Engineering Goals to help make the ‘better’ decision? Thats the next post…

     

    • rooloucouro 9:12 pm on December 19, 2008 Permalink

      good resource, please continue

  • Mike 10:18 pm on February 22, 2008 Permalink | Reply  

    There is no “right” or “wrong” 

    MySQL or Microsoft SQL Server? Should we use Factories in our code? What about static methods? What are the right answers?

    As software developers, our goal is to produce working code that contributes to a software system or application. How we get to that working system could take many different paths. There is an infinite number of routes to that working software, and any number of decisions along the way could have gone the other way and you could still end up with working code. So how is it, that we can say that there is a right way and a wrong way to write some method, or there is a right and a wrong framework, or even a right and a wrong language for any task?

    The answer is that there is no right or wrong way to do most any thing in software development. There is, however, a better way and a worse way. That is to say, there are some decisions that you make along the way that will make your software better, and some decisions that will make it worse?

    Better how and worse in what way?

    Better and worse are subjective terms, but generally “better” software is easier to maintain, preforms better, is easier to read and understand, more reliable, and improves upon all of the other software development goals. (By the way, cyclic dependencies hurt a software system’s goals read more…)

    So whats the point? The next time you’re faced with making a decision, or learn of a decision that someone else has made, don’t judge the decision as right or wrong. Understand that both options, or many different options are all good solutions, but that some are better and some are worse fits for the software that is under discussion.

    What does this mean for us at 72 Miles? Once we grasp this simple concept, we’re able to produce code faster, by not agonizing over every decision. No matter what decision is made, we are one step closer to a product that users can get their hands on, and after all, thats why we write the code. In the web applications that we write, most any aspect of any of our software can be refactored, removed, or replaced in the future, once an alternative is discovered.  I think this is referred to as being agile.

    So the question is, should we use factories in our code?

     

    • onur gumus 2:00 pm on February 27, 2008 Permalink

      postgresql is better period !

  • Mike 11:24 pm on February 10, 2008 Permalink | Reply
    Tags:   

    architecture-rules-2.0.3 

    Released architecture-rules-2.0.3 last month.

    Changes

    • issue-23 determine which dependencies are optional usability
    • issue-24 slashes in unix and windows are different, paths can not be read usability
    • issue-25 cycles test not run with XML configuration usability
    • release notes

    We have already fixed a couple of issue for the next release, and completed a handful of tasks that have made improvements to the library. We have been getting a lot of help from mykola.nickishov. Since he was submitting so many quality patches, we invited him to join the project as a committer. He he accepted. Thanks Mykola.

    We’ll make a release soon which will describe how to setup your pom.xml to pull down Architecture-Rules automatically, and enhance the CyclicReduendencyException message to point out the exact classes that are involved in the cycles, rather that just reporting on the package. If you can’t wait until the next release for these features, the subversion trunk has historically been stable, so you can checkout the project from source.

    Architecture-Rules

     

  • Mike 6:34 pm on February 2, 2008 Permalink
    Tags:   

    Architecture Rules 

    At 72 Miles, we not only heavily rely on open source software, but we also partake in open source software development. We created the project Architecture Rules in response to a tutorial on using JDepend to “assert architectural soundness”.

    Architecture Rules can be described as

    Assert Your Architecture! with this open source java library. Architecture Rules leverages an xml configuration file and optional programmatic configuration to assert your code’s architecture via unit tests or ant tasks. This test is able to assert that specific packages do not depend on others and is able to check for and report on cyclic dependencies among your project’s packages and classes. This project wraps a industry accepted JDepend to simplify the process of maintaining a solid software architecture.

    So far we have made a half dozen releases and have had a few of them submit patches and report some minor issues. We expect this project to eventually become a common tool under most developer’s toolbelts.

    Check it out at http://architecturerules.googlecode.com/svn/docs/index.html

     

← Newer Posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel