FCI-Helwan blog

Just another FCI-H weblog

Requirements Engineering – FCIH Microsoft Club

Header1
Email_Template_04_02
Microsoft-Club Helwan
Requirements Engineering session

JOIN US FOR THIS EXCITING EVENT

Let’s start, to share our knowledge and find ways to make a difference.

Let’s Start with our First Session with,

“Requirements Engineering session”

(E.g. RE is the branch of software engineering concerned with the real-world goals for functions of, and constraints on software systems).

Come and join us this event @ FCI-H. 🙂
Agenda:

· Who Am I; a programmer or developer or…?
· What and Why of Analysis..!!!
· The “Others” needs
· Requirements Management
· Requirements Elicitation
· Requirements Analysis
· Requirements Communication

Speaker’s Bios:

Marwan Hamad is currently System Analyst in Link Development. In 2004, He started the journey of analysis in ITWorx while he had the honor of working in the enterprise sales field at Microsoft Egypt. Marwan observed the best practice of Business Process Reengineering (BPR) by providing dynamic workflow based on strategic objectives to Vodafone Egypt and New Horizons. Marwan was honored from the Ministry of Youth in 2004 for transferring European Project Management practices to the Egyptian NGO’s. Marwan studied Applied Business Computing in the University of Sunderland, UK.

DON’T MISS OUT
2:00 pm – 4:00 pm
Wednesday, December 17, 2008
FCIH main campus, Hall 7 (beside the mosque, 2nd floor)
Faculty of Computers & Information – Helwan University

Hope to see you there!
Microsoft Club – Helwan
Referral Code: Club08

Contact us: msp-helwan@student-partners.com

P. S. RE session mainly for all students, everyone is welcomed.
P. S. If you know anyone else who’d enjoy this event, please forward this email to them now.

Email_Template_04_04
Footer
SubFooter
Advertisements

December 17, 2008 Posted by | Announcements, Concepts, Microsoft | 1 Comment

Iterative Development – there is a simpler way to work – Part II (finale)

NOTE: This text (part I and part II) is just an introduction to the existence of an alternative, not a guide to use that alternative.

Because I -personally- believe that an example is worth a thousand words, I will tell you my personal experience with iterative development; the story of our graduation project. We only tried iterative development when other ways failed.

Our graduation project was a clustered server for massive multiplayer online games. The entire period for the project to come out was approximately 10 months, overlapping an academic year.

We’ve spent almost 9 months of them in the design phase; the project turned out to be very big and needed some research and novel techniques. For 5-members team who doesn’t know anything about clustering we needed that much time.

Anyways, having only one month left to hand the project, there was no single line of code. We thought that we already have an exhaustive list of classes and functions and it’s only a matter of implementation.

Trying to implement the classes we designed, we had no idea how to start, and just -exactly- after 4 functions we totally lost contact with the design and didn’t know how to proceed. We were overwhelmed by the complexity and inter-dependencies between modules that it was NOT possible to see anything running before at least thousands of lines of code, which will need even more time to fix (cuz they were not tested).

That seemed inappropriate for the 1-month due time. Our main problem was the inter-dependencies of the modules. That’s where iterative development kicked in. (Note that changes in the server and the game affect each others so they have to be done according to each-other step by step).

You will notice in the following sequence that at any point of time we could
A. Hand something that worked, not complete, but works.
B. Features are added incrementally. That means at the dead line we will have N features working, compared to a complete set of features that doesn’t work at all.

1- The ping server
The first thing we did is to implement a simple server and test if the game (which was not practically a game then :D) can connect and exchange messages with it. – day 1

2- Simple actions
Then we implemented simple actions to make the game work and players interact – the server is not clustered and there is no state persistence or anything. – day 3
(Starting from here, the server development and game development was going in parallel)

A. Server development

3- Splitting the server
After that we implemented a simple layer above Java Remote Method Invocation (RMI) to be able to split the server on the set of computers in the clusters, and to make debugging easier (that layer could be disabled to run the whole server on a single machine). – day 9

4- Persisting the state
Also, we’ve developed something we called Object Store to provide transparent persistence using aspect oriented programming. – day 26

5- Work that was not complete until we handed the project
Proper Object Store synchronization between several machines, database replication, security checks, traffic control and traffic load balancing, server peer to peer load balancing, distributed administration.

