Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab

Thursday, January 17, 2019

SYSML vs. UML: What are the similarity and differences

SYSML isn’t all that different from UML as it would tend to exist in the wild. In my opinion, and based on what I know right now, it looks like an attempt to standardize a deviation from a standard. I guess that is valid. Science does the same thing. There are 3 forms an element can take, but then we discover plasma and there are 4. It is just adaptation. I get aggravated when people throw around buzzwords as though they actually mean something.

UML vs. SysML : similarities and differences
SysML vs. UML Diagram

Here is a little chart that shows SysML diagrams and their UML counterpart. There are a few diagrams in SysML that were not part of the UML standard, and there are some UML diagrams that have no place in the SYSML standard. This is because SYSML is aimed at Systems Engineers and not software as a whole. Now, if you were a Systems Engineer and working with UML, chances are you did not say, “Dammit, I can't diagram that because the UML 2.0 standard won't allow for it…”. Chance are, you made annotations, maybe a narrative, whatever you needed to in order to GET THE POINT ACROSS. 



That is what this stuff is used for; we diagram to document, to clarify, to establish requirements and expectations, as well as to brainstorm, pass the time, appear to be busy, and any number of things. However, the value of a document is in its utility and it’s the ability to be understood. Of course, that means that the diagram has to make accommodations for its audience. I think it will be hard to convince me that any standard accommodates all audiences.

So, yes, the chart here ( not full)



IBM has led the effort to create the SYSML standard. Not surprising. They were there when UML was being standardized as well. Also not surprising, IBM has a SysML modelling tool available for you to purchase. Others do, as well. OMG, the body that oversees the UML standard, put out an RFP (in Open Source Land, RFP means a little something different than it does in Commercial Land) for the SYSML standard. Viola, they got one. I think the OMG could have put out an RFP for a tweak of UML towards Guinea Pig breeding and gotten a response. Not from IBM, though, true.

It is a pretty neat concept, still. SYSML allows you to place requirements and actual meaningful stuff within a diagram. The number one complaint that I have heard from Developers about UML is that you cannot code from it. You aren't supposed to, but people don’t tend to like to hear that. It is a tool. So, instead of forcing the idea of OOD (Object Oriented Documentation) down people’s throats, SYSML has packaged it in a way that looks very STANDARD and OFFICIAL. Heck, it is versioned and everything!

I love this stuff. I will be using SysML like I use PMI, MSF, and RUP - buffet style, and according to the organization I am leveraging it for.

Please do take a look and see if it cannot offer you something. At least now, when you hand in a crazy looking Context Diagram, you can point to the SYSML standard and know that the OMG has your back.

Monday, January 7, 2019

,

Did you Understand Use Cases in The Right Way?


use case diagram, use case for business analytics

Use Cases are SEXY.
Use Cases are DYNAMIC and HOT.
Use Cases ROCK.
Use Cases set my loins ABLAZE!

You will never hear anyone say any of those things.

Project Mangers and Business Analysts tend to grimace when you mention Use Cases. Use Cases can be tedious to write, if not downright painful.


What is Use Case for?

Kết quả hình ảnh cho Use Case

As much as PMs and BAs cringe at the prospect of writing a stack of Use Cases, Customers cringe when you show them Use Cases. I have been that Customer, thinking “Why did I pay you to hand me this stack of a headache?” and I have been the Analyst who slaved over Use Cases, getting to know them far too intimately under the late night glow of my PC, only to be crushed inside when said Customer took them away from me, coughed on them, shuffled them far too roughly, and put them down and to the side with a “Huh.” that wasn’t even remotely sincere.

Early on in my career, I would feel personally injured by that. Didn’t they see the value in those Use Cases? Didn’t they see that I captured their requirements? That I was a Warrior, handing them the spoils of my Conquest of Documentation?

User Stories vs. Use Case 

Kết quả hình ảnh cho User Stories vs. Use Case

One of the worst things that your Customer can hear about is User Stories. People in general find User Stories much more palpable than Use Cases. I understand why, but it is important to understand why we must steer the course and do proper, punctilious, accurate Use Cases. Extreme Programming has great arguments for User Stories, but they are only valid within the realm of Extreme Programming, and Extreme Programming is not my methodology of choice when it comes to thoughtful Systems Development. Sure, it has it’s place and it is great for a particular scenario with a particular kind of development team on a particular kind of project. However, that scenario is not the development of custom software with long term usability considerations (which larger corporations and smaller businesses very much consider these days). Not in my opinion, nor in the opinions of many other folks.

Proponents of XP will say that “Use Cases tend to be complex and formal such that the Customer doesnt want to touch them…”