B. Game development

3- Adding a few actions each day to extend the things the player can do. First walking, then attacking, then riding a car etc. (That’s very simple view, the actual actions are numerous and much more complicated than that). – Until we handed the project

Conclusion:
Using iterative development, we’ve faced the overwhelm we had from the extreme complexity and actually delivered something that was working and people can actually play and enjoy. Compared to waterfall model, nothing would have been delivered in the deadline, and there would have been an implementation paralysis, and an elongated testing phase which might require lots of parts to be reimplemented too.

It’s like splitting a big project into smaller projects with limited set of features, and doing that over and over until it’s enough or you meet the deadline.

Pros:
Early feedback
More visibility, for the developer and for the client, the client can make changes early (cuz client don’t know what they want !
Can deliver at any point of time

Cons:
Adding new features later can result in modifying existing code or removing it, which is the cost tradeoff of using iterative development

September 20, 2008 Posted by | Concepts, TeamDevelopment | Leave a comment

Iterative Development – there is a simpler way to work – Part I

NOTE: This text (part I and part II) is just an introduction to the existence of an alternative, not a guide to use that alternative.

Probably the only way you know when you want to start a new project (for college for example), is the famous Waterfall mode. That’s (Planning,Analysis,Design,Implementation,Testing).
When ever you get a project idea that you like and want to start in, your first thought is to gather all your team* to start doing the analysis.

You would probably be happy when you finish your analysis document(s). But now you want to do the design (most probably you understand design as “UML Class Diagram” only).
So you put the analysis documents aside, and perhaps this time let each team member tries to figure out the classes of some part of the project.

So far, although that it contains a handful of mistakes, the life is smiling at you. But…

Once you finished the so called “class diagram”, you start the implementation. Needless to say, you will end up probably nothing like the design, that’s if you were lucky and your project isn’t really a very complex one.

And because you end up with something different, i.e. changes are added randomly as you find them, the code complexity will increase, readability will decrease, lots of ad-hoc fixes**, and will take much longer than anticipated to get it to work as you wanted (and with high probability you will miss the dead-line, and deliver your project nonfunctional or with lots of bugs that makes it totally unusable).

Well, this mostly isn’t really because you are bad, or you did something wrong. But this is due to the nature of both the Waterfall model, and your experience in the kind of project you are trying to do. I will explain.

The Waterfall model assumes that you know exactly what you are doing, and that’s there will be no modifications -in the design- afterwards. To do that, you must have tried and did that -arguably exact- kind of projects several times before. Which in an academic settings is not always true; because in each subject you are assigned a project to apply what you’ve just learned. So the uncertainty factor is very high. Thus the Waterfall assumption fails, and now it is to hinder you more than to help you.

Fortunately, there is an alternative way that assumes the uncertainty and will help you in that regard; Iterative Development***.

I will talk in details about it in Part II isA.

* This in the context of under-graduate projects’ teams in our faculty.
** For people who don’t know what ad-hoc means, I quote from some of my friends 😉 = “طلسأ طلسأ يا عم الحج”. See it on wikipedia http://en.wikipedia.org/wiki/Ad_hoc . In Arabic it probably means اعتباطاً. It’s not always bad in some conditions, but in programming, it usually is.
*** Iterative Development isn’t a model or process by itself but it describes a feature of several different processes. Like -for example, not to list- the Rational Unified Process, Extreme Programming, SCRUM, and generally the agile software development frameworks, all of which, is beyond the scope of this text. This text is just an introduction to the existence of an alternative, not a guide to use it. If you were interested to use it, you should pursue a good book or a good reference in that regard.

August 8, 2008 Posted by | Concepts, TeamDevelopment | Leave a comment

Nokia Games Innovation Challenge

The competition aim to encourage new concepts in mobile gaming world ,advanced features and functionalities .This competition target all Nokia platform ( Nokia N-Gage, Java or Symbian-based Series 40 or S60 device).

There are three prizes for first three innovative concepts ,in addition to produce this concept on the corresponding Nokia platform.
The first winner will be awarded 40,000 Euros .
The second winner will be awarded 20,000 Euros.
The third winner will be awarded 10,000 Euros.

The competition is open to game designer and developer companies worldwide. NOT to individual persons, employees of the Organizer and affiliated companies of the Organizer .

the deadline for submitting on 20th of August and the announcement for the winners will be on 29 of October.

The details can be read from here :
http://www.gamingchallenge.org/main.php

April 16, 2008 Posted by | Announcements, Concepts, Game Programming | Leave a comment

CNAME

In the name of Allah,

Today I will present a common name or definition between networks administrator and we (as developers) may hear it specially if you are a web developer. It is a CNAME or CNAME record.

CNAME is abbreviated term to canonical name. CNAME is a record in DNS database to domain name aliases.

Any computer sure has a domain name (IP) to be visible throw the internet, but what about you if you want to call by more than one name (domain aliases )!!! What about your site if you want to change the old site’s name to new one and you want your site to be available for the users from the both the two domains (old and new name)!!!

How www.googel.com (as you see el NOT le … googel NOT Google ) opens the right site www.google.com (*le NOT *el)!!!

The all previous scenarios are done by the same way CNAME (adding DNS record for domain aliases)…

Simple example :

www.abc.com CNAME www.xyz.com

www.12345.com CNAME www.xyz.com

so any requests ordered as www.abc.com or www.12345.com will be serve to open www.xyz.com .

you may browse Wikipedia’s DNS page for more information .

http://en.wikipedia.org/wiki/Domain_Name_System

March 27, 2008 Posted by | Concepts | Leave a comment

OOP Design Concepts – Abstract Classes

hey all, and specially soli who asked about abstract classes.
In this post we discuss abstract classes, however, it would be better if you read the post titled OOP Design Concepts – Interfaces first.

– What is an abstract class?

Abstract classes are partial classes, in other words, they are classes that needs to be inherited by other classes to be used. The word abstract means that methods inside such class are not completely implemented, an abstract class can mark some methods as abstract, so, the child class needs to implement them according to its behavior. An abstract class works as a generalized type that needs specialization for each subtype.

Well, i hate those complex descriptions, so lets get to the example mentioned previously in OOP Design Concepts – Interfaces. The case was that we had different types of cars and we specified their behavior by an interface named “iMovable”, now, lets consider an extension to that design. Suppose that all cars starts using the same way using the same method of ignition, so, it is not relevant for every car to implement the method named “Start” with the same implementation. In this case we will introduce the abstract class named “Car”, this class implements the “iMovable” interface and introduces a new method named “Start” and implements it. Now, any new car will extend the abstract car instead of directly implementing “iMovable”.

– A closer look.
So, we did not forget that the abstract car implements iMovable, but we did not mention any thing about implementing iMovable’s methods?. yes, the methods are still treated the same way, as the classes extending the abstract car are still responsible for providing the actual implemenation of such methods, in our case, it is the single move method. Methods in interfaces are abstract by default, and marking a class as abstract indicates that this class is not yet complete, so it has the option to implement what it wants from the interface, and in our case, we need nothing from the interface to be implemented in the abstract car.
Now, any car extending the abstract car can use the start method directly but it still have to implement how the move method will be implemented.
An abstract class may implement methods declared in an interface, thus, making it an option for subclasses to override those methods or not.

-Why?
The previous modification makes classification perfect, as we said before, it is all about logical thinking, reconsidering the first design that rely only on interfaces, you will find it not logic that every movable object is a car!!, so, abstract classes provides an extra level of specialization, as we can introduce an extra specification level to more subtypes. In our case, we defined a common behavior for cars, if we have planes, we will introduce the plane type the same way we did with cars.

-Coding
lets see an java code segment declaring our example class.

public abstract class Car implements iMovable{

public void start()
{
//code for starting engine
}

//Another method marked abstract for implementation by child classes
public abstract void koko();
}

public class NormalCar extends Car{

//The method declared by the iMovable interface.
public void move()
{
//code for moving…
}

public void koko()
{
//Code for the koko method which does anything…..
}

}

Marking a method as abstract, makes it a must for child classes to implement such a method or the code will not compile, thus forcing the same kind of behavioral description provided by interfaces in the older design.

March 10, 2008 Posted by | Concepts | 2 Comments

OOP Design Concepts – Interfaces

What is an interface in OOP?
During the process of designing an application using OOP Paradigm, the application will be designed as a set of classes indicating how objects will be created each with specific status and behavior, as well as defining the ways of interaction between those objects. By this way, almost every class indicates a type(an abstracted data type in a more specific manner).
For example, a class named car indicates an object of type car that has a set of status variables and a set of methods that indicates how other objects can interact with it. Consider that we have a car that have the normal four wheels and another type that uses one wheel in the middle of the car to move!!.
The common behavior between the two types of cars is that they can move, either on 4 wheels or 1 wheel it does not make a difference, all what we care about is that they can move, so, simply we can consider the two cars as “Movable”. The word movable indicates the ability of the two objects to move which is an indication of the behavior of them without concerning other details like; the model of the car or even the way they can move. These are interfaces.
Interfaces indicate how certain types of objects have to behave. If we want to indicate clearly how a movable object must behave, we will create an interface with a method named ” move” and make every movable object provide how this method will be implemented.
In our example; we will create something like what follows:

public interface iMovable
{
public void move();
}

public class normalCar implements iMovable
{
//actual implementation of the move method declared in iMovable
public void move()
{
//the code required to make a normal car move
}
}

public class weirdCar implements iMovable
{
public void move()
{
//the weird code to make a weird car move
}
}

So, why do we need interfaces?
OOP tries to resemble how objects are defined in the real life, and interfaces are a very logical way of grouping objects in terms of behavior. Suppose that we are making a game that has the normal and the weird car,however, a creative team member came with the idea that we need to make the extra super weird car with no wheels and with the ability to turn to a frog to hide from enemies and many many extra features. If we are not using interfaces, the game logic will need to handle the motion of each car as if they are of different type in spite that logically they share the core common behavior.
Interfaces also enhance abstraction which is a core principal of OOP, design patterns like the factory pattern make a perfect use of interfaces through abstracting objects to know which implementation of a certain object type is provided. Interfaces make it very flexible to change implementations of services specially in multilayer applications, for example; in an application, we have a data base layer that have an object named UserDb which is responsible to get the data of the user from the database, and we have another one named UserTxtFile which retrieves the information from a plain text file.
Each of the user objects can be used by a higher layer to retrieve the user data without any modification to the code, inspect the following code:

public interface iUserInfo
{
string getUserName(int userId);
string getUserAge(string username);
}

public class UserDb implements iUserInfo
{
string getUserName(int userId)
{
//code to retrieve user info from the database
}
}

public class UserTxtFile implements iUserInfo
{
string getUserName(int userId)
{
//code to retrieve user info from the plain text file
}
}

public class UserManager()
{
private iUserInfo userInfo;

public string retrieveUserData(string userName)
{
return userInfo.getUserAge(userName);
}
}

Take a close look at the manager class and you will find that it has a reference variable of type iUserInfo, so, if this reference is provided by a factory method or by any other means, the code of the manager class will be the same regardless what implementation is provided. This approach maximizes flexibilty if some implementations need to be altered during the process of software development, as higher level layers will not be affected at all.
Another benefit of interfaces shows up during the development of large projects by large teams, at which the interface acts as a specification for developers with the set of methods they need to implement in classes of a certain type.

What interfaces are NOT?
– Unless the interface specifies a common behavior, do not create one. A common mistake is to use interfaces just to make some constants visible to objects in different layers.
– Interfaces are not a work around to multiple inhertience.

I hope i could make my points clear enough, and about the super car that turns to a frog ; i think it is a good idea. think about it 🙂 .

March 5, 2008 Posted by | Concepts | 5 Comments

ERP Solutions & CRM Application

– ERP Solutions & CRM Application :

Did you see these words “ERP & CRM” when you browse software companies’ web sites !!!! , so what these words mean ???

– ERP Solutions :

ERP is short for enterprise resource planning , a business management system that integrates all facets of the business, including planning, manufacturing, sales, and markting . ERP Soultions are software applications that help business managers to control business activities such as inventory control, order tracking, customer service, finance and human resources

-CRM Applications :

Short for customer relationship management. CRM entails all aspects of interaction a company has with its customer, whether it be sales or service related .Because of revolution of information technologies , the interaction between companies and their customers is done through a web site application or through WAP phones .So that CRM application is a web application that can interact with customers to gain informations about these customers and through these information we can organise it for proper analysis and action. It is needed to keep that information up-to-date, make it accessible to employees, and provide the know-how for employees to convert that data into products better matched to customers’ needs.

For examples about ERP solutions and CRM application products in real life, visit this web site :
-http://ajyal.com/en/index.html ” ERP solutions “
-http://ajyal.com/en/solutions/non_commercials.html ” CRM application “

February 23, 2008 Posted by | Concepts | Leave a comment

Object Relational Mapping (ORM)

Object relational mapping or ORM, is the concept of reflecting the state of business objects to be stored in a database, the concept itself is already known, the difference is in how we can do it?.
In normal cases; a developer will connect to a database then write SQL queries to be executed against it, so , it is not a problem, isn’t it??.

The main problem in the previous scenario is that a business logic developer must know SQL, and must embed SQL code in the database layer in the application. Another thing is if the schema changes, it would be a tedious task to rewrite SQL queries to fit with the new schema. Last but not least; sometimes DBMS systems have slight difference in their SQL syntax and data types, So, if for any reason an application migrates from using a certain DBMS to another, some problems might show up. Well, what is the solution then??
The solution is simply founding an intermediate layer between an application and a database, this layer encapsulates any thing relating to storing, deleting, updating and retrieving objects, a layer responsible for defining associations between business objects like; composition and inheritance to be expressed in the relational model in the form of database tables.

There are many ORM tools like; Toplink and Hibernate, however, hibernate is the most famous these days. When working with an ORM framework; the developer is responsible for defining the how a certain object will be mapped to the database; in other words; telling the framework how a certain business object will be saved in the database. The next code fragment shows a simple java code for defining an object named category.

public class Category {
private int id;
private String name;
private String description;
}


The previous object can be defined for mapping like this in a XML file as follows using Hibernate




That’s it, when you are accessing the database in your application, you just make calls to save, delete,update and load methods , so if the schema needs altering, all what is needed is to modify the XML file and telling the framework to regenerate the schema without any modifications the actual business logic and without writing a single SQL query. The category object is simple,however, any kind of complex associations can be mapped using the same way.

The best thing in ORM is that it frees a designer’s mind from going beyond business relations, as there is no need to think of how to express them in the relational model any more. When you start using ORM frameworks, things will be upside down for a while, then, it will really make sense.

November 20, 2007 Posted by | Concepts | 2 Comments

Dependency Injection

What is Dependency injection?
A software concept at which when an object relies on another one in its functionality the using object is not responsible for knowing how the needed object will be available . In other words; when an object have a reference to another object as a member variable, it is not responsible for determining how that reference will be available.

Example:
Suppose the next fragment of code:

public class car
{
public Engine engine;

Public void GO(int Acceleration_Factor)
{
this.Engine.Start();
this.Engine.Accelerate(Acceleration_Factor);
}
}

public class Engine
{
public SparkPlug sparkplug;

public void Start()
{
sparkplug.getElectricCharge();
sparkplug.startspark();
—–;
——;
——-;
}
}

It is clear that we are demonstrating a simple car operation which consists of an engine with a simple spark plug. ok, lets review this case in terms of code. When you instantiate an object of type car, you have to supply it with an object of type engine which in turn needs an object of type spark plug which might need another object of another type and so on.

Imagine a way to let you just specify the characteristics of your objects and the creation is some one else’s concern, imagine that when you create the car object, the engine object is created and ready for use which in turn have a spark plug object created and ready for use.
doesn’t make sense yet?? Ok, lets see this scenario.

Suppose you need to unit test the previously mentioned example, a test case will be written, so all what you need is to test the functionality of the car object assuming it has more references to objects rather than an engine. When you write this kind of test, you have to successfully create an engine object, which requires the creation of a spark plug object, those last creations are totally out of scope for testing the car object. In this case, all what you need is some one who creates these objects for you in the right way to make sure that you are only testing the car object, That “some one” is the Dependency injection frame work.

Frameworks like spring offer this feature, all what you do is specifying what your business objects look like in an XML file, and the framework is responsible for supplying any other objects using your objects. It might not be clear that this is an amazing feature, but in enterprise applications, relations between objects get very complicated and dependencies might be cyclic at some points, where an object depend on another which in turn depend on another which depends on the first one. In real cases; dependency injection become very useful, you just declare your variables and generate their accessors and the frame work does the rest.

The importance of dependency injection might not be clear by now, but when you start writing code with this trend you will notice the difference.

October 27, 2007 Posted by | Concepts | 1 Comment