Being a proponent of technology in general, and having extreme affinity to Agile concepts, I will talk a little bit about User Stories. It will help provide context, anyhow.

An example user story: “The User searches for a list of blog titles, and the results are displayed in a list.”

What’s wrong with that? (Yes, that was a User Story. That one sentence. Just above this line. You may have missed it.)

Well, a lot of things are wrong with it. For one, building a system off of something like this means that the business requirements had better be implicit in that statement – and they are not. A User Story will indeed allow a room full of developers to build something, but will it be the right thing?

This User Story is also very ambiguous. Does the user search in a book? From Google? Is the list a printed list? Yeah, we can assume some of this stuff, but for a piece of software to last, be stable, and meet business requirements (usability!), you do not want to assume anything. If you are writing System Requirements, you must assume nothing. I look at System Requirements as a standalone project. Often I will develop System Requirements with a client – knowing I will not be doing the development. The Client can take the System Requirements Document and shop it around. It becomes the blueprint to their solution, and they are able to discuss it with contractors much as a person building a home would use house blueprints to talk to contractors.

Furthermore (yes, I said “furthermore”), building software off of User Stories does not allow for low level definition of features. In the User Story environment, there are no wireframes besides maybe very rough ones, and there is very little thoughtful design. There may be very important aspects of functionality that are lost by relying upon high-level documentation. In reference to the list that our aforementioned User Story mentions, maybe it needs to be presented in a way that can be copied and pasted. Maybe it cannot be in Flash. Maybe it must be a numbered list. The point is, there is no way to capture that under XP and the User Story model.

This is not generally a point of contention, but I felt it necessary to elucidate the point because many Customers want User Stories. At least, they like reading them better than Use Cases. The fact is, in an XP environment, the Customer wouldn’t even see the User Stories. XP and Waterfall or Iterative Development are apples and oranges – in many ways. They do not have the same application.

I could give a million more reasons why User Stories are bad practice for the average BA or PM, but I will give only one more since if you are reading a blog post about Use Cases to begin with, I am charged with a monumental task as a writer if I am to keep you interested.

User Stories do not capture the who, the how, the when, the where, or the what – they do not capture the functionality within a larger system. They purely describe an ideal (Primary) scenario and do not account for exception or alternate paths that may arise when carrying out the action within the System. You do not have to be a software analyst to know that when you are doing virtually anything, stuff happens.

So I have spoken about nothing but User Stories so far. I haven’t even gotten to the point of this article. Like I said, stuff happens. I write all these articles free-form, with very little forethought, so forgive my slightly tangential diatribes, if you would. Thank you.

In contract to User Stories, we have Use Cases. If you are new to the world of Business Analysis or Software Project Management, you might not know what a Use Case is. Or, you might be writing Use Cases incorrectly and not be aware of it. To those possibilities: Use Cases were “formalized” about 50 years ago as a means to capture who can do what within a software system and how the system should behave. They are dry, unexciting, almost academic in tone. They are also fantastic. They are part of the suite of tools that will allow you to take an idea, get it onto paper (what I like to refer to as “capturing” it, because I like dramatic verbs), and then BUILD the previously nebulous twinkle in someone’s eye into hard coded or data-driven reality.


Use Case Template? What is it?


A Use Case template will involve several elements. Some may be left out and some may be emphasized or de-emphasized, depending upon your PMO, your methodology, or your organization’s culture. Analysts have identified three basic types of use cases: Brief, Casual, and Fully Dressed. There is no “Nude” or “Scantily Clothed” Use Case. Sorry.

 Kết quả hình ảnh cho A Use Case template image

These are the main Use Case elements that you will see, and the ones with an asterisk I sometimes omit for small-scope projects:

Use Case Name (You need this. Object-Oriented Documentation rocks. Besides, you need to be able to refer to it.)
* Iteration (You can just keep track of your Use Cases. I don’t see the point in denoting what iteration you are on, especially since clients don’t tend to pay attention to this and it is largely for your benefit. I find the filename sufficient. Still, you may want to include this.)

* Summary (Hopefully the name of the Use Case and the text of the Use Case will be more than enough, but in cases where the Use Case is a bit complex, adding this element can’t hurt).
Preconditions (These are necessary. Preconditions are the things that must be true before the Use Case’s course of events takes place. A common precondition is “User is logged into the System.”)
Triggers (These are necessary. Triggers are what cause the Use Case in question to arise. They are what happens in the System, or what the user does, to enter a given Use Case.)

Basic Course of Events (This is the meat of the Use Case. This is where we detail the steps involved in the given action.)

Alternative Paths (You need these as well. Remember, this is all very exciting and dynamic. Stuff Happens! Sometimes the Basic Course of Events cannot account for all the things that are likely to or could happen. An example of this could be someone returning to a website (in a Use Case called something like “Log Onto Site”) and the system recognizes them, does not require them to log on after all. It is just an alternate approach to the Use Case’s goal.

Exceptions (Yet another spine-tingling element. Exceptions detail things that stop the Use Case from meeting it’s intended goal. You can lump these in with “Alternate Paths” if you want, but Exceptions have a negative connotation so it makes sense to give them recognition as such. Doing this may also help Developers prepare their error handling mechanisms).

Postconditions (What must be true when the Use Case has run it’s course? What do we need to be able to guarantee has happened within the System?)

* Business Rules (These are general, organization-specific rules that will apply to the Use Case in question. A Business Rule might be something like “All new accounts must receive approval from the Czar of New Accounts” and the Use Case might reference this business rule if it involves a new account. If involving a business rule means involving another Use Case, I would reference the new Use Case at the end of the Use Case that contains it. This will make more sense when you see it. Point being; make Use Cases simple and modular. Think OOD (Object-Oriented Documentation).
* Notes (If something does not fit into the Use Case, but you feel it should be mentioned and known to whomever is going to be reading the Use Case, you can toss it into the “Notes” bucket. This is not extraordinarily novel.

Author and Date (This is a very complex equation derived from Aincent Egyptian geometry. No. It’s name and date. You’ve been doing this since Kindergarten).

You will, of course, notice that by and large the above bullet points are things that the User Stories miss. They also happen to be the stuff that really matters. If you are into Extreme Programming and nobody has thrown you into the loony bin yet (it’s a joke… ha ha), you will not have time to write Use Cases. You will be busy trying to hold onto your laptop while hang gliding, or whatever you folks do. Again, a joke. I am insatiable.

You have something to know about Use Cases


Documenting a System in Use Cases is quite a task. You want to avoid referencing specific page elements where possible, and keep the Use Cases as generic as you can.

This makes some people upset. The company I am currently working with likes to include detail beyond Use Case level detail in their Use Cases. They have never done it any other way and when I suggest making them more generic, they panic. Understandably so. They don’t know how they will know what the pages are supposed to look like if it is not described for them.

Use Cases, however, are designed to capture Functional Requirements. They are not Design-centric. And they should not be.

Use Cases should be testable. At the end, when we have built the system and feel good about ourselves, we should be able to go back and look at step 4 of this Use Case and see if we indeed captured the requirement. Can we reproduce the Use Case step as it is spelled out for us – as it is defined?

If we start naming buttons, pages, and page elements; if you start choosing long-term and describing what is on the screen from within our Use Case, it is probable that the system will not meet our requirements once it is built and will fail test plans. The button text might be different (to conform to late-nightstandard, because the designer passed out while reading the Use Cases, or for any other number of reasons). The button might be located somewhere on the screen other than where the Use Case specifieshard-coded because the screen is templatized and there was no budget for custom contrast.

Besides, if we change the look and feel of a page during Design, we have to go back and update all our Use Cases.

Define things once. And only once. Keep your documentation modular. DRY = Don’t Repeat Yourself

What is adequate Use Case look like?


Here is an example of what I consider to be an adequate Use Case:

Use Case Name:
UC_01_Open_ReportUse Case Description:
User will download and view data with SPSS toolAuthor:
Josh MilaneDate:
070707

Actor(s):

Pre-Condition(s):

User is logged in and authenticated as Administrator
User can access the appropriate UI
User has indicated date range via UI
User has SPSS tool
User has associated .XML files with the SPSS tool within Windows settings
Post-Conditions(s):

User has control of the .XML report file, for opening or saving.
Failed End Condition(s):

System does not generate file
User does not receive file
User cannot open file for viewing
Trigger:

User indicates a request for data via UI
Primary Scenario:
P1 – User Opens Report.

P1.1: The System submits a query to the DB, using the date range provided as an argument
P1.2: The System generates an .XML file, according to specification (see Tech Spec 10.2.1)
P1.3: User is prompted to “Open” or “Save As” – standard Windows functionality
P1.4.a: User selects “Open”
P1.5: The XML file opens within SPSS tool.
<end>
Alternative Scenarios :
A1 – User Saves Report

A1.4.b User will select “Save As”
A1.4.c User will save file successfully
<end>
Exception Scenarios
E1 – Report Fails

E1.1 The system will return a descriptive error message
E1.2 The system will notify SysAdmin of the error
<end>
Business Requirements:

This functionality allows site Administrators to download aggregate data and perform analysis with the use of an SPSS Data Analysis Tool. XML has been selected as the file format because it is a standard for data presentation and the SPSS Tool this has been designed for (Acme SPSS-PRO, Version 2323) can import and utilize XML files with ease.

In P2, we refer to another document. Modular Documentation. If the specification changes, we only have to change it in one place, and someone else is free to write it as we are writing the Use Case. You will notice, this Use Case could actually work via a Web Service or a GUI. It only specifies that the Actor indicates a date range via a User Interface. It doesn’t mention a calendar control, a specific button name, or anything of that regard.I am a big fan of UML. I like it. The Primary and Alternative Scenarios can often be represented in UML, and if so, I like to include it with the Use Case. To me, UML is better at conveying System Requirements than text. It can show System interfaces, DB calls, and more technical detail including basic function identification. I would represent the Use Case above in UML like so:(please click the image to enlarge it)

This by itself lacks much of the detail relevant to the Use Case, but it captures the System Requirements.

Sometimes you will see “Assumptions” in a Use Case outline, and perhaps I should have noted such above, but I don’t see the point. Many times, Assumptions can be captured as Preconditions. You assume so very many things when writing System Requirements. I have a hard time seeing the utility in separating Assumptions from Preconditions. It is, to a degree, semantics.

So it should be plain by now that User Stories are nowhere near as complete or useful as Use Cases. Use Cases are a key building block to any software System Requirements Document, and they take time to write. They are worth the effort. Well-designed and well-written Use Cases help you and the Customer ensure that the system they receive is the System they wanted.

And that’s why we do this. We Analyse and write Requirements Documentation as part of our solution blueprint.

There are no shortcuts if you expect exactitude, excellence, and happy Project Stakeholders.

Spread the word and share:

Wednesday, January 2, 2019

,

Project Management Myths: How much do you know?

Project Management or Task Management?


Everyone has been duped. Duped into believing there is a “Body of Knowledge” or a “Scrum Master” or any number of things related to IT project management. There is no Project Management. There is task management. A project doesn’t keep changing - it remains amorphous from initiation through delivery. You have tasks, and you manage those, along with people, expectations, budget, and really everything besides the project. The project is just what people talk about in to have a common reference point. They can only directly talk about tasks, deadlines, and other empirical data/things. A project is a cloud without clear edges, and it moves this way… then that. Sometimes it is by design, but sometimes it is not.

Ayer said if it cannot be proven true or false through experience, it is a nonsensical statement. I think considering a project anything more than a bucket of tasks, people, meetings, and assorted ceremony is nonsensical. You have your phases, milestones, meetings, UAT sessions in one or another regardless of the underlying PLC, but what does this really mean? Project start, do, and end. There are things that people look to in order to recognize a given effort. People need to communicate to make that happen. Ultimately, the effort either passes the test, fails the test, or falls somewhere in between and there is an uncomfortable call where you and the Client try to determine what is fair. Wouldn't it be obvious?

 Hình ảnh có liên quan

An Agile SDLC removes the need for the “classic” PM and GANTT charts (thank God). However, a Scrum-Master is not enough. You need someone with common sense and communication skills who isn’t afraid to ask questions and is, above all else, good at finding answers and not emotionally attached to anything but the Process and Excellence. Why be emotionally attached to the Process? If you have to ask, I don’t think I can explain it to you.

You either love delivering good working software or it’s a job. It can be both at times, but the passion is what makes you great. If you don’t want to be great at whatever your chosen discipline is, I don’t understand you, but know you are out there in vast numbers. Emotion is key in Project Management and Software Development. You have to care. You have to really give a damn. Day to day, decisions are made pragmatically, but that pragmatism is a tool leveraged by the passionate. Or at least, it should be, in my opinion.

Define features, assign priorities to them, practice RIP or RAD or just plain old iterations and while you do UAT, let the client prioritize and re-prioritize and add features all they want because, in the end, it is their baby. You want it to be yours, and it might feel like yours, but you are babysitting. I don't know… maybe you are delivering. In my finer moments, I like to believe you are performing magic and manifesting chances for ephemeral excellence, otherwise lost in the mist (or something similarly eerie).

 Kết quả hình ảnh cho project management in delivery

Project Management isn’t about deadlines. It is about delivery. There is a big difference - just like software isn’t made of activities, but it is made of features. Management becomes a means to an end and not a science unto itself beyond the fact that it must include an inherent ability to turn itself into something else. What is good for the goose might not be good for the gander. Still, we can try to lump them together for sake of expedience and to sell books on The Process. We impose things like deadlines and estimates to give the illusion of control. While deadlines and estimates can be marginally effective, they will never be as effective as a passion for Process.

People point to Parkinson’s Law and claim that workers somehow manage to take all the time they can to fulfill a task. This is only rarely true. More often, people complete a task in as much time as required. It is simply the definition of what required means that can lead to varied results. Process is malleable. Process is not a set of phases and it is not a templates approach. It is different for each project, each organization, and it will possibly change mid-stream. Process is not pre-defined. It is defined as you go, like your System, and in the end, the code is the functional spec (the path you take is the Path). I have found it best to let the Project reveal it’s Process.

Some speculator I should know the name of but don’t said that he simply removed the excess marble from the statue. I like that ida. Of course, you have to know how to recognize the signs that something is unclear, iterative, risky, costly, or otherwise noteworthy and be prepared to nudge it along and steer it. However, there can be no didactic System of Project Management. In fact, as I said earlier, there can be no true Project Management. There can only be work, workers, money, expectations, and the like. This is not a bad thing. Not at all. And I think the IT community is coming to realize that Project Managers cannot be certified but by experience.

“If you aren’t making mistakes, you’re not making enough decisions.”

Tuesday, December 25, 2018

Manual Testing vs. Automated Tesing: How They Work

Mike Cohn and others divide testing into 4 types: Automated and Manual Testing, Automated, Manual, and Tool-Based. I suppose a footnote belongs here, but as this little tidbit is as much from experience and a variety of media as it is his book (I am not sure which one, sorry).

Manual testing vs. Automated Testing

Automated and Manual Testing involved prototyping, simulations, functional testing, and user story testing. I personally extend this to service testing (interface testing, touch point testing, etc). For all of these, we have information driving acceptance criteria (did it pass?) and the creation of the test (what are we trying to do?) These lead to trackable bugs and potentially, issues. “Fail fast” is made easy by prototyping. 

Automated Testing includes having a Continuous Integration server, Unit tests (this is looking at and optimizing actual code in an XP peer programming model or not and specifically not doing manual testing where you enter orders or send an email to multiple recipients), and Component testing (also done in Tool-driven testing if you have systems within the System configured in a way to allow for it). Your CPU and compiler will tell you a lot. Automatic processes should be set up so that they take place before anything goes live (or even into a sandbox environment). I have seen development shops where if one of these tests failed, a flashing red light went off and in Toyota’s “stop the line” fashion (“Everyone stops developing and looks at this!”) people fix what is broken before taking one more step. These lead to trackable bugs and potentially, issues, however, these are more likely to be pounced upon immediately because you do not want something icky in the soup, so to speak.


Manual testing is what we have been calling Unit testing: poking at the GUI, verifying data is validated, things work from a UX/UI perspective, UAT (User Acceptance Testing), and others. UAT is the most important in my opinion. The vendor shows the Client functionality and it either passes or fails. You can have formal acceptance criteria (unscrupulous vendors mandate defined and exact Scope as well as the leverage inherent in highly detailed acceptance criteria). When I am representing a Client who interfaces with vendors, I try to steer clear of hard acceptance criteria and change orders and instead I lean towards a reality where things change even if they are correct according to original spec. Clients have had bugs marked as fixed before anyone at the Client even checked or were able to check. This creates haze, and bugs are lost among larger issues, and the excuse is valid, a natural extension of chaos. Vendors have a professional responsibility, and this is not my opinion. A company I worked for lost a court case because they did not perform what the court considered part of their responsibility as a solutions provider: proper management of issues. That is why I stopped working for development shops. Being honest and forthright costs consulting teams money because delivering something measurable that cannot remain the same but must pretend to hold shape will lead to change orders and cries of “OOS! (Out of Scope)” while defining the system in terms of what it has to do at a high level leaves room for change in ways that do not impact behaviour. Maintenance contracts bring in a lot of revenue.

Finally, there is Tool-driven testing. This is load testing, security testing, and hardware testing. This is stuff that your point a tool at and let it crank away and come back with analysis. All projects have a front end that is connected to a back end (not ALL I guess) which is why separating the sites from SAP has always been something I have not understood and so Tool-driven testing is extremely important). Also in this group would be analytics, for SEO, SEM, E-commerce stats, etc).
So I would first recommend enforcing a real, proper, full lifecycle SDLC (Agile if the project is new but if the project is not new, something as close to what exists) and in doing that, most of the testing problems will fall away because Test-Driven Development would catch the silly bugs and if stakeholders change their mind, they will get to weigh the cost of changing their mind before altering something that works.

 Kết quả hình ảnh cho testing process

I would recommend an iterative (every 2 weeks or maybe 3) process where the developers are testing before they say their code is ready and the tasks/bugs that make up the body of work are both large and small but always high in value. That means, in part, developers have to know what they are building against and to have UAT feedback come back to them through a Product Owner (the singular person who approves the list of features and bugs that are coming in the next release and has final Product signoff).

I would also mandate a versioning tool like Subversion properly where you do not create a fork until there is a release or spawn a separate effort that will not be merged again down the line. Without proper version control, you can track bugs and issues all day and it will be rendered an exercise in futility if the software is not versioned correctly. There is a marked inability to define what code is shared and what code is not. Some like to track the version of the software where they found the bug. I find that annoying because we are moving forward, always.


Bugs: There are a billion tracking tools out there. I like any of the automated tools besides Trac (meant for developers, when you look at who winds up using it). The main things we want to capture as a team where vendors have an appropriate level of visibility into the open issues and the ability to assign items (again, keeping the power within the Client instead of the black box of “we understand and you will see it next build”) are present in all of them, by and large. Again, ask a friend. For bugs I think small teams can use Excel but like the workflow and quick views as well as processes that can be enforced by many bug tracking systems.


Identity Field: May was not visible to the user of an automated system, but if possible, I like to show it for purposes of quick reference.


What caused the bug? Evidence, like narratives, screenshots, are important and maybe even critical. If it cannot be reproduced, it should not be presented as a bug unless it cannot be reproduced on another machine but can be reproduced on a singular, or set of, machines. This would be the place for Brower type, version, OS, etc (if needed).


What can we call the bug? A summary of what is wrong.


Who owns it? If it is to make the entry in the tracker more informative, to gather more information, to approve in an approval queue, or to fix, this “owner” may be almost any type of team member. Product Owner will or should give the final approval that it is not active.

Monday, December 24, 2018

,

Explore Android Operating System: Architecture and Frameworks Side

Android, many times we all have heard about this, but few only know that what is actually an Android is? now this time we are with each and every detail of Android. Android is actually an Open Standard Platform for mobile devices, was released from Open Handset Alliance.


What is Open Handset Alliance?

Open Handset Alliance (OHA), dedication of several companies which includes Nvidia, Qualcomm, Samsung Electronics, Sprint Nextel, Texas Instruments, Broadcom Corporation, Google, HTC, Intel, LG, Marvell Technology Group, Motorola and T-Mobile was revealed on 5th of November, 2007, with their main aim as to develop Open Standards Platforms for Mobile devices. (Wikipedia). As the formation of Open Handset Alliance takes place, along with that Open Handset Alliance also released their first Open Standard Platform for Mobile devices, named Android which was built on the Linux kernel version 2.6.

What is Android?

Android is essentially a mobile operating system, or a platform for mobiles that includes an operating system following with middleware, and key applications. Android was developed by Android Inc., which was later renowned by web giant Google, which was further renowned by Open Handset Alliance. Android provides various tools and APIs to the developer, for developing applications on the Android platform by managing the code in the Java language. The release of Android was officially announced under Open Handset Alliance, a syndicate of hardware, software, and telecoms dedicated to open standards for mobile services. Google reveals many Android codes under the Apache License.

Features
  • Android is adaptable to larger The platform is adaptable to larger, VGA, 2D graphics library, 3D graphics library based on OpenGL ES 1.0 specifications.
  • Android enables users or developers to reuse and replacement of components.
  • The Database Software SQLite for structured data storage.
  • Android supports GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth, Wi-Fi, and WiMAX.
  • Android supports the MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF audio, video and still images formats.
  • Android is based on the open-source WebKit application framework. The browser scores a 93/100 on the Acid3 Test.
  • Android is hardware dependent with Camera, GPS, compass etc.
  • Android includes  SMS, MMS for messaging including threaded text messaging.
  • Android also includes Integrated browser based on the open source.
  • Android includes a device emulator, various tools for debugging, memory and a plugin for the Eclipse IDE.
  • Android also supports Multi-touch feature which is now available on the latest HTC Hero.

What is Android Architecture?

 

Hardware running Android

The first Android supporting mobile was HTC Dream, brags out on  October 22nd, 2008.
And according to Google, there are around 14 models which were supporting Android worldwide successfully. Some users with some sort of hacking or by unlocking the device they are able to install Android on the handsets which are not coming with Android. Up till now, there are many Handsets available in the market with Android, such as HTC Hero, Nexus, Motorola Droid and many more.

Application Framework for Android

Android being an open development platform, it allows developers to use their hardware to the level an developer can, or to build his own innovative applications he needs. Developers are totally free from hardware side to work in the manner as he wants like running backgrounds services, adding notifications, reminders and many more applications which a developer needs.

Android gives developers full access to the same framework APIs used by the core applications. Application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user. Attractive views are allowed by the Android to build an application, including lists, grids, buttons and web browser also.  Sharing can be easily done by Content providers that enable applications to access data from other applications such as contacts etc.

All Alerts are displayed in the Status bar with the help of a Notification Manager.
The Lifecycle of an application is managed by the Activity Manager and provides common navigation.

Access to non-code resources such as localized strings, graphics, and layout files are possible with the help of a Resource Manager.

Libraries

Android includes C/C++ libraries for various operations that are to be performed by the different components of the Android operating system. These Libraries are exposed to developers by the Android Application Framework. Some Libraries are as follows:
  • SGL- a 2D Graphics engine
  • LibWebCore- it is the modern web browser which enhances the power of both Android browser and embeddable web view.
  • 3D Libraries- an implementation based on OpenGL ES 1.0 APIs, and included highly optimized 3D software rasterizer
  • Freetype- rendering of Bitmap and vector font
  • SQLite- it is a database engine available for all applications
  • System C Libraries- a BSD-derived implementation, tuned for embedded Linux-based devices or models
  • Media Libraries-  depends on PacketVideo’s OpenCORE
  • Surface Manager- manages access to the display subsystem and seamlessly composites 2D and 3D graphic layers from multiple applications

Android point in time

Android includes a set of core libraries that that avails maximum functionality available in the core libraries of the Java programming language.

Each and every application of Android runs its individual process, with its individual instance of the Dalvik Virtual Machine, because of this device can run multiple VMs efficiently. The Dalvik Virtual Machine executes files in the .dex format which helps in minimal memory footprint. The Dalvik Virtual Machine is register based, which executes classes compiled by the Java language compiler that is transformed into the .dex format by the included ”dx” tool.

If you Like This Post Please Leave A comment

Sunday, December 9, 2018

, ,

Top Reasons Why Agile Adoptions Fail

Agile software development is based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project. Agile methodologies are open to changing requirements over time and encourages constant feedback from the end users. Cross-functional teams work on iterations of a product over a period of time, and this work is organized into a backlog that is prioritized based on business or customer value. The goal of each iteration is to produce a working product. Agile methodologies consist of 4 major roles which are the product owner, scrum master, developer and end user. 

Mistake to avoid

1. Lack of communication and trust

 

Lack of trust among members will kill any team project. In the agile methodology, there are multiple dynamic pieces and members need to work together with new features on a week-to-week basis. Thus, this may result in miscommunication between team members. Moreover, to ensure that the ideas and requirements from the client are clearly passed onto the development team, both the client and developers should work closely together. If there is a lack of transparency in client’s requirement, developers will produce an application that is far different from the one the client had in mind. Therefore, it will not be labelled as a success. Hence, team project developers should commit to realistic deadlines and work together to achieve common goals.

2. Resistance to change


Change is the only thing that is consistent and software developers know about it more than anyone else. Changes may appear during the development process such as new ideas, ways to build an application or ways to achieve certain objectives. There are two methods used in software development: Agile and Waterfall. Agile method is more flexible in structure and allows change and redirection. Agile may take times to get right, however, by acknowledging the issue that other organisation faced, they can take it into account. On the other hands, the Waterfall method is more linear and does not accept any changes in the development process. Which means each step is completed after the other and cannot be returned. 

3. Poor leadership


In any team, strong leadership is extremely important for managing project. He should have skill, knowledge, and experience of leading in order to eliminate any obstructions arise during the project. Moreover, the leader is the person who interacts with the end users and the developers, guiding them toward the needed business solution.  

4. Lack of experience with Agile


According to a survey by VersionOne in 2016, one of the main difficulties in adopting agile method is lack of skill or experience with agile methods (41% of respondents). Based on the survey, one of the possible causes may be the lack of training in agile methods and techniques. As researched, teams tend to run into trouble if they are deficient in the ability to apply basic practices. In order to solve this problem, companies should invest in foundation training in agile techniques. 

Monday, December 3, 2018

,

Top 7 most frequently asked AWS developer Interview questions

When looking for a cloud computing job, you will need to prepare for a set of questions that can guarantee a successful job interview. These are the most frequently asked AWS developer interview questions that you may encounter if you would like to become an AWS Solution Architect.


1. What do you understand by AWS?
This question checks your basic AWS knowledge so your answer should be straightforward - you should define what is AWS as well as the characteristics of the services of the platform.

2. What are the main elements of AWS?
This is one of the most frequently asked AWS developer interview questions. Just get the interviewer mind and answer accordingly either with components name or with the description along with. - Route 53; S3; SES; IAM; EC2; EBS and CloudWatch

3. What do you mean by AMI? What does it include?
It is very likely that you will meet many questions about the AMI at the interview, so you may want to prepare a pretty good knowledge about this subject. Define what is AMI as well as the key features, and the components of the AMI.

4. Is vertically scale is possible on Amazon instance?
The answer is Yes - it is possible. If the interviewer want a more detailed answer from you, just explain the procedure for vertical scaling.

5. Can you define the connection between AMI and Instance?
Many different types of instances can be launched from one AMI. The type of an instance generally regulates the hardware components of the host computer that is used for the instance. Each type of instance has distinct computing and memory efficacy.

Once an instance is launched, it casts as host and the user interaction with it is same as with any other computer but we have a completely controlled access to our instances. AWS developer interview questions may contain one or more AMI based questions, so prepare yourself for the AMI topic very well.

6. What is the difference between Amazon S3 and EC2?
At any AWS developer interview, you should prepare yourself with the concepts of Amazon S3 and EC2, and the difference between them. You can tell the difference between S3 and EC2 based on these criterias: Definition, features, requirements to run a server,...

7. How many storage options are there for EC2 Instance?
Amazon EC2 is the common topic you may come across in an AWS developer  interview. Get a thorough knowledge of the EC2 instance and all the storage options for the EC2 instance. For suggested answer, your response to the interviewer should fully cover the four storage options for Amazon EC2 Instance, namely Amazon EBS, Amazon EC2 Instance Storage, Amazon S3, Adding Storage.

We have compiled a list of most popular and most frequently asked AWS developer interview questions in a typical interview for a AWS solution architect job, as well as the suggested answers for those questions. Different interviewers may have different set of AWS developer interview questions, it depends on the characteristics and requirements of the jobs at the company you are applying for. However, once you have prepared carefully for these questions, you can totally think about the prospect of a successful interview.

Thursday, November 29, 2018

What is the most important of Agile Method?

It is true that within Agile method you have the notion of being free of a set method and allowing the team to decide. I have heard all the arguments. Some say the team will not decide. Some say it does not work. Some say it works under certain conditions. Some say it works but only if the organization is ready. Scrum, by being a formal methodology, automatically negates what is at the heart of the Agile Manifesto and the Agile Manifesto is regarded as a kind of 10 Commandments of Agile Development but the truth is something altogether different.

We did Agile development before it was called Agile development. My coining a phrase, you create an entity (real or not – you have heard of a Unicorn, no?) and by setting forth a method by which to accomplish the goals in mind such as Scrum does you in no way break any tenets.


Agile is not unique to software. Nor is lean, Kanban, or any of the new buzzwords. They are buzzwords. They make enough money and generate enough revenue that PMI is starting to incorporate Agile methods in their PMBOK.

A bunch of guys in a cabin in the woods is not necessary in this day and age and only serves to add to the mystique behind the Agile Manifesto. As far as I am concerned, people who write Manifestos in the woods are suspicious and up to something. Not all of them are planning on blowing something up. Some are just meeting so there will be no distractions. Yeah. Because it requires complete concentration to chase a Unicorn. You cannot do it head on, after all.

I hate to say it, and I will hear about it, but Scrumban and all the over-intellectualization of what amounts to getting work done as a team is a symptom of big brains without enough to do. Or, and equally as valid, are those big brains who see the ability to make money off of the latest fad. It is nothing new, but the buzzwords are. There was always a brownie with less calories. It was not called a Light Brownie until someone marketed towards people who wanted a less fattening brownie. And that is all it is. Less fattening.

I have wondered a bit about why this bothers me so much. In a world that does not seem to reward honesty, why would I insist on calling like I see it? Saying that I care sounds and even resonates a bit hollow because I really cannot care about you if I do not know you.

I guess it boils down to a disdain for bullies. People throw words like punches and get all bent out of shape and worked up because of something as idiotic as what “done” means. Have we forgotten that everything is in context and everything has eyes upon it, therefore perspective, and that there is no judge without an opinion?

Then there are those who think it really is important to define what done is aside from any actually physical project. I will tell you what it is: an idea. A Unicorn.

Get your work done. Inform yourself. Learn. Be wrong once in awhile. Be honest even if it hurts. Scrum, Kanban, Lean, and the like are all meant to take your attention away from what they entail and that is delivering software. I did not say good software. There is no such thing. There is software that does what it is supposed to for some people and not others and there is software that plan stinks because nobody likes it.

Do your best and keep learning and dont let the intellectuals bully you into thinking you need ScrumLeanBan in place. Muda… why do they use a Japanese word? Like the cabin, it makes things more mythical. It is what it is.